[PATCH] MAINTAINERS: move hvmloader to x86

[PATCH] MAINTAINERS: move hvmloader to x86

[Jan Beulich]

... as being more like a hypervisor extension into the guest than a
part of the tool stack.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -344,6 +344,7 @@ S:	Supported
 L:	xen-devel@lists.xen.org 
 F:	xen/arch/x86/
 F:	xen/include/asm-x86/
+F:	tools/firmware/hvmloader/
 
 X86 MEMORY MANAGEMENT
 M:	Tim Deegan <tim@xen.org>

Re: [PATCH] MAINTAINERS: move hvmloader to x86

[Ian Campbell]

On Tue, 2014-11-04 at 10:43 +0000, Jan Beulich wrote:
> ... as being more like a hypervisor extension into the guest than a
> part of the tool stack.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

/me goes to sweep out his QUEUE IMAP folder...

> 
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -344,6 +344,7 @@ S:	Supported
>  L:	xen-devel@lists.xen.org 
>  F:	xen/arch/x86/
>  F:	xen/include/asm-x86/
> +F:	tools/firmware/hvmloader/
>  
>  X86 MEMORY MANAGEMENT
>  M:	Tim Deegan <tim@xen.org>
> 
> 
> 

Re: [PATCH] MAINTAINERS: move hvmloader to x86

[Andrew Cooper]

On 04/11/14 10:43, Jan Beulich wrote:
> ... as being more like a hypervisor extension into the guest than a
> part of the tool stack.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I think this is a very sensible idea, but...

>
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -344,6 +344,7 @@ S:	Supported
>  L:	xen-devel@lists.xen.org 
>  F:	xen/arch/x86/
>  F:	xen/include/asm-x86/
> +F:	tools/firmware/hvmloader/

hvmloader as a binary is linked together with other bits in
tools/firmware, which form part of the x86 HVM boot path.

As a result, I would recommend this path being "tools/firmware/" to
include these other bits in being part of the x86 architecture code.

~Andrew

>  
>  X86 MEMORY MANAGEMENT
>  M:	Tim Deegan <tim@xen.org>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [PATCH] MAINTAINERS: move hvmloader to x86

[Jan Beulich]

>>> On 04.11.14 at 11:47, <andrew.cooper3@citrix.com> wrote:
> On 04/11/14 10:43, Jan Beulich wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -344,6 +344,7 @@ S:	Supported
>>  L:	xen-devel@lists.xen.org 
>>  F:	xen/arch/x86/
>>  F:	xen/include/asm-x86/
>> +F:	tools/firmware/hvmloader/
> 
> hvmloader as a binary is linked together with other bits in
> tools/firmware, which form part of the x86 HVM boot path.
> 
> As a result, I would recommend this path being "tools/firmware/" to
> include these other bits in being part of the x86 architecture code.

No, not really. SeaBIOS should remain in Ian's realm, and I think
e.g. the old ROM BIOS also is much better known by the tool stack
maintainers.

Jan

Re: [PATCH] MAINTAINERS: move hvmloader to x86

[Ian Campbell]

On Tue, 2014-11-04 at 11:20 +0000, Jan Beulich wrote:
> >>> On 04.11.14 at 11:47, <andrew.cooper3@citrix.com> wrote:
> > On 04/11/14 10:43, Jan Beulich wrote:
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -344,6 +344,7 @@ S:	Supported
> >>  L:	xen-devel@lists.xen.org 
> >>  F:	xen/arch/x86/
> >>  F:	xen/include/asm-x86/
> >> +F:	tools/firmware/hvmloader/
> > 
> > hvmloader as a binary is linked together with other bits in
> > tools/firmware, which form part of the x86 HVM boot path.
> > 
> > As a result, I would recommend this path being "tools/firmware/" to
> > include these other bits in being part of the x86 architecture code.
> 
> No, not really. SeaBIOS should remain in Ian's realm, 

Agreed (well, I'd welcome a co-maintainer, not that it's much effort to
sync every now and then).

> and I think
> e.g. the old ROM BIOS also is much better known by the tool stack
> maintainers.

Not me, that's for sure ;-)

I think things under tools/firmware should, where appropriate, have
their own independent entry overridding the tools/* default, rather than
introducing a new umbrella entry one level further down.

IOW I think this patch for tools/firmware/hvmloader is appropriate and
correct in its own right. If someone wants to propose different
maintainership for other bits of tools/firmware/* then the default then
that should be done as a separate exercise IMHO.

Ian.