Re: [Xen-devel] [Linaro-uefi] [PATCH] xen: arm: implement generic multiboot compatibility strings (Was: Re: The GRUB multiboot support patch for aarch64(V3.1))

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-06-05 at 22:00 +0100, Julien Grall wrote:
> On 06/05/2014 07:31 PM, Ian Campbell wrote:
> > On Thu, 2014-06-05 at 18:03 +0100, Julien Grall wrote:
> >>>> While we are modifying the protocol, "linux-zImage" is confusing in the
> >>>> name. Actually we can use it for an ELF, another OS... I don't think Xen
> >>>> will change his behavior depending of the DOM0 image.
> > 
> > Actually thinking about this some more I think you are right. Xen
> > already probes the kernel it gets so we can safely implement this as
> > multiboot,kernel, since we don't really need the more specific type. If
> > in the future some non-probable kernel comes along which we want to
> > support we still have the option of adding more specific compatibility
> > strings.
> > 
> > Fu Wei -- if this is OK with you I will modify the wiki page to
> > s/multiboot,linux-zimage/multiboot,kernel/ and rev this patch to suit.
> > 
> > Can we do something similar with linux-ramdisk? I'm not sure since we
> > cannot easily probe the ramdisk contents. We could base the ramdisk
> > behaviour on the probed behaviour of the kernel. Anyone got any
> > thoughts?
> 
> I have only check FreeBSD, and they don't have any bindings for the
> ramdisk for now. It seems they use the command line for this purpose.
> 
> Probing the ramdisk won't help here because the magic and the underlying
> filesystem might be the same.
> 
> I was about to say, we should do add a "multiboot,ramdisk" (or another
> name) but we have to add the linux,initrd-* foo in the device tree.
> 
> In another hand keeping the actual properties with properties from
> another ramdisk protocol won't harm here. Each kernel will deal with the
> property it would like to use.

Having thought about this I think the way I see it is that the module
contains a ramdisk and that is what should be described by the
compatibility string. The method by which this thing is then passed down
to the kernel is actually a function of the kernel in question, which we
have decided can be probed for. Something which is mimicking the Linux
arm/zImage or arm64/Image format can be expected to be mimicking the
Linux initrd protocol as well IMHO.

So I therefore intend to update the wiki with "multiboot,kernel" and
"multiboot,ramdisk" in place of "multiboot,linux-zimage" and
"multiboot,linux-ramdisk" respectively.

I think "boot,module" should also be "multiboot,module" for consistency.
I intend to make that substitution as well.

I will send out an updated Xen patch with those renamings in place.

Fu Wei, I'm very aware that we are redrafting this under your feet. I'm
sorry about this. I think what is being proposed here amounts to
changing a few string constants on your end, but if you have any
concerns at all please shout at me.

I was also planning to clarify the introduction to the wiki page to make
it clearer that the spec is intended to be generic in nature. I don't
think this should make any difference to the implementation, but again
do shout at me.

Ian.


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