Re: [Xen-devel] [PATCH v2] tools: implement initial ramdisk support for ARM.

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [PATCH v2] tools: implement initial ramdisk support 
for ARM."):
> On Fri, 2014-04-04 at 16:00 +0100, Ian Jackson wrote:
> > DYK whether Linux has ever not been able to decompress itself - and if
> > so when did this change ?  It would be annoying to break some old
> > installations.
> 
> By "itself" ITYM "its ramdisk". The answer there is that I don't know.

Yes, that's what I meant.

> If you did mean "itself" then the answer is that it is moot because all
> of the kernel's self decompression stuff is in early real (16-bit) mode
> which we skip when booting a PV kernel -- so we definitely do have to
> decompress the kernel image. Hence the trickle of bzip2, xz, lzma
> patches to Xen, libxc and stubdoms.

Right, yes, I knew that.  By "itself" I meant "the kernel is
decompresssing the ramdisk (rather than expecting the loader to do
it)".

> > Looking at the code, it might be a good idea to at least pass unknown
> > compression formats on to the kernel, rather than failing as we do
> > now.
> 
> Unless I'm misreading that's what we do.
> 
> If either xc_dom_check_gzip or xc_dom_ramdisk_check_size fail then we
> set unziplen to 0 which indicates "do not decompress" to the remainder
> of that code block.

Oh yes, inded.

I foolishly assumed that since we had a function
xc_dom_probe_bzimage_kernel (which dispatches to a variety of
decompressors and aborted if it got a compressed image with a magic it
doesn't understand) that this function was used for ramdisks too (and
hence, wasn't quite accurately named).  But I see we have a different
ad hoc arrangement for ramdisks.

Hrm.  Oh well.  I guess this is good enough, then.  We won't fail
on new compression formats (if they're only used for the ramdisk) and
we will work with putative old kernels that don't know how to
uncompress ramdisks.

Ian.

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