Re: ITP for yaird, yet another mkinitrd
hello,
On Sun, 26 Jun 2005, Erik van Konijnenburg wrote:
> This is to draw attention to the ITP for yaird,
> Yet Another mkInitRD, http://bugs.debian.org/315298
> Jonas Smedegaard will be Debian maintainer.
ok good news.
> If you see anything in this message that could get
> in the way of the kernel distribution process,
> this is a good time to speak up.
>
> Technically, it's a generator for initial boot images
> (initrd or initramfs), written in perl, that uses sysfs
> to analyse which modules are needed to boot the system,
> and that uses templates to achieve maximum flexibility
> in the generated images; you could also see it as
> a massively over-engineered bugfix for #284294.
>
> It supports SATA, IDE, LVM2, mdadm, cryptsetup,
> cryptsetup-luks, USB keyboards, NFS root. Perhaps
> it supports SCSI and USB storage (the code is there,
> but no test reports for actual hardware). It does not
> yet support EVMS, swsusp, firewire, DASD, loopback,
> loopaes, dmraid.
> Integration with kernel distribution is simple: there
> is a wrapper, mkinitrd.yaird, that can be invoked at
> kernel install time using the "ramdisk=" option in
> recent kernel packages. No diversions, no update-alternatives.
nice.
> There are important differences with Jeff Bailey's
> work on mkinitramfs, also scheduled to go into unstable,
> (Jeff, please correct me if I'm oversimplifying):
>
> - Jeff puts everything on the image and lets udev
> decide at boot time what's needed; I do the analysis
> at image build time. The consequence is that my
> images can be smaller, and his images are more resistant
> to hardware changes.
that's the way it's thought to work in ubuntu.
we haven't yet decided for debian, but tend for hardware detection.
> - Jeff works in shell, I work in perl. His code is smaller
> and thus easier to dive into, mine has more error checking
> and should be able to cope with more complexity before
> degrading into spaghetti.
well the coding style of initrd-tools was very special to put
it into kindly words. we won't late mkinitramfs degenerate to
spaghetti.
> We are aware of each others work and willing to share ideas
> and implementations where that makes sense.
cool.
> A note about the future: yaird is not finished. It boots this PC just
> fine, but there's room for improvement, in particular in the following
> areas:
>
> - The templates give flexibility at the lowest level,
> enough to tune the package for Debian or Fedora, but at a higher
> level more flexibility is needed. As an example, it should be easy
> to omit keyboard support for headless systems.
> - The tools on the initramfs are not tuned for maximum efficiency.
> As an example vgchange as found on the root file system is used,
> which sucks in glibc, which greatly increases the size of the image.
> - A number of features -- evms, swsusp -- are not yet supported.
well we need klibc pretty soon in unstable for nicer reduction.
i filled an itp and planning to schedule it soonest.
--
maks
Reply to: