Hi all, (I think I CCed all stake-holders)
A) Decide which "features" to add
B) Decide on the status of the feature
C) Deal with status changes of any past features
The first goal would be to decide on A and any new "features" under C. For B, I am OK to add "???" for now and point to this thread, until we have concluded the discussion
Note that I tracked some of this as preparation for getting CNA status. Items marked with * are not yet in the discussion document that I created for the security team and which we intend to discuss at
the summit.
For all of these, the naming convention is "Section in document" > "Feature" : "Support status". The definition of support status is added at the end of the mail: note that the text has not yet been fully
agreed, but seems to reflect fairly well how we handled stuff in the past.
== On A / B: I think we should add ==
- Resource Management > Null Scheduler : tech preview or experimental
- Virtual Firmware or PV Bootloader Support (not sure which) > x86/Boot
Xen on EFI platforms using GRUB2* : ???
- Hardware > ARM/Alternative Runtime Patching (ARM32 and ARM64): ??? [note that this should probably have been added for 4.8, but I didn't add it]
- Hardware > ARM/System Error Protection* : ???
- Hardware > ARM/Wait for Virtual Interrupt* : ???
- Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
- Hardware > x86/AVX512/Multiply Accumulation Single precision AVX512_4FMAPS* : ???
- Device Models > DMOP (Device Model Operation Hypercall) : ???
New Heading: PV Protocols and Drivers
- PV Protocols and Drivers > pvcalls : tech preview or experimental
- PV Protocols and Drivers > 9pfs : tech preview or experimental
- PV Protocols and Drivers* > sndif (sound device) : tech preview or experimental
- PV Protocols and Drivers* > displif (PV display) : tech preview or experimental
Did I miss anything?
== On C ==
- Security > Alternative 2pm : Supported – I think we should split
this out – it is currently implicitly covered under "Virtual Machine Introspection"
If we introduce a new heading "PV Protocols and Drivers" we should probably list all the common ones as supported in this heading, e.g.
- PV Protocols and Drivers* > default (net, block, console, keyboard, mouse) : supported
There are also USB and framebuffer, which I am not sure whether they should be supported and if not, what their status is
- PV Protocols and Drivers* > USB : ???
- PV Protocols and Drivers* > framebuffer : ???
Suggestions are welcome
Best Regards
Lars
----
## Definitions
### User-facing Support Criteria
* **Functionally complete:** Does it behave like a fully functional
feature? Does it work on all expected platforms, or does it only work
for a very specific sub-case? Does it have a sensible UI, or do you
have to have a deep understanding of the internals to get it to work
properly?
* **Functional stability:** What is the risk of it exhibiting bugs?
General answers to the above:
- *Here be dragons*: Pretty likely to still crash / fail to work. Not
recommended unless you like life on the bleeding edge.
- *Quirky*: Mostly works but may have odd behavior here and there.
Recommended for playing around or for non-production use cases.
- *Normal*: Ready for production use
* **Interface stability:** If I build a system based on the current
interfaces, will they still work when I upgrade to the next version?
- *Not stable*: Interface is still in the early stages and still fairly
likely to be broken in future updates.
- *Provisionally stable*: We're not yet promising backwards
compatibility, but we think this is probably the final form of the
interface. It may still require some tweaks.
- *Stable*: We will try very hard to avoid breaking backwards
compatibility, and to fix any regressions that are reported.
* **Security supported:** Will XSAs be issued if security-related bugs are
discovered in the functionality?
### Definition of Support Labels
Rather than specify each level above, we have some short-hand labels that we use to denote general answer to the above questions.
# Experimental
Functional completeness: No
Functional stability: Here be dragons
Interface stability: Not stable
Security supported: No
# Tech Preview
Functional completeness: Yes
Functional stability: Quirky
Interface stability: Provisionally stable
Security supported: No.
# Supported
Functional completeness: Yes
Functional stability: Normal
Interface stability: Yes
Security supported: Yes
# Deprecated
Functional completeness: Yes
Functional stability: Quirky
Interface stability: No (as in, may disappear the next release)
Security supported: Yes
|