Re: [Xen-devel] [RFC for 4.6] xen: Extend DOMCTL createdomain to support arch configuration

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.11.14 at 20:20, <julien.grall@xxxxxxxxxx> wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      int i, j, e820_warn = 0, bytes = 0;
>      bool_t acpi_boot_table_init_done = 0;
>      struct domain *dom0;
> +    struct arch_domainconfig config;
>      struct ns16550_defaults ns16550 = {
>          .data_bits = 8,
>          .parity    = 'n',
> @@ -1347,7 +1348,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>          domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
>  
>      /* Create initial domain 0. */
> -    dom0 = domain_create(0, domcr_flags, 0);
> +    memset(&config, 0, sizeof(config));
> +    dom0 = domain_create(0, domcr_flags, 0, &config);

Why not NULL like almost everywhere else?

> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -228,6 +228,11 @@ struct arch_shared_info {
>  };
>  typedef struct arch_shared_info arch_shared_info_t;
>  
> +struct arch_domainconfig {
> +    char dummy;
> +};
> +typedef struct arch_domainconfig arch_domainconfig_t;

I think we decided that, regardless of all bad precedents, we'd stop
adding things without xen_ prefix to the public interface. I'm also
rather uncertain about all these typedef-s - I think we could very
well get away without adding any new ones (if internally to the
hypervisor or tools they turn out to make the code much better
readable, each such component could still introduce one on its own).

Jan


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