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

[chenbaodong <chenbaodong@xxxxxxxxxx>]

On 5/31/19 20:58, George Dunlap 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?
>
> 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)?
Hello George, yes yes, smaller code base for safety certification is 
under my thought.
plan to run xen for automotive use case on arm (perhaps i.MX8 ) devices.

> 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).
I like the idea about 'certification' config.
> 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