Date: Thu, 04 Jul 2002 14:17:34 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bruce Evans <bde@zeta.org.au> Cc: Greg 'groggy' Lehey <grog@FreeBSD.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Mario Goebbels <mariog@tomservo.cc>, current@FreeBSD.org Subject: About DEVFS (was: Re: About GEOM...) Message-ID: <3D24BB6E.3829314A@mindspring.com> References: <20020704210304.Y21619-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> On Thu, 4 Jul 2002, Greg 'groggy' Lehey wrote:
> > I don't know enough about GEOM to embrace it whole-heartedly, but I
> > think you'd be hard pressed to find anybody who disagrees that devfs
> > is a forward. It may need some improvement, but it's so much more
> > logical than what we had before that I really think you should explain
> > your objections.
>
> This has been discussed before. Basically, devfs creates work by moving
> problems around without any significant benefits. I expect control of
> devfs device visibility and persistence of devfs device attributes would
> end up mostly in a utility (devd?). But once you have such a utility,
> you don't need devfs (or MAKEDEV).
Here are the significant benefits realized by the current devfs,
over static device nodes:
o Hardware & node synchornization
o If the hardware is there, the device is there
o If the hardware is not there, the device is not
there (as opposed to being there, but being
unusable)
o Device arrival/departure (necessary for docking ports,
USB, IEEE 1394, PCMCIA, PCCARD, and Hot Plug-N-Play)
o If a device for which there is a driver arrives,
the node is created
o If the device for which a node exists is removed,
the node is removed
o Better support for booting of physically FS-less images
o When porting to a new platform, the ability to
access device nodes is one less thing to worry
about (getting a physical FS running first)
o Because device nodes in FreeBSD have more bits,
they exceed the major/minor numbers representable
on some platform's device nodes in their FS; this
means without a devfs, it's impossible to net-boot
FreeBSD from some systems
o Inability to create non-existant ("convenience") nodes and
symbolic links, thus confusing the /dev directory
o Inability to accidently "tar" or otherwise archive your
entire system to a file in /dev, rather than writing it to
a device (;^))
o Increased security, as hacked permissions values away from
the system defined acceptable safe values can not persist
across a reboot, unless the source code is modified to match
Here are the significant disadvantages:
o Inability to create non-existant ("convenience") nodes and
symbolic links, thus providing device aliases matching those
rendesvous expected by existing third party programs, in
particular, with regard to ABI compatability
o Inability to persistently modify default permissions values
away from the system defined acceptable safe values persistantly
across a reboot, without modifying instance declaration in
source code.
o "One size fits all" per major number for template permissions
definitions
Here are the promised, but as-yet-unrealized additional benefits (you
could also call these significant disadvantages, as they were supposed
to be part of the pay-off for the switch):
o The device instance becomes the vnode reference, rather than
the major/minor
o Specfs can die, once and for all
o struct fileops must die (e.g. inability to set range locks,
ownership, other administrative controls on file objects that
are not backed by fileops == vfsops)
o Real cloning devices
--
Personally, I've never been persuaded that the persistance of modifications
argument against devfs had any validity; I have yet to see one case that
can not be managed via rc.local or modification of driver defaults
(e.g. I know of no transient device that results in the creation of
multiple device nodes for the same major number). I personally think
the correct way to handle this is to write the changes back to the
kernel image, if we are talking about modifications to the primary
instances of the devices.
The ABI argument is resolvable directly: in the conpat hierarchy, you
can create a symlink to the device node; problem solved.
Yeah, it pisses me off that the devfs was not completed before going
on to work on other things which have also not been completed; this
goes for both Julian's implementation, which Poul murdered, and Poul's
implementation, which I regard as still incomplete.
But overall, it seems to be a move forward. I guess if you valued
persistance (e.g. the ability to rename your floppy device to be
/dev/mickeymouse) over the new features, I guess I could see your
point.
At this juncture, though, it's starting to look more like luddism
than reasoned argument against devfs.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D24BB6E.3829314A>