Hi Al,
Thanks for your reply.
There appear to be some issues on which we have quite differing
opinions. Rather than responding to your various statements, I will
try to draw out these issues.
1/ namespaces - as in the plan9 idea that each process, or process
grouping, can have a different namespace.
You seem to be very keen on this idea. While I think that it is
an elegant idea, I don't think it fits well with Unix, and I
think that it is fairly independant on the main devfs related
issues.
Free control of your namespace (as in plan9) does not sit well
with setuid programs (which are absent from plan9). Many setuid
programs "trust" specific path names, both to read/write and to
execute. If you can control your name space, you can fool such
programs easily. If setuid programs get the default namespace,
you might have difficulty communicating with setuid programs
("lpr /this/file" "lpr: file not found").
Namespaces certainly have some nice features - like mounting all
of the directories in your PATH onto /bin and others - but there
are certainly problems too. As a sysadmin, the idea allowing
people to mess up their namespace and then complain "it don't
work" worries me. If they mess up their filetree, I can go and
look at it. If they mess up their namespace, it is much harder to
look at what is really happening, especially after the fact.
Or would you only allow root to modify namespaces?
2/ "ASCII files are good" you say.
Certainly. Binary files are worst, and an hierarchical namespace
is best.
One of the great stengths of Unix is that "everything is a file".
In actually fact, that isn't quite true.
Some things are lines in text files.
Some things are fields in lines in text files.
Some things are ioctls.
Some things are syscalls.
This is one thing that Plan9 did MUCH better. A lot of syscalls
like getpid, getuid etc became files (like /proc), and ioctls
disappeared (instead you write to /dev/tty/ctl or something).
You appear to want ASCII files to specify how the name space is
tied together. Obviously embeding the namespace description in
the namespace wont work if you want different users to see
different name spaces. But once again, I don't really want that.
If you want, you could have
/home
be a symlink to the homedirectory of the user who does the
READLINK (just like hlfs) and allow people to build a namespace
in their home directory, so that everybody can set their PATH to
/home/bin
but please keep just one namespace.(oops,I jumped back to issue 1).
3/ structure of devfs - different directories or different filesystems.
You seem to be really keen on the idea of having each device
driver produce it's own little filesystem-instance, and then to
bind all of these together into a filetree, presumably controlled
by some ASCII file.
I don't really see what that would gain us. If we were doing a
light-wieght micro-kernel with drivers in separate processes (or
whatever word is used) I could see the point, but we aren't.
Linux, in the Unix tradition, is a monolithic kernel.
You say
> And drivers become aware of the non-local structure in that tree. There
> _is_ a good reason why absolute symlinks in packages are frowned upon and
> it's mostly the same case.
In my sample filesystem, an abolute symlink essentially records a
linking between two "devices".
For example, I have a SCSI controller plugged into a PCI buss.
For this to work, the "SCSI" subsystem must talk to the "PCI"
subsystem somewhere. This is reflected in the symbolic link. If
you like, the SCSI subsystem decides the content of the link, and
the PCI subsystem decides the location of the link.
Or there is the example of the symlink from a disc drive to a
mounted filesystem. When you mount a filesystem, you tell the
filesystem module about a particular disc drive. This
association is reflected in the symlink that gets created.
I don't think this involves any drivers having non-local
knowledge. It just involves drivers communicating with one
another.
Could you let us know what you think is the particular value of
having different filesystems per driver instead of different
directories per driver?
If it is that it allows us to bind together the trees in whatever
organisation we like (as could possibly be suggested by one of
your comments) then I think it is much better for the device tree
to be very fixed/stable/predictable. There is a place of
configurability, but it isn't in the device tree. It is in /dev,
which contains gateways to the device tree.
4/ The nature of device special files.
You say
> Why on the Earth do you _want_ to keep them in filesystem?
Answer: because that is what Unix does. It keeps things in
filesystems (see issue 2).
What I think we are talking about here is the
sysadmin/distribution chosen name and ACL for a kernel-defined
object.
This has to live in the filesystem so that it can hold an ACL.
And it should live there because that is the best place to store names.
You also say:
> And leave the usual device nodes alone - they are very happy as they are.
They may be happy, and you may be happy, but their are those who
aren't.
Given that device node currently only have 16 bits, and that
dividing these bits up hierarchically just doesn't work any more
- we have too many sorts of devices- what do you propose?
1/ convince me that it does work (admittedly, I haven't counted
the devices myself).
2/ extend to 32 bits (64 bits? 128bits?) and hope that that will
be enough?
3/ give up the illusion that it is an hierarchical name space and
just allocate numbers sequentially, as devices are discovered?
This makes the device number essentially meaningless and means
that you have to have a dynamic /dev with all the attendant
problems of dynamic ACLs etc.
4/ something else?
5/ where should the kernel defined device name space live?
I like //devices. You don't like //. I can agree with that,
though it would be nice to have a permanent name that is
independant of the root filesystem. However as the kernel
already "knows" about /etc/init, I guess it can "know" about
/devices or similar.
You seem to suggest that the device namespace should remain
separate from the "regular" namespace. While I could live with
this, I don't agree.
Thanks for your time.
NeilBrown
-
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:14 EST