FreeLists / openbeosstorage / [openbeosstorage] Re: Storage Kit Plan

["Tyler Dauwalder" <tyler@xxxxxxxxxxxxx>]

>So the order of calling is:
> 
>         Application --> storage_kit --> syscall (into kernel mode) --> 
> vfs --> BFS (or other) --> device driver --> device.
> 
> Should we be looking into documenting the syscall interface??

I don't think it's necessary right now (though it might be a good
idea to document it eventually when it's more complete, if that's
what you mean; I'm still hoping for a documentation team :-). 

The API we documented is really really similar to the syscall 
interface we'll be using. In most places, I believe we'll just be passing 
in a file descriptor instead of a pVolume, pNode, and pCookie; the 
rest is basically the same. The problem with trying to document the 
syscall interface right now is that there's next to no information available 
about the R5 interface, and the NewOS interface is only partially done 
(though we'll definitely use the part that *is* done as a reference).

If you look through vfs.h in the newOS CVS, you can compare
the functions they've implemented so far for the two interfaces 
(sorry if the URL wraps):

http://www.newos.org/cgi-bin/fileViewer.cgi?FSPC=//depot/newos/include/kernel/vfs.h&REV=23

The filesystem add-on interface (synonymous with the interface
we documented) starts at line 68 (the fs_calls struct). The user-
level interface that we'd call indirectly with syscalls starts at line 
149 (the user_* functions). 

Syscalls are caught for x86 in the i386/arch_int.c file, line 187:

http://www.newos.org/cgi-bin/fileViewer.cgi?FSPC=//depot/newos/kernel/arch/i386/arch%5fint.c&REV=44

They're handled by the syscall_dispatcher() function in
syscalls.c, line 34:

http://www.newos.org/cgi-bin/fileViewer.cgi?FSPC=//depot/newos/kernel/syscalls.c&REV=31

The bottom-level C functions we'll implement for the
Storage Kit will probably look identical to the user_* 
functions in vfs.h. We'll have to make educated guesses 
about the functions that haven't been added yet (like 
attribute functions), but that shouldn't be too hard. Until 
the kernel is ready, we'll implement those bottom-level 
C functions with POSIX. Then, when the kernel's done,
we'll reimplement them with syscalls.

-Tyler

p.s. I did some looking around for info on the R5 syscall interface
before we started doc'ing the vfs add-on API. The only thing I could
find was the stuff in "os_beos.inc" in:

http://linuxassembly.org/asmutils/asmutils-0.15.tar.gz

The guy who came up with it says he's only confident about
half of the functions he figured out. And out of all the functions
he listed, only a handful of the ones we'd need were there. I
didn't think trying to reverse engineer Be's kernel was something
we'd get very far with in a reasonable time frame...