Philipp Tomsich <philipp.tomsich@...>
On Tue, 16 Nov 2021 at 14:17, Darius Rad < darius@...> wrote: Philipp,
The Common Software Interface concept seems like it could be a promising
idea, but at this point, that appears to be all it is: an idea. Whether
that idea is fully realized into something that is suitable as the
cornerstone of a platform remains to be seen. I think titling the platform
that way at this point is premature and sets up false expectations. You
said that "CSI was chosen as an unencumbered term", yet every time I have
heard it described, it was something along the lines of "CMSIS, but for
RISC-V", which, to me at least, carries a fair set of assumptions.
On the other hand, you said that a variety of things with respect to the
planning of the Common Software Interface have been communicated up through
leadership at RISC-V. If I understand correctly, that is a driving factor
in retitling the platform to match. If that is the case, it is a little
unclear to me what role this committee has had or is expected to have in
influencing this process. If RISC-V leadership has already decided that
this CSI approach will be followed, then I suppose they could also dictate
the name.
The Platforms HSC writing the specs is a left-over (committees only provide governance) that is expected to be restructured in the future (once the initial set of specifications are through the door) to push the actual specification work down into TGs. Note that the responsibility for delivering the Platforms lies with the Software HC, which still drives the overall process on the strategic level with the HSC leadership focusing on the tactical aspects and the content.
The overall structure of the specifications (i.e. the strategic goal) consisting of: - "Rich OS" specifications provides a rigid platform definition to enable binary compatibility.
- "Deeply Embedded" specifications supporting a wide variety of platform implementations (with mutual incompatibility down to the ISA-level) and a unifying abstraction layer
is based on the apparent gaps in our specification landscape and has been deliberated in late 2020 and early 2021 in the HSC, between the HSC and the HC, and throughout the technical leadership. After reaching agreement on this, the HSC leadership has been tasked with implementing this overall structure (which they have made commendable progress on this year).
There have been plenty of things gone less than optimal in how the specifications have been put together (in no small part due to the intense time pressure of having a self-consistent draft for the rich-OS specifications ready before Summit): most visibly, the introductory sections that should clearly state the purpose of each specification and rehash the product requirements to be addressed, are terse bordering on absent. This is an area to be improved.
However, this terseness (and the need to close these gaps) should not distract from the fact that we are building up two families of specifications to address two specific market segments. The goal today is to deliver on these two specifications, so we have a foundation and a blueprint for future specifications. The overall blueprint of having one specification with a binary compatibility mandate and another specification with a source-code compatibility mandate creates a solid path into the future, as any future Platforms can build on either model or mix-and-match as needed.
When we created the Platform policy, we made sure to leave sufficient room for new (and even unforeseen) Platforms to be requested and specified. This was defined in full view of the fact that neither OS-A nor M/CSI would cover everyone's needs and that the community will surprise us in how they evolve the Platform concept.
It sounds like you already have some ideas for how you would like things to evolve. I can only recommend that you participate actively in us getting the current generation of documents into a rounded-off and mature state — while engaging both with the HSC Chairs and us Software HC Chairs regarding those evolutionary ideas. We are working to get a roadmap and planning underway for "what comes next" for Platforms and any input into that process is much valued.
Regards, Philipp.
I think evolving the platform previously called M will have some of the
same challenges I have mentioned previously. Inconsistency within and
between the Platform Policy, the Specification, and statements in the
meetings as well as terminology that is not clearly defined make it
difficult to make progress in improving the specification. For example,
the Platform Policy indicates that the purpose of a policy is to ensure
binary compatibility, but you are saying that the goal of the platform
previously called M is specifically not that. As another example, it has
been repeated stated that there are no optional requirements in the
Platform Specification, but there are many such requirements in the
platform previously called M. The Platform Policy is conspicuously silent
on the matter, as well as not having a definition for terms like
"recommended".
// darius
On Mon, Nov 15, 2021 at 12:10:33PM -0800, Kumar Sankaran wrote:
> + platforms mailing list
>
>
>
> Regards
>
> Kumar
>
>
>
> *From:* Philipp Tomsich <philipp.tomsich@...>
> *Sent:* Monday, November 15, 2021 9:25 AM
> *To:* darius@...
> *Cc:* Kumar Sankaran <ksankaran@...>
> *Subject:* M-Platform/CSI-Base naming
>
>
>
> Darius,
>
>
>
> As indicated, I'd like to fully understand your thoughts on the M platform
> and how it could evolve. Note that defining this platform does not
> preclude us from adding other deeply-embedded platforms in the future.
>
>
>
> Maybe, to start, let me summarize what has been communicated already to
> various stakeholders:
>
> 1. It will be based on the RVM profile (which gives us a lot of options and
> very few guarantees).
>
> 2. We want to provide source code compatibility (for some parts of the
> source code).
>
> The blueprint for this was ARM's CMSIS… i.e., a software interface spec
> that allows portability for software on uCs in deeply embedded use cases.
>
>
>
> Assumption 1 (RVM) precludes us from having anything resembling binary
> compatibility.
>
>
>
> Note that CSI was chosen as an unencumbered term to mean "Common Software
> Interface".
>
> Given that we'll have a large number of extensions to the basic CSI (e.g.
> an abstraction of crypto-operations, security features, NN, etc.), the
> model is similar to the ISA: a small CSI with many extensions for specific
> use-cases.
>
>
>
> This plan and specification scope have been communicated all the way up to
> the BoD in early summer. The lack of a draft document should not preclude
> us from communicating this plan and scope to the ecosystem at Summit — and
> this should be what drives any discussion on the naming.
>
>
>
> That said: please share your concerns and thoughts…
>
>
>
> Philipp.
|
