[RISC-V][privileged-software] [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions
Philipp Tomsich <philipp.tomsich@...>
Duplicating the information (i.e. having the individual extensions marked and the profile itself indicated) seems like an error-prone proposal, unless we mandate/enforce consistency checking.
Given that this does not provide a significant benefit, it seems safer to stick with the canonical form listing the base and individual extensions.
What is the expected benefit from duplicating this information?
Philipp.
On Mon, 11 Jul 2022 at 23:15, Allen Baum <allen.baum@...> wrote:
Greg and I did discuss having Unified Discovery (UD) description macros for profiles, e.g. an RV22A bit that indicates support for all of the individual extensions (and option value ranges) required to meet the profile requirements.
This was in addition to, not replacement of, all the individual requirements, so you'd still have to set the values for each individual required extension.
The idea of have a macro "bit" (perhaps) for a union of different features, and a way to carve out/remove (and probably replace) some specific extension or option is an interesting one, but sounds fraught with possible weird corner cases.
On Mon, Jul 11, 2022 at 11:28 AM Aaron Durbin <adurbin@...> wrote:
On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:
On Fri, Jul 8, 2022 at 3:25 PM Greg Favor <gfavor@...> wrote:
To add on to Alan's point. These "extension" names were created simply to represent individual line items in the Profiles. In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.
Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).
It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you named it. If we're going down that road, it would be good to have things consistent.
What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired). Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs. The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).
In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.
We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification.
Somewhat related, will we have a common way to refer to a Profile that identifies itself as a Profile that can be conveyed as a whole to an OS? This discussion is very much analogous to the toolchain discussion which leads to implementations that may not entirely implement a Profile may want set operations for carve outs for non-conformance. But either way, the SW that is being provided this information has to have a way to identify and keep track of these concepts anyway because it needs to deal both with Profiles proper and the exploded components regardless.
If we're going to not call them extensions, I suggest coining something we can use more accurately then. I don't have any great ideas atm.
As Alan mentioned, him and I threw around names like "profentions" (aka profile extensions), although more out of amusement than practical value.
Practically speaking they should have a reasonably self-descriptive (yet short-ish) name. Maybe simply "mandate names"? This also avoids any confusion with extension names and with K and V names that would be used in discovery structures. This also covers mandate items that are one sentence behavioral descriptions (of either a behavioral allowance or disallowance).
Greg Favor
On Mon, Jul 11, 2022 at 2:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:
This was a point I tried to make in another thread about tech-config and profiles. Support for a profile implies support for all the extensions mandated by the profile (but still leaves unspecified the support for further extensions).
So the question - that should be answered by the direct software user community of tech-config discovery structures - is whether the rest of a tech-config structure must only specify supported extensions not mandated by a profile, or must it also specify (redundantly) all the supported individual extensions, or is any degree of redundancy from zero to full allowed?
For example, having full redundancy would allow someone to simply check for presence of a specific extension of interest - without having to also check profile presence bits and understand what each of them implies. Conversely, does someone feel that any redundancy creates confusion or complications for software using tech-config structures?
The rest of us can raise questions, but the direct users of tech-config are the best ones to determine the right answer.