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

[Juergen Gross <jgross@xxxxxxxx>]

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?


Juergen


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