Re: [Xen-devel] [PATCH] xen: make tracebuffer configurable

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.05.19 at 14:58, <George.Dunlap@xxxxxxxxxx> wrote:
>> On May 31, 2019, at 12:10 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 30.05.19 at 12:17, <chenbaodong@xxxxxxxxxx> wrote:
>>> Default: enabled.
>>> Can be disabled for smaller code footprint.
>> 
>> But you're aware that we're, for now at least, trying to limit the
>> number of independently selectable config options? Ones depending
>> on EXPERT are sort of an exception in certain cases.
> 
> I’m trying to remember exactly what we have or haven’t decided.  I take it 
> you think we should avoid having a load of independently-selectable 
> configurations to support?

Yes, that's the main (and perhaps only) reason to limit options with
user visible prompts.

> Baodong, what was your main purpose in adding a patch like this?  Just to 
> make things a bit tidier, or was it to try to go through and generate a far 
> smaller hypervisor codebase (for instance, perhaps to make safety 
> certification more tractable)?
> 
> I think we’ve talked about this before, but our basic options, as far as 
> support, would be:
> 
> 1. Have a single large config option which disabled large swathes of unused 
> functionality

Perhaps this is a worthwhile thing to have anyway.

> 2. Have individual bits configurable, but have only a handful of “security 
> supported” configurations.
> 
> The idea with #2 is that we’d have a “certification” config that we tested 
> and security supported, with all of these individual bits off, as well as 
> “cloud” and “client” configs with all of these “optional” bits on (or some 
> subset on, depending on what each community thought made the most sense for 
> their use cafe).  If people wanted to enable or disable individual config 
> options outside fo those, they’d be taking a risk wrt breakage (not tested) 
> or security issues (no XSA issued unless it affected one of the supported 
> configs).

The one issue with this that I see (besides the implied testing needs,
as generally all or at least most of the possible combinations will need
testing) is that once we have chosen such a "handful", their volume
will likely grow. Plus it may be difficult to come to an agreement what
should or should not be part of this "handful". But sure, we can give
it a try ...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel