Re: [Xen-devel] Uniform commands for booting xen

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.01.16 at 15:58, <phcoder@xxxxxxxxx> wrote:
> On 11.01.2016 15:32, Jan Beulich wrote:
>>>>> On 11.01.16 at 15:06, <phcoder@xxxxxxxxx> wrote:
>>> On 13.11.2015 10:50, Ian Campbell wrote:
>>>> On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote:
>>>>>> How do you express modules other than kernel+initrd in that
>>>>>> scheme, without grub needing to be aware of any new addition we
>>>>>> may find necessary going forward?
>>>>>>
>>>>>
>>>>> Are modules used by Xen self-identifying? Is it enough to simply pass
>>>>> Xen kernel list of binary blobs or Xen kernel must be told what these
>>>>> binary blobs are? If they are self identifying, why arm needs to be
>>>>> passed module type in the first place?
>>>>
>>>> At first Xen/ARM required the bootloader to identify, but that was since
>>>> identified as causing madness and fixed by having Xen/ARM do as Xen/x86
>>>> does and figure things out for itself, but I failed to communicate this
>>>> clearly and things got implemented on the grub side under the old
>>>> assumptions.
>>>>
>>> This changes a lot. This removes most of hurdles towards uniformity. Are
>>> you ok with replacing xen_kernel/xen_xsm/... with just xen_module and
>>> dropping type altogether?
>>> Do you think that it makes sense to have xen_initrd in order to have
>>> in-memory initrd concatenation like baremetal counterpart? In either
>>> case we can add it later. I'd rather not have a command than to change
>>> its meaning later.
>>> Jan, does it address your concerns?
>> 
>> It improves things a bit, but I'd really like to not see any xen_
>> prefixed commands at all in grub2 - after all Xen should just be
>> an ordinary multiboot client.
>> 
> This is true for x86 but on ARM64 the protocol xen expects is quite
> different and not really multiboot. How would we avoid xen_ prefixed
> commands for ARM64? And when we have them it makes sense to have them on
> x86 as well so that the same set of commands works on both arm64 and x86

Well, if they're unavoidable on ARM then I can see avoiding them
on x86 as not as relevant. Otoh avoiding divergence from other
x86 clients might still call for them to be omitted. In the end you're
the maintainer, so you should know best.

Jan


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