On Fri, 14 Oct 2016, Jan Beulich wrote: > >>> On 14.10.16 at 11:59, <george.dun...@citrix.com> wrote: > > On 14/10/16 07:36, Jan Beulich wrote: > >>>>> On 14.10.16 at 02:58, <sstabell...@kernel.org> 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 Xenemail@example.com https://lists.xen.org/xen-devel