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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
