On Fri, 2014-09-26 at 00:08 +0100, Ben Hutchings wrote: > On Thu, 2014-09-25 at 23:20 +0100, peter green wrote: > > Karsten Merker wrote: > > >> Browse online: > > >> > > >> http://anonscm.debian.org/cgit/d-i/base-installer.git/tree/debian/templates-arch > > >> > > >> Adding -arm@ and -boot@ for possible comments/insight. > > >> > > > > > > I suppose the reason for MODULES=dep being the default on arm* > > > might be that some armel systems boot their kernel and initrd > > > directly from an onboard flash chip with a size of only a few MB, > > > so an initramfs built with modules=most might be uninstallable on > > > them due to lack of space. > > > > > Which makes sense for armel, many load their boot files from fixed size > > blocks of flash and flash space is a MAJOR issue (and major thorn in the > > kernel teams side) and you will generally need a new kernel if you move > > to a different device anyway. > > Another possible reason for using MODULES=dep would be that disk access > from the boot loader is very slow (this is the case on Google Compute > Engine for example). > > > On the other hand for armhf i'm not sure it makes sense, most armhf > > systems i'm aware of load their kernels/initrds from filesystems so > > space is not such and issue and with the new armmp kernels having a > > modules=most initrd would presumablly allow one to move to different > > hardware with just swapping out the bootloader. > > Assuming that armhf is not constrained by flash partition sizes (we > certainly don't have any size limit configured for the kernel image yet) > or very slow I/O, I support using MODULES=most by default.
I agree. I'm not aware of any armhf platforms with size constraints or cripplingly slow boot time I/O. I think if either of those show up the answer would be to fix the bootloader to run with caches on, support a better boot device etc etc. Unless there are objections I'll make the change in base-installer. > However, at the moment initramfs-tools won't include PHY drivers even in > that configuration. I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762042 about this sort of thing on xgene, and today I updated it because arndale is affected too. As I say there I'm planning to send a patch to load an appropriate set of phy drivers when running with modules=most. That won't solve modules=dep though. The only solution I can think of right now for that is to extend the existing hidden_dep handling with a scheme which maps each module to be loaded to a list of other modules which should be included (e.g. ahci_platform => { a bunch of phy drivers }). Hardly the most elegant thing in the world, could perhaps be improved by looking at the set of currently loaded drivers, but that has pitfalls too. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1413035956.11505.22.ca...@hellion.org.uk
