11.04.2012 23:22, david M brooke написал: > On 23 Apr 2012, at 20:20, Andrew wrote: > >> 11.04.2012 21:36, david M brooke написал: >>> On 11 Apr 2012, at 14:16, Yves Blusseau wrote: >>> >>>> Le 23/04/2012 11:31, Andrew a écrit : >>>>> 11.04.2012 11:20, Erich Titl написал: >>>>>> Hi Andrew >>>>>> >>>>>> at 23.04.2012 10:07, Andrew wrote: >>>>>>> 11.04.2012 09:36, Erich Titl написал: >>>>>>>> Hi Andrew >>>>>>>> >>>>>>>> at 22.04.2012 23:20, Andrew wrote: >>>>>>>>> Hi all. >>>>>>>>> I'm thinking about some improvements that can be useful in future, >>>>>>>>> especially on tiny systems, and that should be added before 5.0-beta >>>>>>>>> release if they'll be accepted as useful: >>>>>>>>> >>>>>>>>> 1) Split single solid initrd to multiple files, for ex. - basic initrd >>>>>>>>> with binaries, and additional files with kernel modules (usb variant, >>>>>>>>> cd >>>>>>>>> variant, etc). Syslinux supports multiple initrds: >>> Hi all, >>> >>> I am increasingly interested in non-x86 systems and for those SYSLINUX is >>> no good. For ARM the preferred boot loader seems to be U-Boot, or for "raw" >>> booting on the Raspberry Pi the kernel image needs to include the >>> initramfs. As long as we can accommodate different approaches for different >>> platforms that's OK. >>> >>> Agree that having a compressed filesystem for logging seems like a great >>> idea. >>> >>> david >> AFAIK uboot supports also initramfs or other ramdisk types, but it >> requires prepared images. This is actual for SOHO MIPS-based routers, >> but I don't know about Raspberry PI. Possible there are possibility to >> use some '2nd-stage' loader to boot from CF/NAND. How generic distros >> are booted on Raspberry PI& > U-Boot does indeed support initramfs, but probably not *multiple* initramfs > files. > > The Raspberry Pi *must* boot from the first disk partition on its SD card, > but that could in principle run U-Boot rather than booting a kernel directly. > Using U-Boot would provide the flexibility for TFTP download, NFS root etc. I > haven't seen any examples of that yet, but then again virtually nobody has a > physical Raspberry Pi yet either :-) > The "generic" distros I have checked so far just put a kernel image with an > embedded (small) initramfs on the first disk partition and then boot into a > root disk on the second partition on the SD card. > > It's no big deal and we should not constrain our enhancements on an x86 > platform with what the Raspberry Pi needs. I'd just like the option to retain > a single initramfs (embedded in the kernel image…) rather than *having* to > work with multiple initramfs files. > > david We should decide in what way we'll handle splitted initramfs to fit it on all platforms. There are IMHO 3 most acceptable variants: 1) Generic initramfs with scripts/binaries for arch, and separate initramfs images for platforms of arch (or even for booting variants for each platform) with modules. For x86 it'll be OK, on ARM - 2nd image can be absent (it will not have modules, all required drivers are compiled into kernel - because kernel is targeted for single board). 2) Same as 1) but possible some binaries (like curl for netbooting) are also pushed into boot type-dependent initramfs. 3) Same as 1) or 2) but 1st initramfs is compiled into kernel. It'll require some reworking of building process, and will result in some flexibility decrease.
Imho 1st variant looks as preferred (it should soften edge between distro versions - user can easily upgrade kernel + modules of distro, or can leave kernel+modules but upgrade all userland); and in that case we can even have dual independent versioning - version of kernel-related stuff, and version of userland. Or even provide multiple kernel branches (3.2-stable one, and bleeding-edge 3.x) into one single distro branch. Today it isn't too actual, but after 6-12 months fresh kernel may brings some valuable functions into router box... ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
