|
Kumar Sankaran
On Wed, Apr 28, 2021 at 11:10 AM Greg Favor < gfavor@...> wrote: Philipp and Kumar,
I haven't looked over the Platform Policy doc (if I got the name right), but won't it address these high-level generic matters that apply to all platform specs?
Greg
Yes, all the issues being discussed in this thread regarding the platform spec documentation structure are covered in the platform policy document.
On Wed, Apr 28, 2021 at 8:59 AM Darius Rad < darius@...> wrote: On 4/28/21 11:30 AM, Philipp Tomsich wrote:
>
>
> On Wed, Apr 28, 2021 at 5:03 PM Darius Rad <darius@...
> <mailto:darius@...>> wrote:
>
> On 4/28/21 8:54 AM, Philipp Tomsich wrote:
> > Here a short summary of some of the discussions that went on in the
> > early weeks of the year.
> > I hope this helps to clarify rather than compounding the confusion...
> >
> > In order to provide interoperability within platforms, there is no
> > optionality within each platform.
> > Implementations are allowed to do whatever they want outside of the
> > requirements, though.
> >
>
> So nothing is optional ...
>
> > However, we provide for some "managed optionality" through the
> > extensions: implementations can choose to conform to these in
> addition
> > to the base specification if they are compatible with all
> requirements
> > of the respective platform extension.
> >
>
> ... except for the things that are optional?
>
>
> Mark and I talked about this already today and we are in agreement that
>
> * we need an escape valve (and space for individual innovation)
> * consider the cost of requirements (including the self-certification
> testing)
> * ensure interoperability
>
> With the current model, we have covered all three.
>
What model is this? Are you referring to the current ad hoc structure
of the Platform specification that is not yet documented? Will it be
documented?
All of these are documented in the platform policy document that will be released shortly. This document is undergoing reviews currently.
I would like to note that with the document structure that I proposed
yesterday, I was not intending to change what was being represented by
the Platform Specification at all. I was suggesting a way to represent
what I understood to be the intent of the specification in a way that I
thought would be clearer for the reader, easier to maintain, and in fact
better suit the goals you just listed above. I am certainly willing to
accept that my proposal does not do that adequately, and I will not
pursue my proposal any further. I ask that perhaps you be willing to
consider that the current structure of the specification also does not
necessarily convey your intent in the most effective way.
> Note that I would not equate the 'extensions' to optionality: a 'Linux
> platform
> with the server extension' simply complies to its base specification and the
> add-on requirements. Extensions are targeting wider markets (e.g. server,
> automotive, mobile) and each extension requires additional features.
>
> Just because it is optional if someone wants to claim compatibility with any
> of the extensions, there is no optionality within the requirements of the
> extension itself.
>
> I hope this is clearer at this point...
>
Not so much.
> > The goal for the platform specifications is to create a common
> > interoperability specification: i.e. if a device is compatible and a
> > software-distribution is compatible, then there is no fine-print or
> > wiggle-room for interoperability. Any device implementation may
> offer
> > additional, discoverable features and any software implementation
> may
> > offer optimized support for any such discovered features.
> >
> > Note that in the previous discussion "optional" actually specifies
> > "required":
> >
> > * "Feature A is optional" => "Software MUST support devices
> that (a)
> > implement Feature A, or (b) don't implement Feature A."
> > * "Feature A is optional. If it exists, Requirement A.1 [e.g.
> > "optimized support for A"] needs to be satisfied" =>
> "Software MUST
> > support devices that (a) implement Feature A, or (b) don't
> implement
> > Feature A. On devices implementing Feature A, software MUST
> > implement Requirement A.1."
> >
>
> I understand the rationale, and seems fairly reasonable, but also seems
> to directly contradict what Kumar stated yesterday.
>
>
> My wording may have been a bit confusing, but I already talked to Kumar
> earlier and there has been no disagreement, except a difference in wording.
> I will again talk to him later and let him work on the official wording.
> Philipp.
Philipp's comment above in the paragraph that starts with
"Not that in the previous discussion..." was meant to indicate what
would happen in case we use the "optional" clause in the spec.
He wanted to provide an example of "optional" and
the additional complexity it would add from a compliance perspective and we
wish to avoid that. These statements are NOT contradicting what I said before
but inline with our goal of not listing "optional" features in the
spec and limit the spec to "required" features only.
Hope this clarifies things.
--
--
|
|
|
Kumar Sankaran
On Wed, Apr 28, 2021 at 11:10 AM Greg Favor < gfavor@...> wrote: Philipp and Kumar,
I haven't looked over the Platform Policy doc (if I got the name right), but won't it address these high-level generic matters that apply to all platform specs?
Greg
Yes, all the issues being discussed in this thread regarding the platform spec documentation structure are covered in the platform policy document.
On Wed, Apr 28, 2021 at 8:59 AM Darius Rad < darius@...> wrote: On 4/28/21 11:30 AM, Philipp Tomsich wrote:
>
>
> On Wed, Apr 28, 2021 at 5:03 PM Darius Rad <darius@...
> <mailto:darius@...>> wrote:
>
> On 4/28/21 8:54 AM, Philipp Tomsich wrote:
> > Here a short summary of some of the discussions that went on in the
> > early weeks of the year.
> > I hope this helps to clarify rather than compounding the confusion...
> >
> > In order to provide interoperability within platforms, there is no
> > optionality within each platform.
> > Implementations are allowed to do whatever they want outside of the
> > requirements, though.
> >
>
> So nothing is optional ...
>
> > However, we provide for some "managed optionality" through the
> > extensions: implementations can choose to conform to these in
> addition
> > to the base specification if they are compatible with all
> requirements
> > of the respective platform extension.
> >
>
> ... except for the things that are optional?
>
>
> Mark and I talked about this already today and we are in agreement that
>
> * we need an escape valve (and space for individual innovation)
> * consider the cost of requirements (including the self-certification
> testing)
> * ensure interoperability
>
> With the current model, we have covered all three.
>
What model is this? Are you referring to the current ad hoc structure
of the Platform specification that is not yet documented? Will it be
documented?
All of these are documented in the platform policy document that will be released shortly. This document is undergoing reviews currently.
I would like to note that with the document structure that I proposed
yesterday, I was not intending to change what was being represented by
the Platform Specification at all. I was suggesting a way to represent
what I understood to be the intent of the specification in a way that I
thought would be clearer for the reader, easier to maintain, and in fact
better suit the goals you just listed above. I am certainly willing to
accept that my proposal does not do that adequately, and I will not
pursue my proposal any further. I ask that perhaps you be willing to
consider that the current structure of the specification also does not
necessarily convey your intent in the most effective way.
> Note that I would not equate the 'extensions' to optionality: a 'Linux
> platform
> with the server extension' simply complies to its base specification and the
> add-on requirements. Extensions are targeting wider markets (e.g. server,
> automotive, mobile) and each extension requires additional features.
>
> Just because it is optional if someone wants to claim compatibility with any
> of the extensions, there is no optionality within the requirements of the
> extension itself.
>
> I hope this is clearer at this point...
>
Not so much.
> > The goal for the platform specifications is to create a common
> > interoperability specification: i.e. if a device is compatible and a
> > software-distribution is compatible, then there is no fine-print or
> > wiggle-room for interoperability. Any device implementation may
> offer
> > additional, discoverable features and any software implementation
> may
> > offer optimized support for any such discovered features.
> >
> > Note that in the previous discussion "optional" actually specifies
> > "required":
> >
> > * "Feature A is optional" => "Software MUST support devices
> that (a)
> > implement Feature A, or (b) don't implement Feature A."
> > * "Feature A is optional. If it exists, Requirement A.1 [e.g.
> > "optimized support for A"] needs to be satisfied" =>
> "Software MUST
> > support devices that (a) implement Feature A, or (b) don't
> implement
> > Feature A. On devices implementing Feature A, software MUST
> > implement Requirement A.1."
> >
>
> I understand the rationale, and seems fairly reasonable, but also seems
> to directly contradict what Kumar stated yesterday.
>
>
> My wording may have been a bit confusing, but I already talked to Kumar
> earlier and there has been no disagreement, except a difference in wording.
> I will again talk to him later and let him work on the official wording.
> Philipp.
--
|
|
|
Philipp and Kumar,
I haven't looked over the Platform Policy doc (if I got the name right), but won't it address these high-level generic matters that apply to all platform specs?
Greg
On Wed, Apr 28, 2021 at 8:59 AM Darius Rad < darius@...> wrote: On 4/28/21 11:30 AM, Philipp Tomsich wrote:
>
>
> On Wed, Apr 28, 2021 at 5:03 PM Darius Rad <darius@...
> <mailto:darius@...>> wrote:
>
> On 4/28/21 8:54 AM, Philipp Tomsich wrote:
> > Here a short summary of some of the discussions that went on in the
> > early weeks of the year.
> > I hope this helps to clarify rather than compounding the confusion...
> >
> > In order to provide interoperability within platforms, there is no
> > optionality within each platform.
> > Implementations are allowed to do whatever they want outside of the
> > requirements, though.
> >
>
> So nothing is optional ...
>
> > However, we provide for some "managed optionality" through the
> > extensions: implementations can choose to conform to these in
> addition
> > to the base specification if they are compatible with all
> requirements
> > of the respective platform extension.
> >
>
> ... except for the things that are optional?
>
>
> Mark and I talked about this already today and we are in agreement that
>
> * we need an escape valve (and space for individual innovation)
> * consider the cost of requirements (including the self-certification
> testing)
> * ensure interoperability
>
> With the current model, we have covered all three.
>
What model is this? Are you referring to the current ad hoc structure
of the Platform specification that is not yet documented? Will it be
documented?
I would like to note that with the document structure that I proposed
yesterday, I was not intending to change what was being represented by
the Platform Specification at all. I was suggesting a way to represent
what I understood to be the intent of the specification in a way that I
thought would be clearer for the reader, easier to maintain, and in fact
better suit the goals you just listed above. I am certainly willing to
accept that my proposal does not do that adequately, and I will not
pursue my proposal any further. I ask that perhaps you be willing to
consider that the current structure of the specification also does not
necessarily convey your intent in the most effective way.
> Note that I would not equate the 'extensions' to optionality: a 'Linux
> platform
> with the server extension' simply complies to its base specification and the
> add-on requirements. Extensions are targeting wider markets (e.g. server,
> automotive, mobile) and each extension requires additional features.
>
> Just because it is optional if someone wants to claim compatibility with any
> of the extensions, there is no optionality within the requirements of the
> extension itself.
>
> I hope this is clearer at this point...
>
Not so much.
> > The goal for the platform specifications is to create a common
> > interoperability specification: i.e. if a device is compatible and a
> > software-distribution is compatible, then there is no fine-print or
> > wiggle-room for interoperability. Any device implementation may
> offer
> > additional, discoverable features and any software implementation
> may
> > offer optimized support for any such discovered features.
> >
> > Note that in the previous discussion "optional" actually specifies
> > "required":
> >
> > * "Feature A is optional" => "Software MUST support devices
> that (a)
> > implement Feature A, or (b) don't implement Feature A."
> > * "Feature A is optional. If it exists, Requirement A.1 [e.g.
> > "optimized support for A"] needs to be satisfied" =>
> "Software MUST
> > support devices that (a) implement Feature A, or (b) don't
> implement
> > Feature A. On devices implementing Feature A, software MUST
> > implement Requirement A.1."
> >
>
> I understand the rationale, and seems fairly reasonable, but also seems
> to directly contradict what Kumar stated yesterday.
>
>
> My wording may have been a bit confusing, but I already talked to Kumar
> earlier and there has been no disagreement, except a difference in wording.
> I will again talk to him later and let him work on the official wording.
> Philipp.
|
|
|
On 4/28/21 11:30 AM, Philipp Tomsich wrote: On Wed, Apr 28, 2021 at 5:03 PM Darius Rad <darius@... <mailto:darius@...>> wrote:
On 4/28/21 8:54 AM, Philipp Tomsich wrote:
> Here a short summary of some of the discussions that went on in the
> early weeks of the year.
> I hope this helps to clarify rather than compounding the confusion...
>
> In order to provide interoperability within platforms, there is no
> optionality within each platform.
> Implementations are allowed to do whatever they want outside of the
> requirements, though.
>
So nothing is optional ...
> However, we provide for some "managed optionality" through the
> extensions: implementations can choose to conform to these in
addition
> to the base specification if they are compatible with all
requirements
> of the respective platform extension.
>
... except for the things that are optional?
Mark and I talked about this already today and we are in agreement that
* we need an escape valve (and space for individual innovation)
* consider the cost of requirements (including the self-certification
testing)
* ensure interoperability
With the current model, we have covered all three.
What model is this? Are you referring to the current ad hoc structure of the Platform specification that is not yet documented? Will it be documented? I would like to note that with the document structure that I proposed yesterday, I was not intending to change what was being represented by the Platform Specification at all. I was suggesting a way to represent what I understood to be the intent of the specification in a way that I thought would be clearer for the reader, easier to maintain, and in fact better suit the goals you just listed above. I am certainly willing to accept that my proposal does not do that adequately, and I will not pursue my proposal any further. I ask that perhaps you be willing to consider that the current structure of the specification also does not necessarily convey your intent in the most effective way. Note that I would not equate the 'extensions' to optionality: a 'Linux platform
with the server extension' simply complies to its base specification and the
add-on requirements. Extensions are targeting wider markets (e.g. server,
automotive, mobile) and each extension requires additional features.
Just because it is optional if someone wants to claim compatibility with any
of the extensions, there is no optionality within the requirements of the
extension itself.
I hope this is clearer at this point...
Not so much. > The goal for the platform specifications is to create a common
> interoperability specification: i.e. if a device is compatible and a
> software-distribution is compatible, then there is no fine-print or
> wiggle-room for interoperability. Any device implementation may
offer
> additional, discoverable features and any software implementation
may
> offer optimized support for any such discovered features.
>
> Note that in the previous discussion "optional" actually specifies
> "required":
>
> * "Feature A is optional" => "Software MUST support devices
that (a)
> implement Feature A, or (b) don't implement Feature A."
> * "Feature A is optional. If it exists, Requirement A.1 [e.g.
> "optimized support for A"] needs to be satisfied" =>
"Software MUST
> support devices that (a) implement Feature A, or (b) don't
implement
> Feature A. On devices implementing Feature A, software MUST
> implement Requirement A.1."
>
I understand the rationale, and seems fairly reasonable, but also seems
to directly contradict what Kumar stated yesterday.
My wording may have been a bit confusing, but I already talked to Kumar
earlier and there has been no disagreement, except a difference in wording.
I will again talk to him later and let him work on the official wording.
Philipp.
|
|
|
On Wed, Apr 28, 2021 at 5:03 PM Darius Rad < darius@...> wrote: On 4/28/21 8:54 AM, Philipp Tomsich wrote:
> Here a short summary of some of the discussions that went on in the
> early weeks of the year.
> I hope this helps to clarify rather than compounding the confusion...
>
> In order to provide interoperability within platforms, there is no
> optionality within each platform.
> Implementations are allowed to do whatever they want outside of the
> requirements, though.
>
So nothing is optional ...
> However, we provide for some "managed optionality" through the
> extensions: implementations can choose to conform to these in addition
> to the base specification if they are compatible with all requirements
> of the respective platform extension.
>
... except for the things that are optional?
Mark and I talked about this already today and we are in agreement that - we need an escape valve (and space for individual innovation)
- consider the cost of requirements (including the self-certification testing)
- ensure interoperability
With the current model, we have covered all three.
Note that I would not equate the 'extensions' to optionality: a 'Linux platform with the server extension' simply complies to its base specification and the add-on requirements. Extensions are targeting wider markets (e.g. server, automotive, mobile) and each extension requires additional features.
Just because it is optional if someone wants to claim compatibility with any of the extensions, there is no optionality within the requirements of the extension itself.
I hope this is clearer at this point...
> The goal for the platform specifications is to create a common
> interoperability specification: i.e. if a device is compatible and a
> software-distribution is compatible, then there is no fine-print or
> wiggle-room for interoperability. Any device implementation may offer
> additional, discoverable features and any software implementation may
> offer optimized support for any such discovered features.
>
> Note that in the previous discussion "optional" actually specifies
> "required":
>
> * "Feature A is optional" => "Software MUST support devices that (a)
> implement Feature A, or (b) don't implement Feature A."
> * "Feature A is optional. If it exists, Requirement A.1 [e.g.
> "optimized support for A"] needs to be satisfied" => "Software MUST
> support devices that (a) implement Feature A, or (b) don't implement
> Feature A. On devices implementing Feature A, software MUST
> implement Requirement A.1."
>
I understand the rationale, and seems fairly reasonable, but also seems
to directly contradict what Kumar stated yesterday.
My wording may have been a bit confusing, but I already talked to Kumar earlier and there has been no disagreement, except a difference in wording. I will again talk to him later and let him work on the official wording. Philipp.
|
|
|
On 4/28/21 8:54 AM, Philipp Tomsich wrote: Here a short summary of some of the discussions that went on in the early weeks of the year.
I hope this helps to clarify rather than compounding the confusion...
In order to provide interoperability within platforms, there is no optionality within each platform.
Implementations are allowed to do whatever they want outside of the requirements, though.
So nothing is optional ... However, we provide for some "managed optionality" through the extensions: implementations can choose to conform to these in addition to the base specification if they are compatible with all requirements of the respective platform extension.
... except for the things that are optional? The goal for the platform specifications is to create a common interoperability specification: i.e. if a device is compatible and a software-distribution is compatible, then there is no fine-print or wiggle-room for interoperability. Any device implementation may offer additional, discoverable features and any software implementation may offer optimized support for any such discovered features.
Note that in the previous discussion "optional" actually specifies "required":
* "Feature A is optional" => "Software MUST support devices that (a)
implement Feature A, or (b) don't implement Feature A."
* "Feature A is optional. If it exists, Requirement A.1 [e.g.
"optimized support for A"] needs to be satisfied" => "Software MUST
support devices that (a) implement Feature A, or (b) don't implement
Feature A. On devices implementing Feature A, software MUST
implement Requirement A.1."
I understand the rationale, and seems fairly reasonable, but also seems to directly contradict what Kumar stated yesterday. So the more meta question which I asked earlier, is this task group planning to define what a _Platform_ is, with clear and specific terminology on how to subsequently define a particular Platform? I thought so, but perhaps I am mistaken. Philipp.
On Wed, Apr 28, 2021 at 2:33 PM mark <markhimelstein@... <mailto:markhimelstein@...>> wrote:
to me optional for platform means "if it is there you have to
support it, if it is not there you do not. you may be platform
compatible either way. support only means support (like for context
switches) but does not mean use well (like having the optimizer
exploit it)."
platform required means to me "if it is not there then this is not a
compatible. if you expect it to be there and it is not then the
platform should fail on boot gracefully and with a meaningful message."
obviously some of what i wrote above would be a non sequitur for
profiles.
Mark
--------
sent from a mobile device. please forgive any typos.
On Apr 27, 2021, at 10:28 PM, Greg Favor <gfavor@...
<mailto:gfavor@...>> wrote:
On Tue, Apr 27, 2021 at 10:22 PM Allen Baum
<allen.baum@...
<mailto:allen.baum@...>> wrote:
RE: - All Features are implicitly optional, so all use of
the term "optional" can be removed to avoid confusion.
I don't think this is correct. Optional implies the OS is
aware of and will save extension state on contect switches, or
so I have been led to believe.
This is true for the definition of "optional" in an ISA profile
spec (i.e. an optional feature must still be supported by
OS/hyp/toolchain software). But this does not need to be the
definition that a platform spec uses (since it is comprehending
the whole hardware and software picture).
Or put differently, if "optional" means that system software may
or may not support the feature, then that's not much better than
"unsupported" from an application's or hardware system's
perspective. And if "optional" means that system software must
support the feature, then that's no different than "required".
Greg
|
|
|
Here a short summary of some of the discussions that went on in the early weeks of the year. I hope this helps to clarify rather than compounding the confusion...
In order to provide interoperability within platforms, there is no optionality within each platform.
Implementations are allowed to do whatever they want outside of the requirements, though. However, we provide for some "managed optionality" through the extensions: implementations can choose to conform to these in addition to the base specification if they are compatible with all requirements of the respective platform extension.
The goal for the platform specifications is to create a common interoperability specification: i.e. if a device is compatible and a software-distribution is compatible, then there is no fine-print or wiggle-room for interoperability. Any device implementation may offer additional, discoverable features and any software implementation may offer optimized support for any such discovered features.
Note that in the previous discussion "optional" actually specifies "required": - "Feature A is optional" => "Software MUST support devices that (a) implement Feature A, or (b) don't implement Feature A."
- "Feature A is optional. If it exists, Requirement A.1 [e.g. "optimized support for A"] needs to be satisfied" => "Software MUST support devices that (a) implement Feature A, or (b) don't implement Feature A. On devices implementing Feature A, software MUST implement Requirement A.1."
Philipp.
to me optional for platform means "if it is there you have to support it, if it is not there you do not. you may be platform compatible either way. support only means support (like for context switches) but does not mean use well (like having the optimizer exploit it)."
platform required means to me "if it is not there then this is not a compatible. if you expect it to be there and it is not then the platform should fail on boot gracefully and with a meaningful message."
obviously some of what i wrote above would be a non sequitur for profiles.
Mark -------- sent from a mobile device. please forgive any typos. On Apr 27, 2021, at 10:28 PM, Greg Favor <gfavor@...> wrote:
RE: - All Features are implicitly optional, so all use of the term "optional" can be removed to avoid confusion. I don't think this is correct. Optional implies the OS is aware of and will save extension state on contect switches, or so I have been led to believe.
This is true for the definition of "optional" in an ISA profile spec (i.e. an optional feature must still be supported by OS/hyp/toolchain software). But this does not need to be the definition that a platform spec uses (since it is comprehending the whole hardware and software picture).
Or put differently, if "optional" means that system software may or may not support the feature, then that's not much better than "unsupported" from an application's or hardware system's perspective. And if "optional" means that system software must support the feature, then that's no different than "required".
Greg
|
|
|
mark
to me optional for platform means "if it is there you have to support it, if it is not there you do not. you may be platform compatible either way. support only means support (like for context switches) but does not mean use well (like having the optimizer exploit it)."
platform required means to me "if it is not there then this is not a compatible. if you expect it to be there and it is not then the platform should fail on boot gracefully and with a meaningful message."
obviously some of what i wrote above would be a non sequitur for profiles.
Mark -------- sent from a mobile device. please forgive any typos.
On Apr 27, 2021, at 10:28 PM, Greg Favor <gfavor@...> wrote:
RE: - All Features are implicitly optional, so all use of the term "optional" can be removed to avoid confusion. I don't think this is correct. Optional implies the OS is aware of and will save extension state on contect switches, or so I have been led to believe.
This is true for the definition of "optional" in an ISA profile spec (i.e. an optional feature must still be supported by OS/hyp/toolchain software). But this does not need to be the definition that a platform spec uses (since it is comprehending the whole hardware and software picture).
Or put differently, if "optional" means that system software may or may not support the feature, then that's not much better than "unsupported" from an application's or hardware system's perspective. And if "optional" means that system software must support the feature, then that's no different than "required".
Greg
|
|
|
On 4/28/21 1:27 AM, Greg Favor wrote: On Tue, Apr 27, 2021 at 10:22 PM Allen Baum <allen.baum@... <mailto:allen.baum@...>> wrote:
RE: - All Features are implicitly optional, so all use of the term
"optional" can be removed to avoid confusion.
I don't think this is correct. Optional implies the OS is aware of
and will save extension state on contect switches, or so I have been
led to believe.
This is true for the definition of "optional" in an ISA profile spec (i.e. an optional feature must still be supported by OS/hyp/toolchain software). But this does not need to be the definition that a platform spec uses (since it is comprehending the whole hardware and software picture).
Indeed. Or put differently, if "optional" means that system software may or may not support the feature, then that's not much better than "unsupported" from an application's or hardware system's perspective. And if "optional" means that system software must support the feature, then that's no different than "required".
I think the meaning of the terms "optional" and "required" are different whether one is talking from the perspective of software or hardware. It is my understanding that the Platform is a contract between hardware and software. When there are choices, I think in general the hardware must support *any* of the choices but the software must support *all* of the choices. Certainly there are benefits to having fewer choices. However, it is also perfectly reasonable (even if not desirable) to have software that supports, say, multiple devices of a particular type, and then detect which specific device exists in hardware. This is perhaps another reason why this task group needs to define what a Platform is more clearly, so that it is unambiguous which perspective the specification is directed at: hardware or software. Greg
|
|
|
On 4/27/21 7:14 PM, Kumar Sankaran wrote: Hi Darius,
Firstly, the purpose of the platform spec is to define a *minimal *set of *"Required" *features that will be needed to define a platform or an extension.
By this definition, all requirements within the spec will be "Required". We used the word "Mandatory" before, but we will change that to "Required".
We don't specify any "Optional" features in the spec. If a feature is optional, it is not mandatory for compliance and hence will not be defined in the spec. My understanding is that scope of this task group is to define what a Platform is, as well as defining a small number of specific Platform. I was expecting the definition of a Platform to impose a structure or set of constraints on how each Platform itself is defined. I don't see where that has been defined, but perhaps I misunderstand the goals of this task group. With respect to the Platform themselves, I understand the desire to make them composed of a minimal set of features and would like to think that can be achieved in a reasonable way. However, it seems people have varying opinions of what "minimal" means, both in terms of scope and specific content. Given the current direction of the specification, it is reasonable to expect that I will be in a position of having to explain to others how, for example, it is possible to run Linux on a Platform with *fewer* than the minimal set of features, as contradictory as that sounds. I would prefer, and would have thought this should be possible, that I could describe such a system using concise terminology established by this task group, rather than simply copying an entire document and hacking it apart. There is another category we are proposing of "Deprecated" which means, that particular feature will be "Required" for this version of the spec but is expected to be removed in the next major version of the spec which is 2-years later.
This gives platforms enough time to remove that particular deprecated feature in the next version of their platform or chip.
Regarding an earlier email thread from Abner about extensions,
Extensions are add-ons to the base spec. The names used for extension define which target market category the extension is defined for.
Right now, we are only defining the "server" extension for the Linux-2022 platform. By definition, an extension will support all of the features in the base specification with overrides.
In future, we might define more extensions like "automotive", "mobile", "edge" and more. Each of these extensions will have selected features that are needed for that particular target market.
There might be overlap between features for extensions because both target markets might need those "Required" features.
For example, we may have a certain platform claim compliance with both the "server" extension and "automotive" extension because it supports all the features for both of those extensions.
On Tue, Apr 27, 2021 at 10:02 AM Darius Rad <darius@... <mailto:darius@...>> wrote:
I would like to make a suggestion regarding the organization and
structure of the Platform Specification that I think might make it
easier to understand and eliminate some of the ambiguity around
recommended and optional features.
The draft document as it stands defines each profile monolithically.
There are two major chapters, one for each profile (Linux, Embedded).
Each chapter contains various sections for different features.
I propose splitting the document into two parts. The first part would
be a definition of "Features". A Feature would correspond roughly to
what is in a section now (Interrupt Controller, Serial Console, etc.),
but would be clearly delineated as a separable unit. The second
part of
the document would be definitions of the Profiles. The Profile
definitions would be much shorter, as they would simply reference the
Features previously defined. Something like: Linux-2022 Platform:
RVA22
Feature, Serial Console Feature, Legacy Interrupt Controller
Feature, etc.
In RISC-V terminology, profiles refer to RVA22, RVM22 and such. Platform calls out to profiles.
Platform would also define extensions as needed.
Indeed, that was my mistake. I meant to say, and am referring to, Platforms here. Structuring the document this way would provide these benefits:
- All Features are implicitly optional, so all use of the term
"optional" can be removed to avoid confusion. If necessary, an
introductory paragraph can explicitly convey that Features are optional.
There is no point in having "optional" features defined in any spec. By definition, an optional feature gives people the liberty to drop it and still claim compliance and this is undesirable.
There should not be any use of the word "*Optional*" in the spec in the context of a requirement.
I respectfully disagree that optional features have no place in a specification. The RISC-V ISA specification defines a number of instructions sets, and essentially all of them are optional. Even with respect to RVA22 and RVM22, the instructions not required within each are effectively optional (e.g., Vector extension is optional in RVM22). - Most or all use of the term "recommends" could also be removed.
The term "Recommends" is used for two slightly different meanings: (1)
"you should include this thing", or (2) "if you happen to include this
thing, do it this way". Definitions of Features will implicitly cover
the latter meaning. It is perhaps debatable if the former meaning
belongs in the document at all.
Yes, for the Embedded-2022 platform definition, we currently have "Recommended" in there and it is confusing since "Recommended" really means "Optional". In conversations with Alistair, it was deemed that none of the Embedded-2022 features are "Required". Hence, we decided to pull in that change for now and debate the "Recommended" features later. My opinion here is to make some/all of the Embedded-2022 features "Required".
Let's not use "Recommended" or "Optional" in any patch going forward.
- It is more straightforward to create a custom (or vendor
specific)
Profile by referencing a unique combination of standard Features, or a
defining custom Features and referring to a mix of standard and custom
Features. (With the current document, the only clear way to create a
custom Profile is to copy the entire document and edit it, which makes
it difficult for the reader to see how the new profile may differ from
standard profiles.)
Vendor specific profiles are beyond the scope of the Platform spec. Our goal is to create a common spec that hardware and software can interoperate with.
I am not sure what you mean by out of scope. I do not expect that the Platform Specification would define vendor specific Platforms, but I would have expected that the definition of a Platform would have provisions for defining vendor specific Platform (by others). Consider the ISA specification, which has certain portions set aside for vendor use and certain terminology defined for the definition of vendor extensions (e.g., Xwhatever extension). - The currently defined Extensions could simply be defined as
Features, which are implicitly optional.
As I mentioned above, there is no point in having an optional feature in the spec.
And yet the Extensions themselves are optional? - This would eliminate some duplication between the Linux and
Embedded Profiles, as they are both currently written independently.
Feature definitions make sharing sections more flexible than trying to
force both (and other, future Profiles) from being a strict superset of
a single Base Profile.
If there is duplication between the Linux and Embedded platforms, that's fine as they are totally independent and not related to each other.
I disagree that this is fine. It may be technically sufficient to define a Platform. However, I think it will cause unnecessary duplication of content, make the specifications less clear for readers, and harder to maintain, particularly as more standard (and custom) Platforms are defined in the future. I would be glad to submit a patch or pull request restructuring the
current document in the form described above if that would help convey
the idea and facilitate discussion.
// darius
--
Regards
Kumar
|
|
|
RE: - All Features are implicitly optional, so all use of the term "optional" can be removed to avoid confusion. I don't think this is correct. Optional implies the OS is aware of and will save extension state on contect switches, or so I have been led to believe.
This is true for the definition of "optional" in an ISA profile spec (i.e. an optional feature must still be supported by OS/hyp/toolchain software). But this does not need to be the definition that a platform spec uses (since it is comprehending the whole hardware and software picture).
Or put differently, if "optional" means that system software may or may not support the feature, then that's not much better than "unsupported" from an application's or hardware system's perspective. And if "optional" means that system software must support the feature, then that's no different than "required".
Greg
|
|
|
Allen Baum
RE: - All Features are implicitly optional, so all use of the term "optional" can be removed to avoid confusion. I don't think this is correct. Optional implies the OS is aware of and will save extension state on contect switches, or so I have been led to believe. If not listed, and present - it could very well be totally broken, and so should not be used.
On Tue, Apr 27, 2021 at 10:02 AM Darius Rad < darius@...> wrote: I would like to make a suggestion regarding the organization and
structure of the Platform Specification that I think might make it
easier to understand and eliminate some of the ambiguity around
recommended and optional features.
The draft document as it stands defines each profile monolithically.
There are two major chapters, one for each profile (Linux, Embedded).
Each chapter contains various sections for different features.
I propose splitting the document into two parts. The first part would
be a definition of "Features". A Feature would correspond roughly to
what is in a section now (Interrupt Controller, Serial Console, etc.),
but would be clearly delineated as a separable unit. The second part of
the document would be definitions of the Profiles. The Profile
definitions would be much shorter, as they would simply reference the
Features previously defined. Something like: Linux-2022 Platform: RVA22
Feature, Serial Console Feature, Legacy Interrupt Controller Feature, etc.
Structuring the document this way would provide these benefits:
- All Features are implicitly optional, so all use of the term
"optional" can be removed to avoid confusion. If necessary, an
introductory paragraph can explicitly convey that Features are optional.
- Most or all use of the term "recommends" could also be removed.
The term "Recommends" is used for two slightly different meanings: (1)
"you should include this thing", or (2) "if you happen to include this
thing, do it this way". Definitions of Features will implicitly cover
the latter meaning. It is perhaps debatable if the former meaning
belongs in the document at all.
- It is more straightforward to create a custom (or vendor specific)
Profile by referencing a unique combination of standard Features, or a
defining custom Features and referring to a mix of standard and custom
Features. (With the current document, the only clear way to create a
custom Profile is to copy the entire document and edit it, which makes
it difficult for the reader to see how the new profile may differ from
standard profiles.)
- The currently defined Extensions could simply be defined as
Features, which are implicitly optional.
- This would eliminate some duplication between the Linux and
Embedded Profiles, as they are both currently written independently.
Feature definitions make sharing sections more flexible than trying to
force both (and other, future Profiles) from being a strict superset of
a single Base Profile.
I would be glad to submit a patch or pull request restructuring the
current document in the form described above if that would help convey
the idea and facilitate discussion.
// darius
|
|
|
Kumar Sankaran
Hi Darius, Firstly, the purpose of the platform spec is to define a minimal set of "Required" features that will be needed to define a platform or an extension. By this definition, all requirements within the spec will be "Required". We used the word "Mandatory" before, but we will change that to "Required". We don't specify any "Optional" features in the spec. If a feature is optional, it is not mandatory for compliance and hence will not be defined in the spec. There is another category we are proposing of "Deprecated" which means, that particular feature will be "Required" for this version of the spec but is expected to be removed in the next major version of the spec which is 2-years later. This gives platforms enough time to remove that particular deprecated feature in the next version of their platform or chip.
Regarding an earlier email thread from Abner about extensions, Extensions are add-ons to the base spec. The names used for extension define which target market category the extension is defined for. Right now, we are only defining the "server" extension for the Linux-2022 platform. By definition, an extension will support all of the features in the base specification with overrides. In future, we might define more extensions like "automotive", "mobile", "edge" and more. Each of these extensions will have selected features that are needed for that particular target market. There might be overlap between features for extensions because both target markets might need those "Required" features. For example, we may have a certain platform claim compliance with both the "server" extension and "automotive" extension because it supports all the features for both of those extensions. On Tue, Apr 27, 2021 at 10:02 AM Darius Rad < darius@...> wrote: I would like to make a suggestion regarding the organization and
structure of the Platform Specification that I think might make it
easier to understand and eliminate some of the ambiguity around
recommended and optional features.
The draft document as it stands defines each profile monolithically.
There are two major chapters, one for each profile (Linux, Embedded).
Each chapter contains various sections for different features.
I propose splitting the document into two parts. The first part would
be a definition of "Features". A Feature would correspond roughly to
what is in a section now (Interrupt Controller, Serial Console, etc.),
but would be clearly delineated as a separable unit. The second part of
the document would be definitions of the Profiles. The Profile
definitions would be much shorter, as they would simply reference the
Features previously defined. Something like: Linux-2022 Platform: RVA22
Feature, Serial Console Feature, Legacy Interrupt Controller Feature, etc.
In RISC-V terminology, profiles refer to RVA22, RVM22 and such. Platform calls out to profiles. Platform would also define extensions as needed.
Structuring the document this way would provide these benefits:
- All Features are implicitly optional, so all use of the term
"optional" can be removed to avoid confusion. If necessary, an
introductory paragraph can explicitly convey that Features are optional.
There is no point in having "optional" features defined in any spec. By definition, an optional feature gives people the liberty to drop it and still claim compliance and this is undesirable. There should not be any use of the word "Optional" in the spec in the context of a requirement.
- Most or all use of the term "recommends" could also be removed.
The term "Recommends" is used for two slightly different meanings: (1)
"you should include this thing", or (2) "if you happen to include this
thing, do it this way". Definitions of Features will implicitly cover
the latter meaning. It is perhaps debatable if the former meaning
belongs in the document at all.
Yes, for the Embedded-2022 platform definition, we currently have "Recommended" in there and it is confusing since "Recommended" really means "Optional". In conversations with Alistair, it was deemed that none of the Embedded-2022 features are "Required". Hence, we decided to pull in that change for now and debate the "Recommended" features later. My opinion here is to make some/all of the Embedded-2022 features "Required". Let's not use "Recommended" or "Optional" in any patch going forward.
- It is more straightforward to create a custom (or vendor specific)
Profile by referencing a unique combination of standard Features, or a
defining custom Features and referring to a mix of standard and custom
Features. (With the current document, the only clear way to create a
custom Profile is to copy the entire document and edit it, which makes
it difficult for the reader to see how the new profile may differ from
standard profiles.)
Vendor specific profiles are beyond the scope of the Platform spec. Our goal is to create a common spec that hardware and software can interoperate with.
- The currently defined Extensions could simply be defined as
Features, which are implicitly optional.
As I mentioned above, there is no point in having an optional feature in the spec.
- This would eliminate some duplication between the Linux and
Embedded Profiles, as they are both currently written independently.
Feature definitions make sharing sections more flexible than trying to
force both (and other, future Profiles) from being a strict superset of
a single Base Profile.
If there is duplication between the Linux and Embedded platforms, that's fine as they are totally independent and not related to each other.
I would be glad to submit a patch or pull request restructuring the
current document in the form described above if that would help convey
the idea and facilitate discussion.
// darius
--
|
|
|
I would like to make a suggestion regarding the organization and structure of the Platform Specification that I think might make it easier to understand and eliminate some of the ambiguity around recommended and optional features.
The draft document as it stands defines each profile monolithically. There are two major chapters, one for each profile (Linux, Embedded). Each chapter contains various sections for different features.
I propose splitting the document into two parts. The first part would be a definition of "Features". A Feature would correspond roughly to what is in a section now (Interrupt Controller, Serial Console, etc.), but would be clearly delineated as a separable unit. The second part of the document would be definitions of the Profiles. The Profile definitions would be much shorter, as they would simply reference the Features previously defined. Something like: Linux-2022 Platform: RVA22 Feature, Serial Console Feature, Legacy Interrupt Controller Feature, etc.
Structuring the document this way would provide these benefits:
- All Features are implicitly optional, so all use of the term "optional" can be removed to avoid confusion. If necessary, an introductory paragraph can explicitly convey that Features are optional.
- Most or all use of the term "recommends" could also be removed. The term "Recommends" is used for two slightly different meanings: (1) "you should include this thing", or (2) "if you happen to include this thing, do it this way". Definitions of Features will implicitly cover the latter meaning. It is perhaps debatable if the former meaning belongs in the document at all.
- It is more straightforward to create a custom (or vendor specific) Profile by referencing a unique combination of standard Features, or a defining custom Features and referring to a mix of standard and custom Features. (With the current document, the only clear way to create a custom Profile is to copy the entire document and edit it, which makes it difficult for the reader to see how the new profile may differ from standard profiles.)
- The currently defined Extensions could simply be defined as Features, which are implicitly optional.
- This would eliminate some duplication between the Linux and Embedded Profiles, as they are both currently written independently. Feature definitions make sharing sections more flexible than trying to force both (and other, future Profiles) from being a strict superset of a single Base Profile.
I would be glad to submit a patch or pull request restructuring the current document in the form described above if that would help convey the idea and facilitate discussion.
// darius
|
|
|
