[RISC-V] [tech-config] Profiles and Config and Device Tree
toggle quoted message Show quoted text
Resend on the request of Mark.
---------- Forwarded message ---------
From: mark <markhimelstein@...>
Date: Thu, Jul 30, 2020 at 4:23 PM
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [tech-config] Profiles and Config and Device Tree
Cc: Al Stone <ahs3@...>, software@... <software@...>, tech-unixplatformspec@... <tech-unixplatformspec@...>
I suggest the charter include but not be limited to:
1. define the syntactic format for the content that is human readable. including things like macros etc.
2. define the globally unique record & field (or equivalent) definitions and semantics. this must include rules for org specific field and a clearinghouse for field and record names (or equivalent).
3. define the organization unique naming scheme for profiles themselves (e.g. RISC-V_identifier/URL/profile_name/version_number). also consider if a RISC-V_identifier (like "RISC-V_PROFILE") is part of the string and whether it has branding or trademark implications (with Kim the marketing director's help).
4. define upwards and backwards compatibility rules for different versions of a profile. for example you may end up saying that later profile versions can only be additive for a profile.
5. define the relationship between profiles and other descriptive items in the RISC-V ecosystem including but not limited to: config, ABI and other *BIs, OS config files like device tree, unpriv spec chapter 27 RV strings. provide guidance on how to generate profile relevant portions of those other descriptions from a profile (whether it is manual or generated).
6. define the name and structure of a profile file or files. for structure an example, is it one big file or can it be a bunch of small files that might allow an umbrella file to include them )even nested) for manageability and to allow multiple profiles to share common portions even across orgs. is it tool compatible with something that will turn it into one big file like cpp? can it be built? will it be built every night and be made available? if so, will all versions of a the big file be made available in combined form somewhere?
7. define where profiles are stored and accessible: github? riscv.org website? multiple places? something different? are all orgs required to post their profiles or just RISC-V. org specific profiles may affect the profile file names so that the profile file URLs has some relationship to the URL (if it is included) from the profile name above.
8. define the copyright requirements.
9. define the rules for organizations other than RISC-V to create, potentially hide, publish, and maintain their own profiles potentially including the definition of the types of profiles they can create. for examples of types: they could have a derived profile meaning it only adds things to a riscv.org profile or they may create a custom profile which changes field values from some base riscv.org profile
10. specify the relationship between profiles and app or os compatibility. for example if you adopt and comply with the riscv.org linux profile or create a derived profile from it (see sample definition of derived above) then you are guaranteed that all linux app (and libs) will work on your product. one ring to bind them instead of having to say all the other identifiers list above (see compliance item below).
11. what does profile compliance or compatible mean? what is the relationship between, for example, RV or *BI compliance and profile compliance.
12. create the riscv.org base profiles: e.g. linux, rtos, bare metal. make sure they can manually or automatically generate the portions of the other descriptions (e.g. device tree) as listed above.
I am sure I missed many things and got some things wrong and I suggest we need Krste to weigh in. I derived the above from my discussions from him and my own thoughts, but it is his concept.
I also expect the TG will correct and add many things.
Is this what you were looking for?
On Thu, Jul 30, 2020 at 5:47 AM <arun@...> wrote:
Mark I Himelstein
CTO RISC-V International