-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ethan Benson <[EMAIL PROTECTED]> writes:
> On Wed, Mar 23, 2005 at 05:57:36PM +0000, Roger Leigh wrote:
>> > 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?
At the present, I am only aware of two conventions: the "traditional"
names, and the "devfs-style" names.
> 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).
Our personal preferences here aren't really the issue here. Even
though it's not the default, the devfs scheme is a reality, and needs
supporting.
Would you accept a patch to add e.g. an --nvram= option to specify the
device? Your code doesn't need to hard code anything except a
default; as long as the user can specify an alternative, that would be
sufficiently flexible.
Additional autodetection is just the icing on the cake.
>> > 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).
The current powerpc-utils (as of today) now supports autodetection of
both nvram device names.
> 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.
If you look at the patch, it's just six extra lines of code, plus
replacement of the hard-coded device name with a variable. Supporting
additional devices would not require any extra lines of code, since
it's processed in a for loop:
for dev in /dev/misc/nvram /dev/nvram; do
...
Given the simplicity of the patch, and its extensibility should any
other device names come into use, please could you apply it?
Many thanks,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFCQzDIVcFcaSW/uEgRAueYAJ0fbdA7EQyIXdvv8tBsoQqkJulv9wCfQYbd
1Xb9Q+zIvlG7h1Y6/9qFUKc=
=ABRU
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
