Messages in this thread | | | Date | Sun, 13 Aug 2000 00:26:04 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: NTFS-like streams? |
| |
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/
| |