Re: [PATCH] libxc: don't fail domain creation when unpacking initrd fails

["Jan Beulich" <jbeulich@suse.com>]

>>> Ian Jackson <ian.jackson@eu.citrix.com> 10/16/17 6:52 PM >>>
>Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when unpacking initrd fails"):
>> On 16.10.17 at 17:45, <ian.jackson@eu.citrix.com> wrote:
>> > Is there no way to tell that a kernel supports gzipped initrds by
>> > looking at the kernel ?
>> 
>> Well, Linux kernels have config options controlling their ability. So
>> even a modern kernel _could_ be configured to require unzipping.
>> I didn't check whether they announce this anywhere outside the
>> (possibly) embedded .config, but even if they did this would be
>> only Linux then. A solution here shouldn't really be OS-specific imo.
>
>I guess I was hoping for an ELF note or some multiboot protocol
>element or something.  If it doesn't exist then your proposed general
>approach is probably best.
>
>I'm afraid I still find the patch less clear than it could be.
>The new semantics of xc_dom_ramdisk_check_size are awkward.  And
>looking at it briefly, I think it might be possible to try the unzip
>even if the size is too large.

I'll double check that.

>I think a sensible implementation is might have to have a flag
>variable to control "try doing it raw".  And it might be bdest to
>replace xc_dom_ramdisk_check_size with either a function which does
>not bomb out if the limit is exceeded.
>
>What you are really trying to do here is to pursue two strategies in
>parallel.  And ideally they would not be entangled.  Maybe there would
>have to be a comment.  Each of the strategies must rely only on
>functions which don't bomb out, to achieve that.

I'll see what I can do. As quite often when changing code I'm not very
familiar with, I had tried to minimize the amount of changes needed. E.g.
I did consider dropping xc_dom_ramdisk_check_size() altogether in favor
of some other function (or even doing what is needed in its only caller),
but that would have been a larger (both textual and factual) change than
keeping the function and adding another parameter.

As to your other reply to Andrew - I don't think I'm up to wiring through a
new guest config file option specifying whether to do the unzipping.
Besides the mechanical aspects I'm also unconvinced this would be
reasonable without then also considering other compression methods.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel