Subject: Re: kernel & libkvm [was IIci success]
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: current-users
Date: 01/11/1996 10:22:38
>> 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