Re: [PATCH] tools: fix xen-detect to correctly identify domU type

[George Dunlap <george.dunlap@citrix.com>]

On 25/03/16 08:54, Juergen Gross wrote:
> On 24/03/16 12:38, George Dunlap wrote:
>> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
>> <andrew.cooper3@citrix.com> wrote:
>>> On 24/03/16 10:58, Juergen Gross wrote:
>>>> I've searched a little bit in git history in order to understand why
>>>> xen-detect has been invented and/or has all the options which clearly
>>>> are meant to be used in scripts.
>>>>
>>>> The last large modification was done in 2009 and I think Konrad is to
>>>> blame here. ;-)
>>>>
>>>> It was meant to be used in early boot sequence to autoload the needed
>>>> modules (frontends/backends) in case of running on top of Xen. I believe
>>>> this usage isn't needed any longer as the dom0 case is handled
>>>> differently and the needed frontends are loaded automatically on demand.
>>>>
>>>> So this means we can drop all the options of xen-detect, as they serve
>>>> no purpose today.
>>>>
>>>> Next question is whether the remaining functionality warrants keeping
>>>> xen-detect, and how the information it is presenting can be obtained.
>>>>
>>>> If we want to keep it, I can think of following solutions:
>>>> - new kernel ABI (as suggested, David doesn't like it)
>>>> - follow the route it is taking today, information is unreliable
>>>> - parsing of the boot messages (e.g. via an init script into a file)
>>>>   and printing that information (would work, but is a little bit hacky)
>>>>
>>>> Thoughts?
>>>
>>> I don't recommend keeping xen-detect.  It is unreliable, and we will
>>> always be playing catchup.
>>>
>>> Parsing? that's not a little hacky...  The ABI is definitely a better
>>> solution.
>>>
>>> As for the ABI,
>>>
>>> [root@fusebot ~]# find /sys/hypervisor/
>>> /sys/hypervisor/
>>> /sys/hypervisor/type
>>> /sys/hypervisor/uuid
>>> /sys/hypervisor/compilation
>>> /sys/hypervisor/compilation/compiled_by
>>> /sys/hypervisor/compilation/compile_date
>>> /sys/hypervisor/compilation/compiler
>>> /sys/hypervisor/properties
>>> /sys/hypervisor/properties/pagesize
>>> /sys/hypervisor/properties/changeset
>>> /sys/hypervisor/properties/virtual_start
>>> /sys/hypervisor/properties/features
>>> /sys/hypervisor/properties/capabilities
>>> /sys/hypervisor/version
>>> /sys/hypervisor/version/extra
>>> /sys/hypervisor/version/major
>>> /sys/hypervisor/version/minor
>>>
>>> A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
>>> and is applicable to all hypervisors, not just Xen.
>>
>> FWIW this sounds reasonable to me.
> 
> Another sum up:
> 
> - common sense seems to be the current way xen-detect is trying to
>   guess the guest type is unreliable and should be dropped (Jan
>   would like to keep it, but I guess he just wants the information
>   to be available - is this correct, Jan?)
> - the command line options of xen-detect are not necessary any more
> - the information which guest type we are should be obtainable from
>   inside the guest, the consumer of this information should be humans
>   only
> - the OS already knows in which mode it is running, so it should be the
>   kernel to present that information (David disagrees here: he isn't
>   convinced this information is it worth to add another kernel
>   interface)
> 
> As there is no real hurry to have this topic settled I'd suggest we just
> discuss it at the Hackathon (all involved in the discussion so far but
> George will be there). What do you think?

I just signed up, so I'll be there too. :-)

So if we decide not to add a /sys/hypervisor/guest_type node, I guess
we'll probably be deleting this anyway.  The next question is, if we
*do* add such a node, will we replace xen-detect with a program that
simply reports the value of this node?  Or are we planning on deleting
it either way?

If we're planning on deleting it either way, I'd be in favor of deleting
it now, so that it can be gone from 4.7.

 -George

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