Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 14 Oct 2016, Jan Beulich wrote:
> >>> On 14.10.16 at 11:59, <george.dunlap@xxxxxxxxxx> wrote:
> > On 14/10/16 07:36, Jan Beulich wrote:
> >>>>> On 14.10.16 at 02:58, <sstabellini@xxxxxxxxxx> wrote:
> >>> On Fri, 14 Oct 2016, Andrew Cooper wrote:
> >>>> There should be a high barrier to "Supported" status, because the cost
> >>>> of getting it wrong is equally high.  However, there are perfectly
> >>>> legitimate intermediate stages such as "Supported in these limited set
> >>>> of circumstances".  A number of features are not plausibly for use in
> >>>> production environments, but otherwise function fine for
> >>>> development/investigatory purposes.  In these cases, something like "no
> >>>> security support, but believed to be working fine" might be appropriate.
> >>>
> >>> I agree on this. I think we need an intermediate step: "working but not
> >>> supported for security" is completely reasonable. When we say that it is
> >>> "working", it should be because we have automated testing for it (I
> >>> don't know if I would go as far as requiring it to be in OSSTest, any
> >>> automated testing, even third party, would do). If it is not
> >>> automatically tested, then it is just "best effort".
> >> 
> >> I don't think this is a reasonable expectation - how would you envision
> >> testing the dozens of command line options alone, not to speak of
> >> things depending on hardware characteristics?
> > 
> > Well there may be situations where we can make reasonable exceptions.
> > But it would certainly be a lot better if a feature wasn't considered
> > "done" until there was something in place to make sure that it worked
> > and continued to work, other than "we hope people use it and report any
> > bugs they find".
> 
> Perhaps an earlier question here is what a "feature" is. My command
> line option example was specifically chosen to make it possibly very
> small scope, yet indicate an area where we would likely say "using
> this and that option is not supported" (depending on the instance
> with either of the two meanings you name below).

This is another one of those cases where we need to apply our judgement
on a case by case basis.


> > The more interesting aspect of Stefano's suggestion here is whether
> > there should be two levels of "supported" -- "supported" as in, "this
> > works but it's not in our security boundary", and "supported" as in,
> > "this works and it *is* in our security boundary".
> 
> To me the question is how far that would matter for people
> wanting to use Xen in production: I for one wouldn't feel well
> using features which aren't security supported.

Sure, but Xen isn't only used in high availability production systems.
For example one use case for Xen on ARM is IoT, a space where most
devices don't even have a way to be securely updated yet. (I hope that
people using Xen on ARM in those scenarios do have a way to patch theirs
devices.)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel