Is it possible to use cFS without a file system?
Hello, the core Flight System (cFS) is a software platform created by NASA (https://cfs.gsfc.nasa.gov/). It provides essential onboard services for space missions. I would like to use cFS on top of an RTEMS qualified for space by ESA (https://rtems-qual.io.esa.int/). Yet, this qualified RTEMS has no file system. cFS can be configured to be used without IP-networking and with static loader only but I have not found any configuration to disable the file system. Does anyone know whether it is possible to use cFS without a file system or can give advice on using cFS without file system? Of course without file system all applications accessing files will not work. Yet, would at least the core services (such as Executive Service (ES), Software Bus Service (SB), Event Service (EVS), Table Service (TBL), and Time Service (TIME)) be functioning? Greetings and Thanks Frank -- embedded brains GmbH Herr Frank KÜHNDEL Dornierstr. 4 82178 Puchheim Germany email: frank.kuehn...@embedded-brains.de phone: +49-89-18 94 741 - 23 mobile: +49-176-15 22 06 - 11 fax:+49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: Is it possible to use cFS without a file system?
Hi Frank,The cFS uses files for:Loading individual applications. The current build system can link all applications with the cFE core and the OS image avoiding the need for dynamic loading.The cFE Executive Services startup scriptTable service filesAnd as you mention, any cFS application that uses filesThere are some commands and APIs that will not work without a file system such as loading a new application from a file system or dumping a log to a file.The cFE Executive Services also creates a RAM disk upon startup. So, I think modifications will be necessary to use cFS without a file system, but all file system calls go through the OS Abstraction Layer so the cFS does not depend on the host OS file system API. Because of this, a file abstraction could be created that is simple enough for qualification but still allows the cFS to operate as designed. An example is the “EEPROM File System” or EEFS which has been used to boot cFS systems:https://github.com/nasa/eefsThe EEFS has an older RTEMS file system interface, but in your use case, the OSAL would call the EEFS standalone API directly. Note that this public release has not been updated in quite a while. Regards,Alan From: Frank KühndelSent: Thursday, November 24, 2022 5:08 AMTo: devel@rtems.orgSubject: Is it possible to use cFS without a file system? Hello, the core Flight System (cFS) is a software platform created by NASA (https://cfs.gsfc.nasa.gov/). It provides essential onboard services for space missions. I would like to use cFS on top of an RTEMS qualified for space by ESA (https://rtems-qual.io.esa.int/). Yet, this qualified RTEMS has no file system. cFS can be configured to be used without IP-networking and with static loader only but I have not found any configuration to disable the file system. Does anyone know whether it is possible to use cFS without a file system or can give advice on using cFS without file system? Of course without file system all applications accessing files will not work. Yet, would at least the core services (such as Executive Service (ES), Software Bus Service (SB), Event Service (EVS), Table Service (TBL), and Time Service (TIME)) be functioning? Greetings and ThanksFrank -- embedded brains GmbHHerr Frank KÜHNDELDornierstr. 482178 PuchheimGermanyemail: frank.kuehn...@embedded-brains.dephone: +49-89-18 94 741 - 23mobile: +49-176-15 22 06 - 11fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht MünchenRegisternummer: HRB 157899Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas DörflerUnsere Datenschutzerklärung finden Sie hier:https://embedded-brains.de/datenschutzerklaerung/ ___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add Formal Verification chapter v2
Hi Andrew, Hi Gerard, first, thanks for the very comprehensive review below - this feedback is very useful for me. I guess I was overly optimistic last night. The note on the front matter should be resolved before we push the full documentation. I guess it's a bit of chicken-and-egg but the documentation should be pushed concurrent with the software that it documents. So, when there is a `formal` folder in `rtems-central` then it makes sense to push this documentation. I think the documentation is valuable, but I'm not sure how relevant it is without the associated tooling? Ok, should I do a separate "adding formal to RTEMS" patch for this, or merge it with the revisions for this patch set? At this stage it would consist of adding the folder `formal` from the main branch at https://github.com/andrewbutterfield/RTEMS-SMP-Formal The current state of main at RTEMS-SMP-Formal is that is has two new managers added in (Barrier and Messages) and all tests run and pass. This has been recently checked by the team currently doing IV&V on the work we delivered at the end of last year, plus our newer stuff. We probably need to rearrange this section slightly to accommodate the possibility (extant) of other formal verification approaches. I think I'd like to see Sections "9.2 Formal Tools Setup" and 9.4 through the end of the section become nested beneath "9.3 Modelling RTEMS with Promela". Add a new section 9.2 to introduce the different approaches that have/are/might be used to formally verify RTEMS. This will allow alternatives to be documented and acknowledged by the RTEMS Project. Fine - I'll do that . There's a bunch of terminology that is introduced in this chapter without additions to the glossary/index. I think we need some definitions added there to complement the new material. At the very least I would like to see definitions added for the keywords that are defined especially in the introduction: * semantics, formal model, artifact, refinement, LTL Once those are defined, the terms should be linked to the glossary. You can see how this is done for example in Section 5.3.4 Traceability between Software Requirements, Architecture and Design. Glossary definitions can/should link to each other as relevant. OK - I'll do the glossary mods "To avoid using (long) absolute pathnames to the tools directory" ... --> maybe it makes sense for you to provide these as part of the env? Is this stuff using venv or something else? I have a student looking at the python code - he is adding a lot of config related stuff into the testbuilder python scripts. I might ask him to look at adding that into the venv we use. incomplete section header? "need to explain how to configure testbuilder" RTMES typo in that section That's a note to self that I missed - I'll fix that up. In section "9.2.2 Running Test Generation" please add some notion of what is the expected output that one would be checking in the step "use a simulator to run ts-model-0.exe directly." Ok There is overuse of double quotations throughout. Sometimes double quotes are being used to introduce terminology, avoid that. Sometimes double quotes appear in section headings, avoid that. Prefer to use double quotes only for quoting (e.g., from references or tool output). Most cases of the double quotes use in this document should be eliminated. Will do. In section "9.4 Promela to C Refinement" what is the name of the YAML file? Is there more than one, or is it unique. Currently there is one, with a filename based on the model name, in a similar manner to the way that the preamble and postamble files are named. I'll add a reminder here about the naming convention in use. There is a longer term issue to be addressed here as the number of models grows. There will be quite a lot of commonality in the refinement YAML files, and it might make sense to have both general and model-specific files for this. That is future work at present. Some of the text that provides examples of how to do some of this might be suited to a new How-To subsection such as in the end of the "BSP Build System" section. OK In Section "9.6 Test Generation Maintenance" please refer to Section "Software Development Management" instead of hard-coding the patch submission process. Ok Section 9.7 "RTEMS Formal Model Guide" seems like it includes both some aspects of a How-To but also a lot of details that might be better as a separate document specific to the Promela/Verification detailed implementation. The point of the RTEMS Software Engineering manual is to provide developers with the guidelines of how to work with RTEMS. This section is very detailed about the implementation of specific models and feels unbalanced with the rest of the new section. For example, this section is about 3/5 of the entire "Formal Verification" section. I agree - this was what struck me after I had sent the patch set. In a sense I think we need a new top-level document, analagous
[PATCH] libmisc/rtems-fdt: Support prop map items up to the size of uintptr_t
From: Chris Johns
Updates #4729
---
cpukit/libmisc/rtems-fdt/rtems-fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
index e5bab21664..26312ff624 100644
--- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
+++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
@@ -1063,7 +1063,7 @@ rtems_fdt_prop_map(const char* const path,
return length;
}
-if (length != sizeof (uintptr_t))
+if (length > sizeof (uintptr_t))
{
rtems_fdt_release_handle (&fdt);
return -RTEMS_FDT_ERR_BADPATH;
--
2.19.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] libmisc/rtems-fdt: Support prop map items up to the size of uintptr_t
From: Chris Johns
Updates #4729
---
cpukit/include/rtems/rtems-fdt.h | 6 ++
cpukit/libmisc/rtems-fdt/rtems-fdt.c | 19 +--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/cpukit/include/rtems/rtems-fdt.h b/cpukit/include/rtems/rtems-fdt.h
index 18e04352aa..e3ebfe3ba4 100644
--- a/cpukit/include/rtems/rtems-fdt.h
+++ b/cpukit/include/rtems/rtems-fdt.h
@@ -694,6 +694,12 @@ const char *rtems_fdt_entry_name(rtems_fdt_handle* handle,
int id);
*/
int rtems_fdt_entry_offset(rtems_fdt_handle* handle, int id);
+/*
+ * Helper function to convert the void* property result of unknown
+ * length to an unsigned int pointer value.
+ */
+uintptr_t rtems_fdt_get_offset_len_uintptr(const void* prop, int offset, int
len);
+
/*
* Helper function to convert the void* property result to a 32bit unsigned
int.
*/
diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
index e5bab21664..ec8f270eef 100644
--- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
+++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
@@ -1063,18 +1063,33 @@ rtems_fdt_prop_map(const char* const path,
return length;
}
-if (length != sizeof (uintptr_t))
+if (length > sizeof (uintptr_t))
{
rtems_fdt_release_handle (&fdt);
return -RTEMS_FDT_ERR_BADPATH;
}
-values[item] = rtems_fdt_get_uintptr(prop);
+values[item] = rtems_fdt_get_offset_len_uintptr(prop, 0, length);
}
return 0;
}
+uintptr_t
+rtems_fdt_get_offset_len_uintptr (const void* prop, int offset, int len)
+{
+ const uint8_t* p = prop;
+ uintptr_t value = 0;
+ intb;
+ if (len <= sizeof(uintptr_t)) {
+for (b = 0; b < len; ++b) {
+ value = (value << 8) | (uintptr_t) p[offset++];
+}
+ }
+ return value;
+}
+
+
uint32_t
rtems_fdt_get_offset_uint32 (const void* prop, int offset)
{
--
2.19.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[LIBBSD 6 PATCH] vfs: Pass in the td's cred to the VFS calls
From: Chris Johns --- rtemsbsd/rtems/rtems-kernel-vfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rtemsbsd/rtems/rtems-kernel-vfs.c b/rtemsbsd/rtems/rtems-kernel-vfs.c index 2f4d009b..0817df81 100644 --- a/rtemsbsd/rtems/rtems-kernel-vfs.c +++ b/rtemsbsd/rtems/rtems-kernel-vfs.c @@ -490,7 +490,7 @@ rtems_bsd_vfs_fchmod(const rtems_filesystem_location_info_t *loc, mode_t mode) } return rtems_bsd_error_to_status_and_errno(ENOMEM); } - error = setfmode(td, NULL, vp, mode); + error = setfmode(td, td->td_ucred, vp, mode); return rtems_bsd_error_to_status_and_errno(error); } @@ -511,7 +511,7 @@ rtems_bsd_vfs_chown( } return rtems_bsd_error_to_status_and_errno(ENOMEM); } - error = setfown(td, NULL, vp, owner, group); + error = setfown(td, td->td_ucred, vp, owner, group); return rtems_bsd_error_to_status_and_errno(error); } -- 2.19.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Fwd: Coverity Scan: Analysis completed for RTEMS
Looks like edit.c may still have an issue since only one was eliminated. Late here and I didn't check the Coverity report for sure. -- Forwarded message - From: Date: Fri, Nov 25, 2022, 12:21 AM Subject: Coverity Scan: Analysis completed for RTEMS To: Your request for analysis of RTEMS has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ81HXwCHW32Mihy8bA1BUtQ-3D-3DviMv_CTvEjVoKhyc6dLmJJo1u9AYIk8P8bcAbCPbBDYvYSXp-2BLm5AROIObGyJpCQ7WUD4uCOedRUNXz4QHmvwU0LGmYTV4utvoGiFNpxV14yuwFbMtMqiPMqYhgJ6qCiAsmbL1A7OIfEkv5puHSikCS43voZxxqfMgjoFP6NzhN7VoL6fGXEkle8-2Fa8udZrAVY6bh3BnQS32ZHR1j0Uir3zRo0hiqrWreidMPjlU87PGInog-3D Build ID: 496417 Analysis Summary: New defects found: 0 Defects eliminated: 1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add Formal Verification chapter v2
On 24/11/2022 14:41, andrew.butterfi...@scss.tcd.ie wrote: Section 9.7 "RTEMS Formal Model Guide" seems like it includes both some aspects of a How-To but also a lot of details that might be better as a separate document specific to the Promela/Verification detailed implementation. The point of the RTEMS Software Engineering manual is to provide developers with the guidelines of how to work with RTEMS. This section is very detailed about the implementation of specific models and feels unbalanced with the rest of the new section. For example, this section is about 3/5 of the entire "Formal Verification" section. I agree - this was what struck me after I had sent the patch set. In a sense I think we need a new top-level document, analagous to the Classic API and POSIX API guides. I am not sure if a new top-level document is really the best option. From my point of view, the RTEMS Software Engineering manual should cover everything useful for the general RTEMS maintainer. The models cover core services of RTEMS. With different documents you just have to open more documents and cross referencing will be more difficult. I am more in favour of a top-level chapter in the manual or some sort of an appendix chapter. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add Formal Verification chapter v2
On 16/11/2022 17:44, Gedare Bloom wrote: I guess I was overly optimistic last night. The note on the front matter should be resolved before we push the full documentation. I guess it's a bit of chicken-and-egg but the documentation should be pushed concurrent with the software that it documents. So, when there is a `formal` folder in `rtems-central` then it makes sense to push this documentation. I think the documentation is valuable, but I'm not sure how relevant it is without the associated tooling? Since rtems-central is currently a bit isolated, we could start with the integration of the "formal" directory. Andrew, please check that every file in "formal" has a clear copyright and license statement (SPDX identifiers would be great). If you used third-party code, then there should be one commit which adds this third-party code unmodified with a source of origin in the commit message. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
