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

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

On 29/03/16 15:00, Juergen Gross wrote:
> On 29/03/16 15:54, George Dunlap wrote:
>> 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?
> 
> +1 for deleting it. Installing a program which is just doing a "cat" of
> a file is nonsense IMO.

Well running "xen-detect" is certainly a lot better interface than "cat
/sys/hypervisor/guest_type".  An argument could also be made that
maintaining the existing interface is worthwhile -- all the scripts that
currently run xen-detect would continue to operate as they always had
been, rather than breaking and needing to be re-written.

Unfortunately it's a bit hard to know how valuable this would actually be.

 -George

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