Re: [Xen-devel] [PATCH 3/5] libxc: create unmapped initrd in domain builder if supported

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-09-11 at 15:39 +0200, Juergen Gross wrote:

> > > > -    /* load ramdisk */
> > > > -    if ( dom->ramdisk_blob )
> > > > +    /* Load ramdisk if initial mapping required. */
> > > > +    if ( dom->ramdisk_blob &&
> > > > +         (!dom
> > > > ->parms.elf_notes[XEN_ELFNOTE_MOD_START_PFN].data.num ||
> > > > +          dom->ramdisk_seg.vstart) )
> > > 
> > > After this patch the resulting structure of the code is rather
> > > unfortunate, in that the order of the main processing steps depends
> > > on
> > > this ELFNOTE.
> > 
> > Shouldn't we ought to have a common code ELF agnostic? I.e we may have
> > other kernel image format where we have notes but not ELF notes.
> 
> dom->parms is the same for all architectures. I think it would have to
> be extended in that case.

dom->parms is a struct elf_dom_parms which unfortunately appears to
conflate a bunch of generic stuff which can be parsed from a variety of
image types (virt_start, features, etc) and some ELF specific stuff e.g.
elf_notes.

Really this stuff ought to be split out, along those lines with dom->parms
only containing the former.

This sort of happens now in an obscure way by virtue of the /* raw */ and
/* parsed */ comments in the struct definition, libxc _only_ uses parsed
information but you are now adding a use of elf_notes which is in the raw
section. I agree with Julien that this should be avoided.

I think the easy answer would be for libelf to parse that note into an
appropriate new field which is agnostic to ELF.

Ian.

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