On 06/20/2012 11:49 PM, H. Peter Anvin wrote: > On 06/20/2012 11:06 AM, Goffredo Baroncelli wrote: >> >> Am not saying that we *should* move the kernel away from /boot. I am >> only saying that having the kernel near /lib/modules *has* some advantages. >> >> Few year ago there are some gains to have a separate /boot (ah, the time >> when the bios were unable to address the bigger disk), where there are >> the minimum things to bootstrap the system. >> > > There still is (in fact this exact problem has made a comeback, as there > are plenty of BIOSes which have bugs above the 2 TB mark); however, > there are also issues with RAID (firmware often cannot address all the > devices in the system -- and no, that isn't ancient history, I have a > system exactly like that that I bought last year), remote boot media > (your / might be on an iSCSI device, or even a network filesystem!) and > all kinds of situations like that. > > The bottom line is that /boot is what the bootloader needs to be able to > address, whereas / can wait until the kernel has device drivers. That > is a *HUGE* difference This leads to have a separately /boot filesystem. In this case I agree with you: make sense that the kernel is near the bootloader files. But if /boot has to be in a separate filesystem, which is the point to support btrfs at all ? Does make sense to support only a subset of btrfs features ? > >> Now we have the possibility to move the kernel near the modules, and >> this could lead some interesting possibility: think about different >> linux installations, with an own kernel version and an own modules >> version; what are the reasons to put together under /boot different >> kernel which potential conflicting names ? de facto standard ? >> historical reasons ? Nothing wrong here; but also the idea to moving the >> kernel under /lib/modules is not so wrong. > > No, it is completely, totally and very very seriously wrong. When a bootloader (and the bioses) will be able to address the whole diskS, this will change.. Not now > > -hpa > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
