Node Approach to MicroKernel

[Cjmovie]

HOW MY OS'S FILE/NODE SYSTEM WORKS:
My idea is rather simple actually:
There are 'nodes'. Each node is either Top-Level or Directory-Level.
Directory-Level nodes are nodes used just for ease of use. For instance, instead of "/fd0" (Just Top-Level), you could put "fd0" in node "Floppy", making the address "/Floppy/fd0". Here, "Floppy" is a Directory Level Node and "fd0" is a top-level node.
Top level nodes actually hold DATA. They give two functions that take as arguments the sector/chunk (512bytes/chunk) that is wanted and a buffer. In reading, buffer is used to put data read in. In writing, buffer is used to hold data to be written. Buffer is exactly 512 bytes long. If you try to access a Director-Level domain it will do nothing, just omit an error.
File systems will be built on TOP OF these directorys. If you access "/Floppy/fd0/MyStuff", it will recogninze "fd0" as Top-Level, and transfer the "/MyStuff" to the file-system manager (driver) assigned to it. The driver will then use the low-level functions of chunk editing (512bytes at a time) to return the requested file or directory information etc.
Basically like a Linux system (I think) but with a few additions/Subtractions.

Excuse the line breaks, this is taken from my source code, but I removed the "//" comment indicators.
What do you think? Basically the system acts as a inter-driver communication system (Letting Program Talk to Filesystem Driver Talk to Physical/Virtual drive driver).

It is built to not care wether the disk is really a disk or a memory location. It also means the OS has no idea if something is a hard disk or mouse without asking the driver that installed it.

In my final system, even the GUI will be a semi-driver type thing (Driver but with lower privelages, so if GUI dies/slows will not slow time critical drivers down).

Not too bad?

[Pype.Clicker]

well, you have identified one of the important aspects of unix organisation: the block device drivers. Imho, you should consider buffers of size different from 512 bytes, because you'll experience a severe performance issue if your kernel is just forcing you to write 1MB to a hard disk by chunks of 512 bytes.

Keep in mind, however, that you might want to _seek_ within files ... or to be able to append data to them, etc.

Even if considering a GUI as a read/write block device might make some sense (okay, you could read events from /GUI/screen0/window1234 and you could write display commands to it, or write a new font to /GUI/resources/fonts/MyFont0), you might have harder times when trying to design the network stack as a couple of read/write things ... And both the network and the GUI will certainly require buffers that are _not_ 512 bytes long.