Jeremy Huntwork wrote: > 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt > this needs its own branch. What sort of time/work is involved here?
Not a ton of work; with a few hours of time, I can probably get this up and running. (I'd just have to compile a newer kernel, install udev, and start making changes to our config files.) At a guess, Saturday (unless Matt wants to do it earlier ;-) ). I am concerned, however, about stripping out udev-config entirely. Maybe it's just because I don't like changing anything (visible) that doesn't have to. I think it would be a better idea to do this in a couple of steps -- yank out all the rules that are now duplicated first, then start going through what is left, and figuring out (a) where it came from (and why it's there) -- most of these are probably still "because MAKEDEV did it" -- and then (b) whether we actually need it. Comparison to e.g. Ubuntu or Fedora rules will probably be instructive. :-) > 5. Ticket 2033. Include support for initramfs. Would this require a > separate branch, and can it be worked on in parallel to other > changes, or is it better to wait until other above changes are sorted > out? It can go in parallel. The only thing it depends on is udev (sort of) and the kernel (sort of). I don't have any objections to putting it into BLFS and linking to it from the kernel page, as long as we also explain that some setup (really early in the book) is required to use the types of root-FS-setups that the initramfs is intended for. E.g., an encrypted rootfs has to be encrypted (cryptsetup) before creating the FS; LVM has to be set up at the same time. But getting that stuff into BLFS first is a better idea.
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
