From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fu Wei Subject: Re: [Linaro-uefi] [PATCH] xen: arm: implement generic multiboot compatibility strings (Was: Re: The GRUB multiboot support patch for aarch64(V3.1)) Date: Fri, 06 Jun 2014 20:57:28 +0800 Message-ID: <5391BAB8.7080402@linaro.org> References: <536A1FCF.50207@linaro.org> <1401899819.15729.44.camel@hastur.hellion.org.uk> <5390205B.5060803@linaro.org> <1401969408.15729.52.camel@hastur.hellion.org.uk> <53909CA0.9010407@linaro.org> <1401987331.7269.81.camel@dagon.hellion.org.uk> <5390A2F6.2060305@linaro.org> <1401993081.15729.170.camel@hastur.hellion.org.uk> <5390DA55.5060100@linaro.org> <1402055229.1313.32.camel@kazak.uk.xensource.com> Reply-To: Fu Wei Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1402055229.1313.32.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Julien Grall Cc: xen-devel , linaro-uefi List-Id: xen-devel@lists.xenproject.org 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