Messages in this thread | | | Date | Wed, 14 Jan 2009 07:47:31 +0100 | From | Alain Knaff <> | Subject | Re: The policy on initramfs decompression failure |
| |
Ingo Molnar wrote: > So basically now the kernel has regressed in its bzImage utility: "oh, i > dont have a decompressor for the initrd. PANIC!". And that is a step > backwards.
Well, for the precise case of gzip I agree with you. The reason why you are right in that special case is that gzip used to be the *only* decompressor available, so it was always available, so you couldn't easily chose a config option which removes the decompressor for a gzip initrd.
However, if you think in more general terms, you _could_ get into that case by attempting to boot up using a bzip2-compressed initrd. If you fed such an initrd to the old unpatched code, you'd get an exception at exactly the same place (populate_rootfs) for exactly the same reason (kernel doesn't have a decompressor for the initrd). Please think about it...
I'm not against fixing old problems with new code, that's in general a good thing. What I do have an issue with is that this seems to become _mandatory_, at least in this case...
And the result of such strictness will not be better code, but stagnant code. Nobody will be able to address one problem, because anybody attempting to do that will have his patch rejected because it doesn't also solve the "hunger in the 3rd world" problem.
> Unless you use bzImage i dont think you can really appreciate > this argument.
Maybe that's the source of our misunderstanding. What is this bzImage? (I suppose it's not just the kernel name/format but something more. But what?)
Regards,
Alain
| |