[openbeos] Re: Porting BFS to Windows

Joseph Galbraith <galb@xxxxxxxxxxx> wrote:
> Axel Dörfler wrote:
> > Joseph Galbraith <galb@xxxxxxxxxxx> wrote:
> >> Unless I'm utterly wrong about filesystem I/O being pretty
> >> much synchronous for linux and BeOS?
> > BeOS device and file system I/O is synchronous only. But since a 
> > file 
> > system must be thread-safe and reentrant in BeOS anyway, having an 
> > asynchronous "backend" would probably be not that hard to support.
> > I expect the problematic fields in the cache and VM area, although 
> > I 
> > can't really say since I haven't seen the Windows API. But porting 
> > to/
> > from Linux is probably harder than it is to port to/from Windows.
> Ahh...
> 
> So, if I understand correctly, during a read operation
> (grossly simplified) it would work something like this.
> 
> 1. App calls read
> 2. Read syscall calls BeOS-fs layer (vfs layer?)
> 3. vfs layer calls file system driver's read interface
> 4. file system driver calls disk driver
> 5. disk driver programs controller and waits for
>     data (blocking current thread.)
> 6. OS runs other threads while controller thinks.

Actually, the OS may run other threads at all times :-)

> 7. Eventually controller interrupts saying data ready.
> 8. Thread is unblocked and disk driver returns to
>     file system driver, which returns to vfs, which returns
>     to read syscall which returns to application.

Exactly.

> Under windows this looks like:
> 
> 1. App calls read
> 2. Read syscall calls I/O manager
> 3. I/O manager calls file system driver's read interface
> 4. Read interface calls disk driver, passing in a function
>     pointer to call when I/O is complete.
> 5. Disk driver programs controller and returns immediately
>     with STATUS_PENDING (and no data.)
> 6. File system driver returns STATUS_PENDING to I/O
>     manager, which propagates to the calling application.
> 7. Eventually the controller interrupts saying data is ready.
> 8. Disk driver calls I/O completion function in file system
>     driver.
> 9. File system driver notifies the I/O manager that the
>     I/O is complete.
> 9. I/O manager notifies application that I/O is complete.
> 
> So, in order for existing BeFS file system driver code
> to work on windows, it has to be changed to expect
> function return from the disk driver with no data,
> to return to it's caller w/ no data, and to expect
> the disk driver to call it at some other entry point,
> later, with the data.
> 
> If BeFS could really be rearchitected to handle this
> kind of thing without too much trouble, a port might
> not be that bad.  (And don't get me wrong, a BeFS
> file system driver for windows would be way cool.)

Actually, I am thinking of pulling the asynchronous I/O mechanism out 
of the disk driver system and into the OS directly, anyway. It wouldn't 
be too much of an effort, but I am not yet sure about how the API 
should look like.

> Trying to do a wrapper which emulates the
> VFS code so that the BeFS filesystem code can
> run unchanged is even more problematic... it could
> be done, but since the BeFS filesystem code
> wants to block the thread, and windows doesn't
> want the thread blocked, everything would have
> to be marshaled into a thread that the wrapper
> layer owns (and can safely block.)  I don't think
> this is going to win any performance contests,
> though it might not be too bad.
> 
> (The files system can block waiting for the disk driver
> to call it's completion routine; it just isn't allowed
> to block the calling thread in certain circumstances...
> in other words, it isn't hard to turn the asynchronous
> model into a synchronous one when permitted and
> convenient.)

Yes, but a different approach would definitely be appreciated :-)

Bye,
   Axel.

Other related posts: