On Sun, 13 Aug 2000, Mo McKinlay wrote:
> Well...wouldn't it be possible to implement a generic 'filefs' modular
> interface? i.e., everything for handling the pseudo-filesystem gets put
> into a module which has an API that doesn't change very often at all (or
> at least, is nicely backward compatible), and doesn't need to be compiled
> at the same as the kernel itself.
Umm... It will make you run file(1) _way_ too often. And such things
should be restrictable to areas in the tree (at the very least). Not to
mention the wonders of remote DoS attacks - just think of a hundred
kiddies logging in to FTP archive and saying cd foo/bar.deb/debian...
Having standard RPC mechanism for userland filesystems is a nice thing,
indeed, but that's completely different story. Aforementioned Plan 9 uses
that for almost all filesystems (OK, except the device drivers' ones,
procfs and other internal kernel stuff). Moreover, that's the only
internal RPC mechanism they have - doing all RPC in filesystem terms
turned out to be possible.
I'm not proposing to take ext2 to userland (and even less so - doing that
via 9P or styx), but for weird_long_dead_micro_floppies_fs it would be
ideal - such things are certainly better in userland.
Besides, ability to have RPC with callers using plain and simple
read()/write()/etc. is a Good Thing(tm). If we had it from the very
beginning libc would be _way_ smaller. Having getpwent implemented as
fscanf from /mnt/nsswitch/passwd/<lusername> and letting nscd do the
right thing... Tempting.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:29 EST