1. Messages
  2. [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Aaron Durbin
 



On Mon, Jul 11, 2022 at 7:54 PM Greg Favor <gfavor@...> wrote:
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:
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. 

But the problem is that a profile is just putting an extension-style name (e.g. Zi* or Ss*) to a specific combination of an option or parameter, and a specific value for that option or parameter.  Whereas in discovery structures one would choose at least somewhat descriptive intuitive names for options and parameters, and would use booleans, integers, enums, etc. - as appropriate - to specify values for the options and parameters.  The latter would be clean and clear and readily captured by a schema.

My point is that the information, regardless of format, needs to be conveyed in some manner to the OS. There's no getting around that aspect. We need to identify 1. all the things the OS needs and 2. how to convey that information for consumption. We're currently talking about #1 and whether a name or whatever is applied to a construct that construct still needs to be properly conveyed. The Profile proposal in its current form is providing names to some of those constructs. Whether that continues and we embrace it going forward is now up for discussion it seems, but that discussion doesn't negate the fact that we have to enumerate many things to the OS for it to make correct decisions. 


Instead using a very large number of terse extension-style names that cover the combinatorial namespace of all allowed K-V pairs, let alone needing to define a universal naming scheme to follow across the entire architecture now and into the future, seems to result in less comprehensible discovery info and will push out even farther into the future having all this worked out.  Whereas developing simple conventions for naming of options and parameters, and for specifying allowed values, and then having each TG that is developing an extension define the specific names (and allowed values) for the options and parameters of the extension, is relatively straightforward and scalable.  This is part of what tech-config was trying to enable.  (For past extensions, there of course is remedial work to be done, but the idea remains.)

I don't think the having a name for something or not reduces comprehensibility of discovery info. It all needs to be enumerated in one form or another. The question is how to get to a consistent way to describing these constructs across the ecosystem. The divide and conquer approach will work, but I'm not sure we'll get consistent names. If that's not a goal, so be it. Either way, we need to go and backfill things that don't have names/identifiers.
 

In short we need to divide-and-conquer the overall issue and not pile everything into one big ball of yarn.  And let's focus on supporting UD/DT/ACPI discovery methods.  Practically speaking, let's leave the relatively very limited naming in profiles of line item mandates, to the profiles.  Let these be two different and only superficially related problems.   (Ok, I'll step off my soapbox now.)

In order to focus on the discovery methods we need to have the set of things needed by each level the software to be enumerated and provide a way to name/identify those pieces. As you noted above, there may be different types needed, but that requirement falls out from the data gatherig step. However, we'll still need to figure out how to encode all this information anyway for DT and ACPI.
 

Greg
Join tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.