Node Approach to MicroKernel
Posted: Mon Aug 29, 2005 9:08 pm
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?
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?