Alexander Viro <viro@math.psu.edu> wrote:
> <rant>
> [snip many of the atrocious SystemV architectural warts and cancers]
> </rant>
> Sorry, I've dealt with a lot of Missed'em'Visms lately and
> compared to them all sucking interfaces introduced by BSD simply pale.
I was only saying `call me SysV' for the network interface
namespace issue - I HEARTILY agree with your SysV warts points.
I've dealt with pure SysV and pure BSD systems, and SysV is
the worse of the two, achitecturally. But I do think that there
is no need to separate the namespace of network devices from
all other devices on the system. It's just inconsistient.
>> Certain things are crucial for a device driver application
>> API (ie, a filesystem) to present:
>> [snip snip]
> _All_ of that stuff can be handled in userland. Remember another mantra?
> "Don't put into the kernel things that can be done outside".
Yep. I do think it should be done in userland. A real, working,
consistient, libdev would be excellent, and a revitalization of
UserFS would seal the deal....
<rant mode="oh-no-he's-going-to-bring-up-that-horrible-userfs-idea-AGAIN!">
Userfs (as some of you may know) was a rather interesting idea
in the 1.x.x tree. What it did was allow user-land applications to
present a filesystem to the kernel. There was a FTP filesystem,
a TAR filesystem, and a few others that were implemented.
Now, there were many issues with UserFS that brought about its
downfall, and they've been rehashed on the list many times.
(suffice it to say that the implementation sucked)
I think that the _idea_ of UserFS, especially applied to the
problem of accessing kernel (/proc) and device (/dev) information
isn't that bad of an idea. It keeps policy (how the filesystem
is arranged) out of the kernel, and is fine for uses where
latency and bandwidth is not an issue (ie configuring devices,
modifying kernel parameters, etc...)
Implementing UserFS is tricky, I agree. But let's play a
little game of what if here - what if a socket-based UserFS
was written, such that a user-land application that performs
and open() or readdir() on a UserFS mount point was its open()
translated into a connect() to a socket that the UserFS has
registered to the kernel. Pathname, pid, uid, access permission, etc
would be sent down the UserFS socket to the UserFS application,
and read()/write() would perform normally. (clean, simple?)
A ``classic'' /dev/ tree would still exist under this
framework, but a /devices/ tree provided by the UserFS application
would allow for all the topology-based-easy-for-humans-to-use
benefits that devfs currently provides.
</rant>
-- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 412.656.3519 cell, 415.701.0792 fax jmcmullan@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution.- 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 May 23 2000 - 21:00:21 EST