On Thu, 6 Apr 2000, H. Peter Anvin wrote:
> Alexander Viro wrote:
> > There is one problem with that (aside of the fact that SNMP is
> > misdesigned) - you are pushing the maintainance of this repository into
> > the kernel. Good luck - and Richard will be the first to become, erm,
> > unhappy, judging by his reaction on another such repository. Device
> > numbers, that is...
>
> That reaction is by and large irrational. I have maintained the Linux
> device number (and name!) space for five years, and besides the fact
> that it was made too small by design (an unfortunate limitation
> inherited from Minix) it has worked just fine.
Here's another space for you: ioctls. Mind maintaining _that_?
> Oh, and the name space management is the harder part of the two to
> maintain. You wouldn't know how poorly some submissions I get are
> named.
I can easily guess. However, I think that the right way to do that is to
provide a simple way for defining an fs (ask Linus about ramfs - this
thing is really easy to turn into library that could be put into VFS and
used by anyone) and let the driver to maintain its namespace. And then let
admin union-mount whatever he wants wherever he wants.
Look, right now we have a friggin' bunch of namespaces, all incompatible.
We have ioctls. We have sysctls. We have procfs, in some places multiplied
by ioctls. We have proposals to extend the fcntls. We have devfs _and_
device numbers. We have SysV IPC. And we have politics and general
mindfscking around the growth of those - just watch the threads regarding
procfs vs. devfs. Don't forget your barf-bag - I've lost a lot of personal
respect to Richard over the stuff that happened on l-k during the last
2-3 months. Normally I'm staying out of this kind of threads, but this
time... Well, I think that I have a thing or two to say.
1) fights over the procfs vs. devfs vs. sysctls (where to put the
stuff) all come from the same design problem: instead of having a
tree for driver and having standards on the layout of that tree we are
have 3 system-wide trees and propose to shove the stuff into them more or
less at random.
2) coupling of procfs tree with procfs proper sucks code-wise
(check fs/proc/{array,base}.c vs. the rest of fs/proc/*) and imposes
problems with security for many sites that do not want all the messy tree.
3) we have insufficient granularity - each of these trees comes on
all-or-nothing basis. Bad, since there are very good reasons to have parts
of each.
4) having the magic numbers all over the place (and worse yet -
having actual tree nodes exported by drivers) is BAD. I've cleaned up the
interaction of procfs and the rest of tree. It was _not_ funny. Ideally,
proc_dir_entry should be opaque to everything except procfs. It's mostly
done, but it _did_ cost a lot of pain. Same applies to sysctls.
5) we really need a moratorium on new ioctls. It's really, really
not funny. Things that are never going to be frequently called, things
that are highly driver-specific and are not required by any compatibility
reasons are dumped into _flat_ namespace and give all sorts of weird
structures shared with userland. That - instead of getting plain text
files. Geez... Why don't we just switch to NT and use oh-so-wonderful
mechanism for pumping the binary stuff into not-exactly-filesystem - it
would even give us a hierarchical namespace, eh?
6) guys, _before_ extending the interface - think whether it can
be done with existing ones. Occam's Razor applies here. Big way. And 'file
as a stream of characters' is a damn powerful interface.
> > If there is a standard space for sysctls - fine, put it into the
> > separate package that will happily live in userland and map the
> > SNMP-mandated numbers to names. Everyone is happy - kernel doesn't have to
> > care about this crap and people who _do_ care are ones who maintain the
> > userland side of things. They are natural candidates for maintaining this
> > repository, not the kernel team.
>
> Doesn't matter -- someone needs to maintain it, and it doesn't have to
> be the "kernel team". Within the LSB there has been suggested a Linux
> Assigned Names and numbers Authority (LANA). I wouldn't mind being
> LANA.
Hey, as long as you don't end up looking like NetSol...
-
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 : Fri Apr 07 2000 - 21:00:16 EST