Okay, in trying to get my elf loader working I am going to need an I/O structure, even if its only reading from RAM.
So I was thinking of a three-tier structure as follows:
1. Block I/O device
Lowest tier, dealing with blocks/sectors/RAM pages. This level will handle caching.
2. Filesystem code.
Independent of Block I/O. Middle tier, dealing with open/close/seek etc. for specific filesystem, will make indirect calls to Block I/O through volume manager struct.
3. Volume manager.
This is the top level, the level accessed by user programs. Will combine both a filesystem module and a block I/O module. For example it will combine FAT/Floppy to enable FAT access to floppy drives.
So, am I overcomplicating things?
How would you do it?
Daryl.
I/O System
-
Curufir
Re:I/O System
I would alter it slightly, my design runs something similar to this.
1. Device specific driver.
2. Fixed API IO interface.
3. Filesystem specific interpreter.
4. Virtual Filesystem accessible by user.
1 and 2 can be combined, but personally I like to keep things as modular as possible. Also 2 can be used to drive any character type device not just disks which keeps the OS interfaces coherent. Caching will be dealt with by a combination of 1 and 3 (Eventually
) since caching type/method is often device/filesystem specific.
1. Device specific driver.
2. Fixed API IO interface.
3. Filesystem specific interpreter.
4. Virtual Filesystem accessible by user.
1 and 2 can be combined, but personally I like to keep things as modular as possible. Also 2 can be used to drive any character type device not just disks which keeps the OS interfaces coherent. Caching will be dealt with by a combination of 1 and 3 (Eventually
) since caching type/method is often device/filesystem specific.
Re:I/O System
my thought trail runs thus;
read on file
request goes to vfs with file descriptor
vfs looks at the FD to see what FS is bound to it
vfs passthrough calls to the FS manager
FS does passthrough hardware disk request
disk driver IO
so....
VFS -> FS LAYER ->hw api call -> DISKIO
mmm looking at this its the same as curufir's!....
my vfs + api call go through my devfs. since the hw api call does a generic read call on the attached device
read on file
request goes to vfs with file descriptor
vfs looks at the FD to see what FS is bound to it
vfs passthrough calls to the FS manager
FS does passthrough hardware disk request
disk driver IO
so....
VFS -> FS LAYER ->hw api call -> DISKIO
mmm looking at this its the same as curufir's!....
my vfs + api call go through my devfs. since the hw api call does a generic read call on the attached device
-- Stu --
-
Tim
Re:I/O System
Here's mine, which is similar to the other two:
http://www.themobius.co.uk/documentation/doc.php?architecture
http://www.themobius.co.uk/documentation/doc.php?architecture
-
DarylD
Re:I/O System
Right, I have had a dig through some more resources and read through the comments and still trying to get this clear in my head. The way I look at is like this then:
Device driver: Deals with the physical layout of the disk, function calls deal in sectors (or maybe blocks/clusters). Kernel use only.
Filesystem: Uses the device driver, reads in sectors and then translates this into files/directories etc. Has open/close/read/seek etc calls. Kernel use only.
I will not be having a VFS, rather I will be having distinct separate disk volumes (RAM/floppy/hard disk partition) in a similar way to windows. So I will have a volume manager, this is the top level user callable code and handles all file functions in addition to mounting etc.
So, is this pretty much what everyone recommends?
I certainly don't want to have to recode due to some stupid design decision on something this big!
Device driver: Deals with the physical layout of the disk, function calls deal in sectors (or maybe blocks/clusters). Kernel use only.
Filesystem: Uses the device driver, reads in sectors and then translates this into files/directories etc. Has open/close/read/seek etc calls. Kernel use only.
I will not be having a VFS, rather I will be having distinct separate disk volumes (RAM/floppy/hard disk partition) in a similar way to windows. So I will have a volume manager, this is the top level user callable code and handles all file functions in addition to mounting etc.
So, is this pretty much what everyone recommends?
I certainly don't want to have to recode due to some stupid design decision on something this big!