Re: Devfs implementation.

Richard Gooch (rgooch@atnf.csiro.au)
Mon, 21 Jun 1999 11:18:00 +1000


Horst von Brand writes:
> Dylan Griffiths <Dylan_G@bigfoot.com> said:
> > I'm not sure why people are resisting Devfs. When I first found out
> > about it, I thought it was a great idea. There are some semantics
> > issues (ie: cdrom, mouse, video, and other common links need some form
> > of persistency and need to be pointing to the correct devices), but on
> > the whole it's a good concept.=20
>
> The problem with devfs, IMVHO, is that it solves the _easy_ half of
> the problem. The _hard_ part is permission management (includes
> persistence, default permissions, etc). And at least default
> permission management is _policy_ and DOES NOT belong into the
> kernel.

I'm really bored with people whining about "policy" as though
something is being rammed down their throats. What belongs in the
kernel is a basic infrastructure that is workable. Then you extend
that in user space. Devfsd provides that extension. Thus the policy is
provided by user space.

You may as well complain that the kernel starts init as root rather
than some other special uid that you'd prefer. There too the kernel
sets "policy", but you can always change it.

And if people really can't deal with mounting devfs onto /dev, then
don't. Leave CONFIG_DEVFS_FS=n (the default), or mount devfs onto
/devices and use devfsd to populate/depopulate /dev.

I've put a lot of work into providing choice. I wish people would stop
talking as though I'm expecting everyone to configure their system the
way I do. The devfs detractors behave as though I'm trying to impose
my scheme on them, when in reality they are trying to prevent others
from using devfs all the way. That reeks of hypocrisy.

I'm committed to providing a lightweight, flexible infrastructure that
can be tailored in a variety of ways. I've provided tools (devfsd)
that help in such customisation. I will even assist in making devfsd
work well (it already can do this through the script interface, but
perhaps it would be nicer to have build-in facilities) with a
disc-based dynamic /dev and devfs mounted on /devices.

Anyone who wants to tell me that I'm trying to force something down
their throats can take a flying leap. The fact is I've been bending
over backwards to accommodate a variety of operating modes. This is
why there is a devfsd.

> Sure, the current way of creating entries in /dev for 8 IDE disks
> (or is = it 16 now?) and assorted SCSI devices is dumb, but it has
> the virtue that permissions (even for now-nonexistent devices that
> might appear tomorrow) are handled by exactly the same mechanisms
> and tools as everywhere else.

Strangely, you can use those same tools with devfs.

> OTOH, it is not exactly a hundred times daily that I add a
> device. To mes= s with everything else just for the sake of making
> an operation the average user does _once_ easier is ridiculous.

Why not download it and see what it does and what it can do? Devfs
provides many more features than you are referring to.

Regards,

Richard....

-
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/