On 27-Apr-99 Michael McCormack wrote:
> 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.

That's basically exactly what userfs is.  It catches the system call when it
hits the VFS layer and packages it up into a RPC to another process to deal
with.

> 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

Oh, you mean reflect the call back into the calling process?  That's not really
a good way to do it.  For a start, all interactions a program has with the
kernel are mediated by the library, so why not catch it in the library before
it hits the kernel?

The other problem is that libraries arn't really first-class objects with
respect to the kernel.  All the kernel sees is some mappings of files which
happen to contain code.  Making the kernel understand libraries in that way
would be complex and be of dubious value.  Also there isn't really an existing
mechanism for the kernel to call back into usermode - the only existing way is
through signals, which isn't really a good mechanism for this either.  There 
has been some work on other callback paths (scheduler activations and doors),
but nothing in Linux.

The other problem with library hooks is that it's hard to get a consensual
filesystem state for all processes to share.  It's not too bad when all you're
talking about is mounting an FTP site, but if you need multiple processes which
share the same namespace to also share state, you need a separate process to
manage that state.

        J

Reply via email to