Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions
On Mon, Jul 11, 2022 at 11:28 AM Aaron Durbin <adurbin@...> wrote:
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.
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.)
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.)