Hey Jeremy,
How about having a special "filesystem" that simply throws open,
read, write, close, etc calls back to a user library?
The calling process would actually call a system call, but the
kernel turn this into a call to shared library, and the shared
library would return to the process directly.
i guess thats something between option 1) and 4).
Advantages:
* its backwards compatible
* one off modification to kernel
* handling library could be specified at each inode
Disadvantages:
* The library and the kernel would have to have some method to share
file
handles.
* each process would have to make sure it loaded the filesystem access
libraries in advance. This could (should?) be done in ld.so.
* don't know how easy this would be to do in the kernel
Mike
>
> Yeah, that's probably what I'd do. There's 4 options:
> - user mode, with a special API
> - user mode, with libc hacks
> - kernel mode, with NFS
> - kernel mode, with some other interface
>
> Only the first 3 are really viable, and the middle 2 probably strike the best
> balance between portability and generality. 4 has its uses, particularly if
> you can steal someone else's "other interface", like CODA.
>
> J
