[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, 2014-06-06 at 14:25 +0100, Julien Grall wrote:
> On 06/06/2014 01:32 PM, Ian Campbell wrote:
> > On Fri, 2014-06-06 at 13:28 +0100, Julien Grall wrote:
> >> On 06/06/2014 01:24 PM, Fu Wei wrote:
> >>> On 06/06/2014 02:31 AM, 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.
> >>>
> >>> This is OK for me, And I think the "multiboot,kernel" is better and more 
> >>> generic. :-)
> >>>
> >>>>
> >>>> 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?
> >>>
> >>> My thought looks exactly the same as yours :
> >>> The cpio utility can detect the cpio file format. Maybe we can just probe 
> >>> the file, see if this is a cpio or cpio.gz.
> >>
> >> cpio is not Linux specific. Probing just the file won't help here to to
> >> determine if we have to add the properties linux,initrd-* or another set.
> > 
> > This can/should be determined by probing the type of kernel which the
> > initrd is being passed to, it is not a property of the initrd.
> 
> I don't find anything documentation in Linux tree that claim the
> linux,initrd-* properties is part of the zImage protocol.
> 
> FYI, the device tree documentation in Linux
> (Documentation/devicetree/usage-model.txt) is talking about
> initrd-{start,end}, not linux,initrd-{start,end}.
> 
> If we plan to assume that the zImage always go with linux,initrd*
> properties then we have to document this specification somewhere.

If something is going to pretend to be Linux (by pretending to be a
Linux zImage) then it should behave like Linux on boot. I think this
extends to initrd handling.

If what Linux does is undocumented (or the docs are out of step with
reality), well, that's too bad.

Feel free to work on improving Linux's documentation. I think it is
orthogonal to the questions raised in this thread though.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.