On Monday 02 of July 2012 12:07:18 Jan Rękorajski wrote: > On Mon, 02 Jul 2012, Elan Ruusamäe wrote: > > > On 07/02/2012 09:22 AM, Jacek Konieczny wrote: > > > On Mon, Jul 02, 2012 at 08:45:41AM +0300, Elan Ruusamäe wrote: > > >> > anyone interested working that out (so that udev can be again optional > > >> > for rootfs on lvm systems)? > > > Is udev on initrams that bad, that you just don't want to use it? Are > > > there scenarios where udev just won't work? > > well, there's continuous fight getting initrd versions of tools > > compiled, as new releases tend to get broken with klibc/uclibc/... and > > even if they compile with some patching, they can crash in some > > configurations/architectures. > > AFAIR semaphore messages are harmless. > > > this could end up we will be having glibc version of initrd udev, or no > > initrd version of udev at all, because nobody wants to do the porting to > > small libc's. > > Porting, and lately even just static linking, becomes bigger and bigger > RPITA, so we may have no choice than to having dynamic linked programs > in initrd. I just don't see a reason to justify the extent of work one > have to put into making klibc/uclibc/.../static built tools.
we should use shared libc.so (~1.7MB @ x86-64) in initrd and build essential init tools with -Os optimization. -Os e.g. reduces mdadm size from 448kB to 380kB and 'upx -9' reduces binaries about the ~50% (better than gzip -9). i vote for drop any klibc/uclibc/glibc static linking. _______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
