[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Uniform commands for booting xen
From: |
Vladimir 'φ-coder/phcoder' Serbinenko |
Subject: |
Re: [Xen-devel] Uniform commands for booting xen |
Date: |
Fri, 22 Jan 2016 10:14:03 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 |
On 18.01.2016 11:28, Ian Campbell wrote:
> On Mon, 2016-01-11 at 15:06 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> 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?
>
> So ending up with xen_hypervisor followed by one or more xen_module lines?
> That's fine with me. This bit:
>
> @@ -203,15 +155,11 @@ prepare_xen_module_params (struct xen_boot_binary
> *module, void *xen_boot_fdt)
> grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name);
>
> retval = grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible",
> - module->node_info.compat_string,
> - (grub_uint32_t) module->
> - node_info.compat_string_size);
> + "deprecated", sizeof("deprecated") - 1);
>
> Seems to be changing the compatibility string of hte node to "deprecated",
> which isn't right (or at least won't work). The nodes still need to be
> identified as being modules per http://xenbits.xen.org/docs/unstable/misc/a
> rm/device-tree/booting.txt that means "multiboot,module" (or if you insist
> "xen,multiboot-module").
>
Changed to "multiboot,module" and committed
>> 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.
>
> If it is useful on baremetal (and I can see that it would be) then I think
> it would be useful on Xen too.
>
> Ian.
>
>
signature.asc
Description: OpenPGP digital signature