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.