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

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

> 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 

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


Xen-devel mailing list



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