First, thanks to Alexander for helping me through the jungle that is udev. It would have taken me a long time to get as good a grasp on the abstract concepts by reading the doco and examples.
Now for the philosophical debate of which book should do what with udev rules. The 2 forerunners in the debate are: - The existence of devices comes mainly from the kernel, so everything should be in LFS. - Many devices are unusable without BLFS software, so the rules for those devices should be in BLFS. The juggling act between technical correctness and educational value is a difficult thing and is made more difficult by those who assume that there is only one right way to do something. I ask those reading this to give equal thought to both goals. Proposal: 1) Since the existence of a device requires nothing beyond a base LFS system, all devices should be named in LFS's rules file(s). 2) BLFS should never have to re-name a device, but symlinking to common names is ok. 3) Anything that does not require BLFS to reasonably use the device should additionally be given group, permission, and symlink assignment as necessary. 4) Anything that does require BLFS should have additional rules to assign the proper group, permission, and symlinks as necessary. 2 ready examples exist. Both have caused a lot of bickering in the past. They are raw usb devices and audio devices. By following the above scenario, LFS would create a rule to make /dev/usb/* (the new standard) instead of the non-standard /dev/usbdev?.? devices created by default. However, since LFS cannot use those devices, the BLFS book would configure them with a proper group and set of permissions (as well as symlinks, if needed) and would show how to mount the deprecated, but sometimes needed, /proc/bus/usb filesystem. This allows for the configuration aspect to be brought out more to the forefront which adds a lot of educational value, IMO. NOTE: This doesn't affect those with usb-based mass storage devices. Those are considered disks and already taken care of by LFS as they should. The other example, audio devices, would basically be the same. The devices would be created with their default permissions and group owned by root, but would be created with the proper names and in the proper directories. BLFS would then have the perfect forum to layout what needs to be done to use those specific devices (configuring the perms on the devices, adding the user to the audio group, installing the software to access the devices, etc.). Again, this is an attempt ro maximize education by clearly defining the roles of the 2 books and allowing each to play to their own strengths. Community discussion on this matter is highly encouraged. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
