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

[Juergen Gross <jgross@xxxxxxxx>]

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@xxxxxxxxxx> 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.

> 
> 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.

+1


Juergen


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