OSDev.org

hi. im going to keep this short and just explain the concept. micro-ish-kernel. kernel includes VFS, but all filesystems (except an interface to processes and possibly a simple ramdisk) are user-mode services. everything is a file. everything. all IPC is done via the filesystem, with files acting as objects. you send messages to files, with a printf-like call (this would ideally be hidden in a higher level language). any data mentioned would be copied in binary form (ie, it wouldnt be translated into text like printf, incase anyone was thinking that). a service would offer to mount a directory. any subsequent messages sent to a file within it would pass through that service. services like this could include handlers for traditional filesystems such as ext3 or FAT, as well as ftp, devices, etc. because all IPC is done via the vfs, the windowing system would also act as such a service. various other services could exist for the purpose of translation and abstraction. these services may apply to, for example, all files with a certain mime type. for example, various services may exist for different image file formats, providing a generic set of messages - stretch, convert, etc. information about services could be cached, so they could be loaded on demand.
using a VFS for all ipc, and having VFS operations have so much string handling overhead, would obviously constitute a significant performance impact, however the logical and heirachial organisation of shared data would ease development, likely decrease bugs and dramatically increase flexibility.
please reply if you have any questions, suggestions or constructive criticism or would like to express your interest in this idea. i could obviously not implement this alone, however when i get time, i will work on a linux-hosted prototype. i also have some more to say, however this post is long enough as it is and there is no need to speak about implementation details unless anyone else is interested. thank you for your attention, i would like to hear your opinion.

[copied from web page im working on]
<p>In the beginning, there was Unix. Everything in Unix was a file. As Unix evolved and increased in complexity, it became apparent that many ideas cannot be expressed as files. That is, the conventional Unix file. Data is read, byte by byte, and written, byte by byte. In this day and age, it seems rather primitive to treat all files and devices as a stream of bytes.
<p>A file manager would employ a library to load it's icons from the sequence of bytes that is a file. What if the icon is a jpeg as opposed to PNG? It would generally use two libraries, check what the image is, and load it appropriately. A year after the file manager is released, a new image format becomes popular, and is found suitable for icons. The developer would have to either go and add support for the corresponding library to the file manager, or develop a plugin system, and rely on third parties to create plugins - or do it themself. It could also use another library that encapsulates other image file libraries, and plugins. This is usually done by the toolkit, however because the toolkit generally depends on a connection to a windowing system, and provides a lot more than just image handling, it would be bloat for a command line tool.
<p>Most full-featured file managers provide various actions to perform on a file. Deleting, renaming, compressing, etc. as well as actions specific to the type of file. The file manager would usually - in conjunction with the rest of the associated desktop environment or operating system - keep complex records of which program performs which operation on which type of file. These actions usually involve starting a complete application, even if you only want to do something relatively simple. Suppose you have a huge image file from your 5MP camera, and you want to email it to a friend. This would generally involve resizing the image, possibly lowering it's quality, compressing it and emailing it to someone. A file manager with image operations, compression and email inbuilt would obviously be bloat (with the possible exception of compression), so most file managers rely on opening external applications and allowing you to use it to resize the file, lower it's quality, gzip it, and email it. This would mean opening something like photoshop or the gimp, then something like winzip or ark, then something like outlook or thunderbird - all of which provide a lot more than what you need. This is bloat.
<p>Suppose that instead of a file being a sequence of bytes, which you read from and write to, that it is an object that you perform operations on. OO programmers would be familiar with this concept, and while object oriented languages have been around for a long time, the principals are yet to be applied to filesystem.
<p>Imaging that you send a message to a file, such as [using a C-like calling convention] resize("40%"). You don't need to know how this magically happens, it is done and you continue. This would be sent to the kernel (a conventional kernel, or a server), the kernel would see what server handles the 'resize' operation when sent a single string on that kind of file, it would then send the message to that service, along with information about the process sending the message, and the file it is on. The service would then do some lower level operations on the file, either using another service, or by juggling bytes itself.
<p>All this message passing and parsing would obviously mean more than significant overhead compared to using a library - as well as the microkernel overhead itself. CPU time would be the main issue, however memory and disk access would be dramatically reduced - removing the need for large applications when only using 5% of what is loaded. Seeing as CPUs advance at a much faster rate than disk, network and memory, this would increase overall speed - as well as making pretty much everything computers are used for easier and more flexible.
<p>While applications would obviously still exist for things like word processing and movie editing, these would be much smaller and more flexible by utilising smaller services that can be loaded on demand. In the example of a movie editor, for speed reasons it would still be very library dependant, things like exporting to different formats and inserting audio clips would be very flexible.

I think this is (generally) how many OS developers are thinking now-a-days.

I'm implementing a similar system, myself, as well. Currently working on an OO-ish, extensible driver API capable of various things via the command prompt:

echo "115200" > device.io.serial(0).baud; cat myFile > device.io.serial(0)

--Jeff