[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: initrd/initramfs: we discussed enough, let's take some action now :)



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[trimming recipients to lessen duplicates]

On Sat, 15 Oct 2005 16:34:57 +0200
Erik van Konijnenburg <ekonijn@xs4all.nl> wrote:

> On Sat, Oct 15, 2005 at 08:57:31AM +0200, Sven Luther wrote:
> > On Sat, Oct 15, 2005 at 08:47:57AM +0200, Erik van Konijnenburg
> > wrote:
> > > On Fri, Oct 14, 2005 at 12:53:41PM +0200, Jonas Smedegaard wrote:
> 
> > Hey, i didn't know the mkinitrd wrapper was shell, or i would have
> > done it myself. I wonder why you need the :
> > 
> >   if [ "$supported_host_version" != "" ]
> > 
> > though, since by default, it will test for an empty string, so this
> > seems redundant, but maybe there is some obscure shell thingies i
> > am not aware of.
> 
> As Jonas suspected, it's coding style.  This notation works
> correctly even if the variable happens to contain "-x";
> furthermore, this notation does not require the reader
> to grok the difference between -n (null string) and -z (zero string).

I believe -n means "nonzero string" (not "null string"), and the
oppposite of -z (not a geeky variation of -z). At least that's the
explanation in the manpage of test in Debian sid currently.


> One of the reasons why
> yaird can be simple in principle (if not in implementation ...) is
> that it does not bother with 2.4 compatibility.  In particular, it
> needs /sys to do analysis.
> 
> With a bit of hand-waving, there are two broad approaches:
> * require the user to upgrade to 2.6 *somehow* before upgrading to
> yaird
> * extend yaird with a universal-boot mode.
> 
> The first one relies on using initrd-tools or mkinitramfs for the
> 2.4->2.6 step; it's probably quickest.
> 
> The second one is more interesting: to build a boot image that works
> on any machine, you don't have to analyse /sys.  You need such a boot
> image for the d-i, and it would help in migrating away from
> initrd-tools. The generated image would be very similar to what
> mkinitramfs does; it's not obvious that extending yaird to do this
> has real advantages over just using mkinitramfs in this context.

The first option is really a "ignore the issue and hope someone else
deals with it".

One of the reasons I find yaird interesting is exactly that it is an
alternative. If a problem shows with a kernel, you can try installing a
different kernel to see if the problem goes away. Similarly if a
ramdisk-generator lacks a feature you can switch to an alternative
generator that handles this particular feature.

As Jeff explained earlier, initramfs-tools aims to "being stupid"[1] and
just provide a framework for other packages to hook script snippets
onto. Yaird seems to aim at "being smart" and contain enough
intelligence itself about all features it wants to support.

I would really like to have the choice of both approaches, also for
less common tasks like switching from 2.4 or preparing an alien bootup
(either for different hardware or for diskless clients).


Oh, and btw, Erik: Please have a look at
http://wiki.debian.org/InitrdReplacementOptions and consider improving
it. :-)


 - Jonas


[1] Hope you don't take this as an offense, Jeff. I find that
"stupidity" can be a good quality: Computers usually are meant to
serve, and servants interpreting commands too intelligently can cause
problems... :-)

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDUSsIn7DbMsAkQLgRAv60AKCXfwTd181xnuWNhYlXhJckp7sZCQCfb/la
THToNO+vQIrCGnBHqgp0kDk=
=5WgZ
-----END PGP SIGNATURE-----



Reply to: