Jim Gifford wrote: > As far as udev rules, CLFS has made the move to use the rules that > have been included for over a year with no issues at all.
Great! :-) That (well: the fact that you've seen no issues, at least) means we can very likely do the same: drop udev-config entirely and go with udev upstream's rules only. Of course, CLFS used to do a couple of things with udev a bit differently than LFS did (though I have not looked at what you're doing in at least 6 months, so it may have changed), so I suspect that it may be better to do a sort of convergent evolution here than just dropping udev-config. But as I said last time, I believe we can start comparing what's provided from udev upstream with various other distros' configurations (and I'll add CLFS to this list as well), and we can likely start dropping lots of rules. > The biggest issue when it comes to a 64 bit build is x86 bootloaders, > grub still doesn't play nice with 64 bit. The bootloader can be 32 > bit, but building it is the issue. There are other choices out there > that need to be looked at for bootloaders. I should probably just go look at the "native x86_64" CLFS book, but as I understand it, lilo is the only one that works native-64-bit for x86* architectures. Are there more? (I tried compiling grub2 as 64-bit a couple of days ago. Turns out that configure barfs halfway through; they appear to be hardcoding a lot of "-m32" stuff in their configure.ac to force 32-bit.) Although actually, when I consider the way a bootloader needs to work, I come to the conclusion that whatever the bootloader's equivalent of grub's stage1/stage2 are, need to be compiled either 16-bit or 32-bit. So I'm not sure that there will be a way to compile *everything* in the bootloader to be 64-bit. Obviously the stuff that runs inside the host (/sbin/lilo, the grub shell, whatever grub2's equivalent is) could be run 64-bit, but the rest is the issue. Anyway, rather than speculating, I should just go start reading. :-P > If LFS wants to support multiple architectures, I would recommend > only supporting x86, x86_64, and powerpc. The others are just too > complicated. Yes; I hope that's the idea as well. :-) I think pointing people to CLFS for other architectures -- or coming up with some other solution entirely -- would be good. (Not that there are that many people, but hey, you never know.) OTOH, LFS has done a lot of work to be UTF-8 capable (thanks Alexander for most of this!), which was done after CLFS split off. There may be a few other things like this that may cause issues for some users if we stay split. Hmm...
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
