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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-04-04 at 16:00 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH v2] tools: implement initial ramdisk support for 
> ARM."):
> > The ramdisk is passed to the kernel as a property in the chosen node
> > of the device tree. This is somewhat tricky since in order to place
> > the ramdisk and dtb in ram we first need to know the size of the
> > dtb. So we initially create a DTB with placeholders for the ramdisk
> > and finalise the value (which doesn't change the size) once we know
> > where everything is.
> 
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> 
> I'll leave you to push it (perhaps after giving time for others to
> comment on v2).

Thanks, I'll leave it until next week.

> > I'm considering proposing this for backport to 4.4 since lack of
> > initrd support is at the very least rather inconvenient for many use
> > cases.
> 
> I think this is a viable backport candidate.  Can you let me know when
> it's in-tree and I'll add it to my list.

Sure. Or since I'm supposed to be doing backport stuff for ARM I could
pick this one up myself.

> > Also, should we consider (separate from this change) making libxc not
> > decompress the consider ramdisk by default? These days Linux at least can do
> > the decompress itself and supports more algorithmns, like xz.
> 
> 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.

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.

> 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.

Ian.


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