|Mario Goebbels||Jul 2, 2002 6:51 am|
|Poul-Henning Kamp||Jul 3, 2002 1:43 am|
|Julian Elischer||Jul 3, 2002 2:16 am|
|Poul-Henning Kamp||Jul 3, 2002 2:59 am|
|Simon Dick||Jul 3, 2002 3:10 am|
|Bruce Evans||Jul 3, 2002 4:23 am|
|Poul-Henning Kamp||Jul 3, 2002 5:36 am|
|Poul-Henning Kamp||Jul 3, 2002 6:47 am|
|Bruce Evans||Jul 3, 2002 6:47 am|
|Julian Elischer||Jul 3, 2002 9:30 am|
|Terry Lambert||Jul 3, 2002 10:44 am|
|Wilko Bulte||Jul 3, 2002 3:24 pm|
|Bruce Evans||Jul 4, 2002 2:19 am|
|Greg 'groggy' Lehey||Jul 4, 2002 2:22 am|
|Mario Goebbels||Jul 4, 2002 2:31 am|
|Bruce Evans||Jul 4, 2002 2:37 am|
|Bruce Evans||Jul 4, 2002 4:27 am|
|Terry Lambert||Jul 4, 2002 2:17 pm|
|Daniel O'Connor||Jul 4, 2002 7:09 pm|
|Terry Lambert||Jul 4, 2002 7:39 pm|
|"Vladimir B. " Grebenschikov||Jul 5, 2002 2:38 am|
|Terry Lambert||Jul 5, 2002 5:05 am|
|Paul Herman||Jul 5, 2002 8:14 am|
|Subject:||About DEVFS (was: Re: About GEOM...)|
|From:||Terry Lambert (tlam...@mindspring.com)|
|Date:||Jul 4, 2002 2:17:12 pm|
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.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message