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@lists.xen.org http://lists.xen.org/xen-devel
