[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected from the menuconfig directly


  • To: Julien Grall <julien@xxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Mon, 11 May 2020 15:27:46 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=George.Dunlap@xxxxxxxxxx; spf=Pass smtp.mailfrom=George.Dunlap@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx; dmarc=pass (p=none dis=none) d=citrix.com
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>
  • Delivery-date: Mon, 11 May 2020 15:28:03 +0000
  • Ironport-sdr: sFzvVleouJDg7Xy1TxcKvHMaiHbyxVydoEM6/s1ITbdNkInSW28ttEnCDjOkUY6ajxHNr4MKXo jMipn6myWvWCQtXey2/BHk+ae4HWeKnFi9OfEvYOg3iQXD4/3oXfbkt5lr/gtMtwgd7UAScuVo MLYgihGuTl+w3E6r1IfDOcCaDdFImN2W7v5vmRDOjj2598yDApxXASP1ZpdzaHtZmyuYvRiWXW JkkWplkmxfhjCMCndu7K+hUY1Z8zMqQwwo+XfmLi4r+Z7dz9tbTP0dMZCDw+OuwiETwtaiSO5s YZE=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWHvtEfLlMb5EF90y7GzIGxHVxJ6iRncgAgAYL5QCAABeggIAC9dcAgAILiACABg54AIAAIM8A
  • Thread-topic: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected from the menuconfig directly


> On May 11, 2020, at 2:30 PM, Julien Grall <julien@xxxxxxx> wrote:
> 
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
> unless you have verified the sender and know the content is safe.
> 
> Hi Ian,
> 
> Thank you for the clarification.
> 
> On 07/05/2020 18:01, Ian Jackson wrote:
>> Julien Grall writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be 
>> selected from the menuconfig directly"):
>>> On 04/05/2020 13:34, Ian Jackson wrote:
>>>> George Dunlap writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be 
>>>> selected from the menuconfig directly"):
>>>>> On Apr 30, 2020, at 3:50 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> Well, if I'm not mis-remembering it was on purpose to make it more
>>>>>> difficult for people to declare themselves "experts". FAOD I'm not
>>>>>> meaning to imply I don't see and accept the frustration aspect you
>>>>>> mention further up. The two need to be carefully weighed against
>>>>>> one another.
>>>> 
>>>> Yes, it was on purpose.  However, I had my doubts at the time and
>>>> I think experience has shown that this was a mistake.
>>>> 
>>>>> I don’t think we need to make it difficult for people to declare
>>>>> themselves experts, particularly as “all” it means at the moment is,
>>>>> “Can build something which is not security supported”.  People who
>>>>> are building their own hypervisors are already pretty well advanced;
>>>>> I think we can let them shoot themselves in the foot if they want
>>>>> to.
>>>> 
>>>> Precisely.
>>> 
>>> Can I consider this as an Acked-by? :)
>> I am happy with the principle of the change.  I haven't reviewed the
>> details of the commit message etc.
>> I reviewed the thread and there were two concernes raised:
>>  * The question of principle.  I disagree with this concern
>>    because I approve of principle of the patch.
>>  * Some detail about the precise justificaton as written in
>>    the commit message, regarding `clean' targets.  Apparently the
>>    assertion may not be completely true.  I haven't seen a proposed
>>    alternative wording.
> 
> I have checked the latest staging, the `clean` target doesn't trash .config 
> anymore.
> 
>> I don't feel I should ack a controversial patch with an unresolved
>> wording issue.  Can you tell me what your proposed wording is ?
>> To avoid blocking this change I would be happy to review your wording
>> and see if it meets my reading of the stated objection.
> 
> Here a suggested rewording:
> 
> "EXPERT mode is currently used to gate any options that are in technical
> preview or not security supported At the moment, the only way to select
> it is to use XEN_CONFIG_EXPERT=y on the make command line.
> 
> However, if the user forget to add the option when (re)building or when using 
> menuconfig, then .config will get rewritten. This may lead to a rather 
> frustrating experience as it is difficult to diagnostic the
> issue.
> 
> A lot of the options behind EXPERT would benefit to be more accessible so 
> user can experiment with it and voice any concern before they are fully be 
> supported.
> 
> So rather than making really difficult to experiment or tweak your Xen (for 
> instance by adding a built-in command line), this option can now be selected 
> from the menuconfig.
> 
> This doesn't change the fact a Xen with EXPERT mode selected will not be 
> security supported.
> "

How about this, clarifying that top-level .config is an option, but that it’s 
still better to put it in menuconfig?  (Also note a number of grammar tweaks.)

—

EXPERT mode is currently used to gate any options that are in technical
preview or not security supported. At the moment, this is selected by adding 
XEN_CONFIG_EXPERT=y on the make command line, or to the (currently 
undocumented) top-level .config file.

This makes the option very unintuitive to use: If the user forgets to add the 
option when (re)building or when using menuconfig, then xen/.config will be 
silently rewritten, leading to behavior which is very difficult to diagnose.  
Adding XEN_CONFIG_EXPERT=y to the top-level .config is not obvious behavior, 
particularly as the file is undocumented.

A lot of the options behind EXPERT would benefit from being more accessible so 
users can experiment with them and voice any concerns before they are fully 
supported.

To make this option more discoverable and consistent to use, make it possible 
to select it from the menuconfig.

This doesn't change the fact a Xen with EXPERT mode selected will not be 
security supported.

—

 -George

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.