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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

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

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

Rich / Daniel, am I on the right track here?  Any thoughts?

 -George

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