My file IO system

[BMW]

I am currently working on implementing decent file IO in my OS.

This is the plan:

At the lowest level are the drivers for different storage device interfaces e.g. ATAPIO (all I've got ATM). These drivers provide basic functionality such as reading and writing sectors. These drivers will (later) handle queueing requests. At this point in time I intend to make all disk IO synchronous for simplicity (probably until I get multitasking and DMA going).

The next level up is a storage device abstraction. A storage device is represented by a structure consisting of necessary information about a particular storage device (type, filesystem, label, size, a cache pointer which will be used by the filesystem drivers for caching certain stuff like the FAT or root dir, and more to be added). The storage device abstraction provides functionality similar to the drivers - reading and writing sectors (through the drivers), and will also be capable of providing information about a storage device.

A device manager will keep track of all the storage devices (as well as other devices), and provide functionality such as getting a storage device from a storage device label.

Above this is the filesystem drivers e.g. FAT16 (All I've got ATM). These will manipulate the filesystem to read, write, create, delete and rename files on a storage device.

Above the filesystem is the file IO interface. This will provide the file abstraction, with functionality such as reading, writing, renaming, creating and deleting files, streamlining the process across different filesystems and devices.

Does this seem like a reasonable way to go about file IO? Are there any major complications that I have overlooked? Any comments or suggestions are welcome.

[Brendan]

Hi,

If you're planning on doing multi-tasking (and communication between tasks, semaphores/mutexes, etc); then implementing device drivers and worrying about file IO first is a complete waste of time because everything will change after you've implemented multi-tasking and communication. Basically; the interface/s you design and the code you implement will both be either discarded or radically modified beyond recognition.

With this in mind:

• Implement multi-tasking
• Implement some sort of communication and/or sychronisation (semaphores, mutexes, FIFO queues, etc)
• Design the VFS (so that it uses the multi-tasking and communication and/or sychronisation) including support for asynchronous IO; then implement it (e.g. maybe using a "quick and dirty RAM disk hack" for testing initially)
• Once you're able to use the VFS for reading/writing files and directories; then worry about real file systems and/or storage device drivers (not before)

Cheers,

Brendan

[BMW]

Hi,

If you're planning on doing multi-tasking (and communication between tasks, semaphores/mutexes, etc); then implementing device drivers and worrying about file IO first is a complete waste of time because everything will change after you've implemented multi-tasking and communication. Basically; the interface/s you design and the code you implement will both be either discarded or radically modified beyond recognition.

With this in mind:

• Implement multi-tasking
• Implement some sort of communication and/or sychronisation (semaphores, mutexes, FIFO queues, etc)
• Design the VFS (so that it uses the multi-tasking and communication and/or sychronisation) including support for asynchronous IO; then implement it (e.g. maybe using a "quick and dirty RAM disk hack" for testing initially)
• Once you're able to use the VFS for reading/writing files and directories; then worry about real file systems and/or storage device drivers (not before)

Cheers,

Brendan

That sounds like a good idea. Lucky I didn't plough ahead and have to redo the whole thing - thanks for the warning.