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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when 
unpacking initrd fails"):
> On 16.10.17 at 17:45, <ian.jackson@xxxxxxxxxxxxx> 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 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.

Ian.

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