OSDev.org

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 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.

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

Here's mine, which is similar to the other two:

http://www.themobius.co.uk/documentation/doc.php?architecture

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!