The FUSA folder is expected to contain requirements and other documents
to enable safety certification of Xen hypervisor.
Added a README to explain how the requirements are categorized, written
and their supported status.
Added maintainers for the same.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
MAINTAINERS | 9 +++++
docs/fusa/reqs/README.md | 75 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 84 insertions(+)
create mode 100644 docs/fusa/reqs/README.md
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c524a8a93..0d328e065c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -314,6 +314,15 @@ F: xen/arch/x86/include/asm/x86_*/efi*.h
F: xen/common/efi/
F: xen/include/efi/
+FUSA
+M: Stefano Stabellini <sstabellini@kernel.org>
+M: Bertrand Marquis <bertrand.marquis@arm.com>
+M: Michal Orzel <michal.orzel@amd.com>
+M: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
+M: Artem Mygaiev <artem_mygaiev@epam.com>
+S: Supported
+F: docs/fusa/
+
GDBSX DEBUGGER
M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
S: Supported
diff --git a/docs/fusa/reqs/README.md b/docs/fusa/reqs/README.md
new file mode 100644
index 0000000000..69b8d3a5c8
--- /dev/null
+++ b/docs/fusa/reqs/README.md
@@ -0,0 +1,75 @@
+This folder contains a set of requirements describing Xen and its implementation
+in a form suitable for a safety certification process.
+The status is experimental and it is maintained on a best effort basis.
+
+The requirements writing style is inspired from the ANSI/IEEE guide to Software
+Requirements Standard 830-1984.
+
+The requirements are categorized as follows :-
+
+1. Market requirements - They define the high level functionalities of the
+hypervisor without going into concepts specific to Xen. Those should allow a
+system architect to understand wether Xen is providing the functionalities it
+needs for its system. This is the top level of the requirements.
+
+2. Product requirements - They define the Xen specific concepts and interfaces
+provided by Xen without going into implementation details. One or several of
+those requirements are linked to each market requirement. An Architect can use
+them understand how Xen fulfils a market need and design how Xen should be used
+in his system.
+
+3. Design requirements - They describe what the software implementation is doing
+from a technical point of view. One or several design requirement together
+define how product requirements are fulfilled technically and are linked to
+them. An implementer can use them to know how to write or understand the Xen
+code.
+
+The requirements are linked using OpenFastTrace
+(https://github.com/itsallcode/openfasttrace/blob/main/doc/user_guide.md).
+OpenFastTrace parses through the requirements and generates a traceability
+report.
+
+The following is the skeleton for a requirement.
+
+Title /* Title of the requirement */
+-----
+
+`unique_tag`
+/*
+ * Each requirement needs to have a unique tag associated. The format is
+ * req_type~name~revision.
+ *
+ * Thus, it consists of three components :-
+ * requirement type - This denotes the category of requirement. Thus, it shall
+ * be 'XenMkt', 'XenProd' or 'XenSwdgn' to denote market, product or design
+ * requirement.
+ * name - This denotes name of the requirement. In case of architecture specific
+ * requirements, this starts with the architecture type (ie x86_64, arm64).
+ * revision number - This gets incremented each time the requirement is modified.
+ */
+
+Description:
+This shall describe the requirement in a definitive tone. In other words,
+the requirement begins with 'Xen shall ...'. Further, the description is
+expected to be unambiguous and consistent.
+
+Rationale:
+This describes a rationale explaining the reason of the presence of the
+requirement when this can help the reader. This field can be left blank.
+
+Comments:
+This describes the use cases for the requirement when this can help the
+reader. This field can be left blank as well.
+
+Covers:
+This denotes the unique_tag of the parent. This field is non existent for the
+market requirement as it is the top level.
+
+Needs:
+This denotes the requirement type of its children. This field is non existent
+for the design requirements as there are no subsequent requirements linked to
+them.
+
+
+The requirements are expected to the technically correct and follow the above
+guidelines.
--
2.25.1On Wed, 31 Jul 2024, Ayan Kumar Halder wrote: > The FUSA folder is expected to contain requirements and other documents > to enable safety certification of Xen hypervisor. > Added a README to explain how the requirements are categorized, written > and their supported status. > > Added maintainers for the same. > > Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com> > --- > MAINTAINERS | 9 +++++ > docs/fusa/reqs/README.md | 75 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 84 insertions(+) > create mode 100644 docs/fusa/reqs/README.md > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7c524a8a93..0d328e065c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -314,6 +314,15 @@ F: xen/arch/x86/include/asm/x86_*/efi*.h > F: xen/common/efi/ > F: xen/include/efi/ > > +FUSA > +M: Stefano Stabellini <sstabellini@kernel.org> > +M: Bertrand Marquis <bertrand.marquis@arm.com> > +M: Michal Orzel <michal.orzel@amd.com> > +M: Ayan Kumar Halder <ayan.kumar.halder@amd.com> > +M: Artem Mygaiev <artem_mygaiev@epam.com> > +S: Supported > +F: docs/fusa/ > + > GDBSX DEBUGGER > M: Elena Ufimtseva <elena.ufimtseva@oracle.com> > S: Supported > diff --git a/docs/fusa/reqs/README.md b/docs/fusa/reqs/README.md > new file mode 100644 > index 0000000000..69b8d3a5c8 > --- /dev/null > +++ b/docs/fusa/reqs/README.md > @@ -0,0 +1,75 @@ > +This folder contains a set of requirements describing Xen and its implementation > +in a form suitable for a safety certification process. > +The status is experimental and it is maintained on a best effort basis. > + > +The requirements writing style is inspired from the ANSI/IEEE guide to Software > +Requirements Standard 830-1984. I think it would be helpful to mention that they are currently experimental and may be slightly out of sync with the code. We are actively working on a process to keep them updated, more details to follow. > +The requirements are categorized as follows :- > + > +1. Market requirements - They define the high level functionalities of the > +hypervisor without going into concepts specific to Xen. Those should allow a > +system architect to understand wether Xen is providing the functionalities it > +needs for its system. This is the top level of the requirements. > + > +2. Product requirements - They define the Xen specific concepts and interfaces > +provided by Xen without going into implementation details. One or several of > +those requirements are linked to each market requirement. An Architect can use > +them understand how Xen fulfils a market need and design how Xen should be used > +in his system. > + > +3. Design requirements - They describe what the software implementation is doing > +from a technical point of view. One or several design requirement together > +define how product requirements are fulfilled technically and are linked to > +them. An implementer can use them to know how to write or understand the Xen > +code. > + > +The requirements are linked using OpenFastTrace > +(https://github.com/itsallcode/openfasttrace/blob/main/doc/user_guide.md). > +OpenFastTrace parses through the requirements and generates a traceability > +report. > + > +The following is the skeleton for a requirement. > + > +Title /* Title of the requirement */ > +----- > + > +`unique_tag` > +/* > + * Each requirement needs to have a unique tag associated. The format is > + * req_type~name~revision. > + * > + * Thus, it consists of three components :- > + * requirement type - This denotes the category of requirement. Thus, it shall > + * be 'XenMkt', 'XenProd' or 'XenSwdgn' to denote market, product or design > + * requirement. > + * name - This denotes name of the requirement. In case of architecture specific > + * requirements, this starts with the architecture type (ie x86_64, arm64). > + * revision number - This gets incremented each time the requirement is modified. > + */ > + > +Description: > +This shall describe the requirement in a definitive tone. In other words, > +the requirement begins with 'Xen shall ...'. Further, the description is > +expected to be unambiguous and consistent. > + > +Rationale: > +This describes a rationale explaining the reason of the presence of the > +requirement when this can help the reader. This field can be left blank. > + > +Comments: > +This describes the use cases for the requirement when this can help the > +reader. This field can be left blank as well. > + > +Covers: > +This denotes the unique_tag of the parent. This field is non existent for the > +market requirement as it is the top level. > + > +Needs: > +This denotes the requirement type of its children. This field is non existent > +for the design requirements as there are no subsequent requirements linked to > +them. > + > + > +The requirements are expected to the technically correct and follow the above > +guidelines. > -- > 2.25.1 >
Hi Ayan, > On 1 Aug 2024, at 01:46, Stefano Stabellini <sstabellini@kernel.org> wrote: > > On Wed, 31 Jul 2024, Ayan Kumar Halder wrote: >> The FUSA folder is expected to contain requirements and other documents >> to enable safety certification of Xen hypervisor. >> Added a README to explain how the requirements are categorized, written >> and their supported status. >> >> Added maintainers for the same. I think this is a good start and we will revisit the details along the way. >> >> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com> With the comment from Stefano handled: Acked-by: Bertrand Marquis <bertrand.marquis@arm.com> Cheers Bertrand
© 2016 - 2024 Red Hat, Inc.