-
Notifications
You must be signed in to change notification settings - Fork 217
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
Comments
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
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 traditionalFS_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.
The text was updated successfully, but these errors were encountered: