Brendan wrote:
There's no callbacks (the VFS and file systems all run as seperate processes in user-space). There is a state machine, but I can't see how you'd keep track of multiple requests without keeping track of the state of each request.
Yeah well, my point about callbacks is that personally I find it more flexible to keep the state machine in the form of callbacks. If you prefer explicit state machine, it's really just an implementation detail.
Quote:
File systems can be simple (when it recieves a request from the VFS it does that request, sends a response and waits for the next request) - no state machine or caching needed.
Filesystems still need states / caching if you don't want to block the filesystem either. I mean, my purpose is not only to have the VFS layer be fully asynchronous, but also the specific filesystems to be fully asynchronous, such that if a FAT driver needs to load a given cluster of the infamous file-allocation-table, it won't block itself on device I/O while it's doing that. Rather it just tells the device to wake it up when the block arrives.
Quote:
You could make the VFS multi-threaded (e.g. one thread per CPU), but IMHO if you've got the VFS, file systems and disk drivers all implemented as seperate processes then most of the work can already be spread across other CPUs, and there isn't much point complicating the VFS itself with re-entrancy locking (and lock contention), race conditions, etc.
Actually I'm looking to do "zero-thread" VFS, which does all it's work from deferred function calls (generalized bottom halves). My kernel panics the moment a deferred function call tries to call any function that could potentially block, so maybe that gives you an idea.
In fact, there are three different contexts my kernel currently knows about:
1. normal context which can block all it wants, and normally runs with interrupts enabled
2. interrupt context which isn't allowed to block and must always run interrupts disabled
3. deferred context, which isn't allowed to block, but normally runs with interrupts enabled
Most VFS functionality should go into the deferred context.
Quote:
Of course if you succeed you could have problems with sychronous file I/O.
Not really. When a system call or exception arrives in kernel, it's in normal context. It can allocate a small event-queue (for a single event), and start the synchronous I/O operation with reporting set to this temporary queue. Then it can block on that queue, and return to userspace once it completes.
Quote:
Of course memory mapped files have other problems too because there's no reasonable way for processes to do their own error handling (e.g. Windows generates a "blue screen of death" when it gets a read error in a memory mapped file).
Well, there's basicly two reasonable ways to handle this: either fake memory mapped files by having every page-fault generate a signal, and have the signal handler request the page. This is a good solution if want to get memory management out of a micro-kernel as much as possible.
Alternatively, you could send the signal only if read fails, and let the application figure out what to do with the issue. Say, in some cases it could just tell the system to put some zero-pages in there to get rid of the fault, and set a flag somewhere that the main process can then check to see that it didn't get the actual contents.
Default action for such a signal would be to kill the process, and if you'd get a double fault from trying to send the signal, then you kill the process anyway. Ofcourse it's naive to hope for programs to actually deal with such issues other than in some special cases, but blue-screening seems a bit too extreme to me..