udev rules

Ken Moffat ken at linuxfromscratch.org
Sun Nov 27 16:22:02 PST 2005

On Sun, 27 Nov 2005, Jim Gifford wrote:

>>  The bad news is that alsamixer is broken in cross-lfs-1 (the devices 
>> starting at controlCn are missing), at least if sound is compiled into the 
>> kernel (haven't tested modules).  The config-5 works correctly for me (with 
>> udev070).
> That's BLFS and not CLFS, but that will change with what I have in the works
  Meanwhile, we are supposed to waste everybody's time with partial 
rules?  Or are you suggesting that CLFS should not be a valid platform 
for building BLFS packages, and therefore each of our builders should 
reinvent the wheel when they build the applications they need ?  I know 
there have been suggestions that alsa devices should move to a separate 
rules file, but lfs-svn hasn't done that yet so I fail to see what 
benefit there is for CLFS in not only ignoring some of the devices, but 
in not providing a separate rules file to create them for people who 
need them.

  We're an official LFS project, where is the benefit in forging a 
separate path for udev rules ?  And doesn't development happen on the 
list ?

>>  I can see there might be reasons to use our own rules, e.g. if lfs-svn 
>> dropped devices that aren't found on x86, but at the moment the regular lfs 
>> rules support iSeries devices and dasd (s390) so I think there is no reason 
>> to maintain our own rules.
>>  Anybody think we ought to maintain our own rules ?  If so, which devices 
>> do you need that aren't supported by the regular lfs rules ?
> We are going to have our own support packages for udev.
  As part of the udev tarball ?  If so, how is CLFS different from LFS, 
which is happily using its own rules file ?  And I repeat, what devices 
do we need to support that aren't in the current LFS rules ?  Or if not 
as apart of the udev tarball, what is the point of extra packages ?

  das eine Mal als Tragödie, das andere Mal als Farce

More information about the cross-lfs mailing list