Matt Darcy wrote:
1.) Kernel Headers, yes you knew this was coming but its certainly worth
talking about, a lots been said on this but its really still unclear of
direction. I suppose the discussion should center around
b.) work with Jim's methods of sanitizing our own headers
c.) Look at what other distros are doing and try to work with them
Aren't "b" and "c" the same (good) thing?
2.) Udev - This again has been a hot topic of many projects, but with
LFS now dropping hotplug I feel it important ti discuss and clear up a
few areas
a.) Udev rules - how complete/incomplete should they be
I won't answer the question myself (because, as you know, I am a maximalist and
don't believe in educational side of things WRT udev), but will list possible
answers.
From the completeness viewpoint:
I) Completely unconfigured: just enough to boot LFS.
II) Devices usable in LFS are correctly named but have root:root permissions,
because not everyone wants separate "floppy" and "cdrom" groups. Some people
think that the "media" group is better.
III) Devices usable in LFS are correctly named and have proper permissions, as
assigned by LFS developers.
III) II, plus: Devices not usable without BLFS packages are at least correctly
named. IOW, if one installs a BLFS package without reading the udev/passwd part
in BLFS book, the devices become usable for root.
IV) III, plus: Devices requiring BLFS packages are put in the proper group.
From the content viewpoint:
I) Device naming (NAME="...") and permissions
II) I, plus "persistent" symlinks like
/dev/disk/by-path/pci-0000:00:07.1-ide-0:1 -> ../../hdb (basically, stock
60-*.rules minus dmsetup line because it is wrong). I feel this is important
because we install the *_id programs and don't use them yet. I think it is
important to configure everything we install.
III) II, plus manually created persistent names like the ones we attempt to use
for multiple Ethernet interfaces.
IV) III, plus Debian-style script that generates such system-specific persistent
names (e.g., autogenerates rules for CD-ROMs, although this can be generalized
for Ethernet too). I got the CD-ROM part working on Archaic's computer.
What I don't tolerate is wrong rules, like the current IDE CD-ROM symlink rule.
It is racy, it doesn't work for multiple CD-ROMs, and it doesn't allow users to
specify other symlinks to their CD-ROM device. Please remove it immediately, and
add instructions (to BLFS?) for the readers to create such rules manually:
# SAMSUNG_CD-ROM_SC-148F (pci-0000:00:07.1-ide-0:1)
ACTION=="add", BUS=="ide", ID=="0.1", SYMLINK+="cdrom"
# PHILIPS_CDD5301 (pci-0000:00:07.1-ide-1:1)
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrom1"
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrw1"
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="dvd1"
(as I said, I have a script for autogenerating them, but let's leave it out for
now)
d.) Should we all use the same rules lfs/livecd/cross-lfs/hlfs even ?
Let cross-lfs use their own rules, because the advances in LFS and CLFS are
different. In LFS, there is good text. In CLFS, they got persistent naming. But
that's not an excuse for not merging CLFS advances in LFS.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
