[RISC-V] [tech-config] Profiles and Config and Device Tree
|
Arun Thomas
[Adding Software and Platform]
I agree the Profiles TG will need to work closely with the Config and Platform TGs.
Mark, I think it might be helpful if you (and maybe Krste also) could create a short description of the high-level goals/use cases for Profiles for a future TSC/TC discussion. Profiles cut across many of the TGs, and I think many are still hazy on what’s involved. I expect we will have an easier time recruiting a Profiles TG Chair if the goals are clearly defined.
Best, Arun
From: <tech-config@...> on behalf of mark <markhimelstein@...>
All,
I feel like we could be more coordinated in our efforts here.
From what I know Profiles will overlap in content with Config and with Device Tree (and friends -- using Device Tree to represent the class of configuration files that drive how we build SW from OS, Tool Chain, etc.).
Both Config and Device Tree must be consistent with the appropriate Profile. Profiles will have some information that Config won't need. Profiles will also have some information that Device Tree won't need. Both Config and Device Tree will contain information that does not have to be in a Profile.
All constituents must have representation in the Profiles TG. The Profiles TG will own driving Profiles to closure.
This may be obvious to some of you but it was not to me from the email chains.
Does this make sense?
Thanks Mark Notice: This email and any attachments may contain proprietary (Draper non-public) and/or export-controlled information of Draper. If you are not the intended recipient of this email, please immediately notify the sender by replying to this email and immediately destroy all copies of this email. |
|
|
|
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? Mark On Thu, Jul 30, 2020 at 5:47 AM <arun@...> wrote:
--
Mark I Himelstein CTO RISC-V International +1-408-250-6611 twitter @mark_riscv |
|
|
|
Philipp Tomsich
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 To: <tech-config@...> 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? Mark On Thu, Jul 30, 2020 at 5:47 AM <arun@...> wrote:
--
Mark I Himelstein
CTO RISC-V International +1-408-250-6611 twitter @mark_riscv |
|
|