[openbeos] Re: Porting BFS to Windows

  • From: Joseph Galbraith <galb@xxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Wed, 10 Aug 2005 13:10:15 -0600

Axel Dörfler wrote:

Joseph Galbraith <galb@xxxxxxxxxxx> wrote:
I don't know, but I suspect that this highly asynchronous
model isn't handled by the existing code base for linux /
BeOS, and that introducing it would account for much of
the estimated time.

I also suspect it would make it pretty difficult to write
a BeOS-fs emulation layer.

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

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

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

Thanks,

Joseph


Other related posts: