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

[Fu Wei <fu.wei@xxxxxxxxxx>]

On 06/06/2014 07:47 PM, Ian Campbell wrote:
> 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.

Sorry for late response, happy to see the code become more generic. 

And your modification for the wiki page  is good for me , will follow it to 
update my patch! :-)

Thanks 
> 
> Ian.
> 


-- 
Best regards,

Fu Wei
Enterprise Server Engineer From Red Hat
LEG Team
Linaro.org | Open source software for ARM SoCs
Ph: +86 186 2020 4684 (mobile)
IRC: fuwei
Skype: tekkamanninja
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021 

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