[openbeos] Re: Porting BFS to Windows
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 14 Aug 2005 14:23:03 +0200 CEST
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:
