>> It'd also provide a place to put something like a /kern/dev [which
>> could be synthesized by the kernel]. I'm not suggesting that EVERY
>> driver necessarily do that, like you-know-who, but for at least some
>> types of drivers it'd be really handy.
> Why not? Having a /dev which configures itself sounds like a handy
> feature to me.
It's also hell on people who want anything even slightly nonstandard in
/dev. One thing I like about /dev is that I can rename, delete, add
things in there with mv, rm, mknod. A device driver that thinks it
knows better than I do what I want its /dev entry to be called is (a)
arrogant and offensive and (b) wrong.
There are a few cases where things will break if the entries aren't
where they're expected to be - like /dev/null - but in most cases, if I
have some reason to want to juggle /dev, it is not the kernel's place
to tell me I can't.
It does have a certain advantage for LKMs, because of the changing
major number problem; having a /kern/lkmdev directory that contains
subdirectories for LKMs would be a good idea. I would propose
something like this: loading an LKM "foo" would cause /kern/lkmdev/foo
to magically appear, with entries in it, one for each minor device
supported by the driver. Then I can populate /dev with symlinks to
/kern/lkmdev/foo, and everything works.
"But", you say, "that loses you the ability to "chmod 640 /dev/fooctl"
to restrict access".
Partially. You can regain some control by making /kern/lkmdev owner 0
mode 700 and dropping in setuid symlinks, as discussed a while ago.
Then make the /dev/fooctl symlink setuid-root and let its execute bits
vary, and you've got some permission control back. What you don't have
is the distinction between open-for-read and open-for-write...I'm not
sure how to address this.
What we really want is a way to give an LKM name instead of a number
for the major device, but I can't see any good way to do that. About
all I can think of is to overload one of the mode bits on a device
special file to indicate that the major number is supposed to go
through some sort of lookup table, but where that table is kept is a
hard problem.
der Mouse
mouse@collatz.mcrcim.mcgill.edu