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.