Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filesystem should differentiate between FS_BASED (known) and unknown filesystem types #456

Closed
jphickey opened this issue May 13, 2020 · 0 comments · Fixed by #461
Closed
Assignees
Milestone

Comments

@jphickey
Copy link
Contributor

Is your feature request related to a problem? Please describe.
The existing OS_FILESYS_TYPE_DEFAULT type is used to cover basically any filesystem mapping that doesn't directly fall into the other categories (e.g. NORMAL_DISK, VOLATILE_DISK, etc). This includes the traditional FS_BASED types, which just map to another existing place in the filesystem.

Describe the solution you'd like
The code should provide a unique value for FS_BASED maps, which is a valid mapping type, as opposed to not knowing what mapping is being used.

Additional context
Distinction between known FS types and unknown types is required for running without Volume Table in BSP.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

@jphickey jphickey self-assigned this May 13, 2020
@skliper skliper added this to the 5.1.0 milestone May 13, 2020
jphickey added a commit to jphickey/osal that referenced this issue May 15, 2020
Add a distinct type for FS_BASED entries, and an UNKNOWN value
for when a type is actually not yet identified.

This can be used to identify the FS type first at the shared
layer, then in the implementation layer as a fallback option
if not identifiable in the shared layer.

Use the volume name prefix "RAM" as a hint that the volume
is supposed to be a VOLATILE disk as opposed to a normal disk.
This is done in shared layer so it applies to all OS types.
jphickey added a commit to jphickey/osal that referenced this issue May 15, 2020
Add a distinct type for FS_BASED entries, and an UNKNOWN value
for when a type is actually not yet identified.

This can be used to identify the FS type first at the shared
layer, then in the implementation layer as a fallback option
if not identifiable in the shared layer.

Use the volume name prefix "RAM" as a hint that the volume
is supposed to be a VOLATILE disk as opposed to a normal disk.
This is done in shared layer so it applies to all OS types.
jphickey added a commit to jphickey/osal that referenced this issue May 15, 2020
Add a distinct type for FS_BASED entries, and an UNKNOWN value
for when a type is actually not yet identified.

This can be used to identify the FS type first at the shared
layer, then in the implementation layer as a fallback option
if not identifiable in the shared layer.

Use the volume name prefix "RAM" as a hint that the volume
is supposed to be a VOLATILE disk as opposed to a normal disk.
This is done in shared layer so it applies to all OS types.
jphickey added a commit to jphickey/osal that referenced this issue Aug 10, 2022
Replaces the `OS_IntLock` with a standard OSAL mutex for protecting
the shared/global perflog data structure.  This may introduce unexpected
task switches when contention occurs, but it ensures proper exclusion
with respect to the data structures.

Removes the temporary child worker task that was spawned for writing
the log data to a file, and replace with a more generic CFE ES
background task.  The background task is started at boot and
pends on a semaphore until there is work to do.

The background performance log dump is implemented as a state machine
which is called repeatedly over time from the background job task.  This
performs a limited amount of work on each invocation, and resumes where
it left from the previous invocation.
jphickey pushed a commit to jphickey/osal that referenced this issue Aug 10, 2022
Fix nasa#456, Perf log threading and concurrency issues
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants