On Wed, Mar 23, 2005 at 05:57:36PM +0000, Roger Leigh wrote: > > devfs is obsolete and slated for removal from 2.6 soon. > > That's true. However, the naming scheme is not devfs-specific, and is > used by others.
I think it is devfs specific. I have never seen this naming outside of devfs systems. > > more easily fix the udev rules to put the nvram device is the > > correct location. > > The "correct" location is rather subjective. I use the alternate > scheme because I prefer it, and I'm not the only one to do so. The > udev devfs.rules scheme is in common use and supported by the udev > maintainer (who also uses it himself), and on such systems ybin and > mkofboot are broken. I also used the scheme without devfs or udev for > several years (but I've only recently moved to powerpc). here is the problem. udev puts device naming conventions under the control of the sysadmin (which is fine, and no different from a purely static /dev where the sysadmin can mknod things to whatever names he feels like). The issue I have is how many naming conventions am I going to be asked to support? what if someone decides it should be in /dev/mem/nvram? or /dev/firmware/nvram? I am simply not going to add endless growing bloat to support everyones notion of where the device should be. I am going to support the traditional location that its had since inception, and the traditional expected location given Unix history (which avoids using subdirectories unless there is a really good reason for them, such as hundreds of related devices. in traditional Unix most devices can be considered `misc' and are therefore simply at the root level of /dev which IMO is correct). devfs last I looked put about 2 or 3 devices in /dev/misc, that is simply silly and adds no benifit whatsoever, the udev rules would do well to correct such sillyness. > > unless nvsetenv gets changed this patch should not be applied > > as it will prevent ybin from doing proper error checking. (ybin > > should not accept non-standard /dev/nvram locations if nvsetenv will > > not). > > Sure. > > I may yet alter the nvsetenv patch to allow the nvram device to be > configurable at runtime, which would make this patch rather more > robust. I'll discuss that with the powerpc-utils maintainer first, > though. See above, I am not going to add endless lines of code to ybin to try to figure out where a device is on random peoples systems, nor am I going to add configuration options for something like this. Device names should be standard and predictable, all of Unix history says a device like /dev/nvram, belongs at /dev/nvram. Whats next? moving /dev/null to /dev/misc/null? -- Ethan Benson http://www.alaska.net/~erbenson/
pgpusHOg1l9pv.pgp
Description: PGP signature
