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

Fix #580, improve FS_BASED mounts on VxWorks #709

Merged

Conversation

jphickey
Copy link
Contributor

Describe the contribution
The mount/unmount implementation was not adequately checking for and handling the FS_BASED (pass -through) mapping type - which should be mostly a no-op. But to be consistent with POSIX it should also create a mount point directory if it does not already exist when using this mapping type.

Adds a documentation note to OS_FileSysAddFixedMap() regarding the limitation that the virtual mount point cannot be empty - so OS_FileSysAddFixedMap(.., "/", "/") does not work - never did. However OS_FileSysAddFixedMap(.., "/", "/root") does work and allows one to open files in the root as "/root/" from OSAL applications.

Fixes #580

Testing performed
Build and run all unit tests on native
Sanity check CFE
Confirm behavior of OS_FileSysAddFixedMap() + OS_TranslatePath() when mapping to root FS.

Expected behavior changes
Mount point directories do not need to be already existing when using OS_FileSysAddFixedMap

System(s) tested on
Ubuntu 20.04 (native)
VxWorks 6.9 (mcp750)

Additional context
Auto-creating the mount point dir is relevant to unit tests - this simplifies running the unit tests by not requiring the user to pre-create this directory. Otherwise without this one gets unit test failures if the directory doesn't already exist.

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

@jphickey
Copy link
Contributor Author

jphickey commented Dec 28, 2020

Ping @johnphamngc -- please review/confirm if this is adequate to address the issue described in #580

The mount/unmount implementation was not really checking
for and handling this mapping type.

To be consistent with POSIX it should also create a directory
if it does not already exist.
@jphickey jphickey force-pushed the fix-580-vxworks-fsbased-mount branch from 8168c01 to e175530 Compare December 28, 2020 20:32
@jphickey jphickey added the CCB:Ready Pull request is ready for discussion at the Configuration Control Board (CCB) label Dec 28, 2020
}
else
{
if (mkdir(local->system_mountpt, 0775) == 0)
Copy link

@johnphamngc johnphamngc Jan 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry - I should have mentioned, if you want to build you'll need to also pull the fix/workaround for VxWorks 7 compatibility in #706 (mkdir was fixed to be POSIX compliant in VxWorks 7).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, this commit 25cd5df seems to have broken vxWorks when attempting to load cFE - "Warning: module 0x56d75b0 holds reference to undefined symbol OS_WaitForStateChange_Impl." when trying to build and run the branch. I'll see if I can backport the fix to OSAL 5.1.0-rc1+dev16 and see if it fixes the issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah there was a bunch of PRs recently, I thought #706 + this one would work in isolation but maybe not...

At any rate, with this change I was able to test/confirm that you can do:

OS_FileSysAddFixedMap(&fs_id, "/", "/root");

Which succeeds, then followed by:

OS_TranslatePath("/root/myfile.txt", myfile_path)

Which in turn sets myfile_path to //myfile.txt

Note - yes it translates to a double leading slash but that is technically OK on UNIX and VxWorks seems to accept this and open it fine as well...

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you confirm that the case of OS_FileSysAddFixedMap(&fs_id, "/cf", "/cf"); works as well? Otherwise I'll get around to backporting the fix and checking it sometime tomorrow.

I think I'll make another ticket for the NFS directory case, since it's unrelated besides both affecting OS_FileSysMountVolume_Impl and is a change in the POSIX OSAL instead. That one is a lower priority since I can just tell our developers to not run cFS off of an NFS mounted directory.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it works for that case as well. I'll wait till we rebase w/ the latest CFE to see if the NFS issue manifests again before making another ticket.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, and yes please submit a separate ticket for the NFS issue. In the meantime I am looking into getting one of my test targets booted using an NFS root, and I'll check if anything looks amiss on it.

@jphickey
Copy link
Contributor Author

jphickey commented Jan 4, 2021

Added dependency label - if/when merging note that this also requires the compatibility fix in #706

@astrogeco astrogeco added CCB-20210106 and removed CCB:Ready Pull request is ready for discussion at the Configuration Control Board (CCB) labels Jan 6, 2021
@astrogeco
Copy link
Contributor

CCB 2021-01-06 APPROVED

@astrogeco astrogeco changed the base branch from main to integration-candidate January 12, 2021 19:16
@astrogeco astrogeco merged commit 52aed2a into nasa:integration-candidate Jan 12, 2021
astrogeco added a commit to nasa/cFS that referenced this pull request Jan 12, 2021
@jphickey jphickey deleted the fix-580-vxworks-fsbased-mount branch January 27, 2021 14:09
@skliper skliper added this to the 6.0.0 milestone Sep 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Possible OSAL bug in OS_FileSysAddFixedMap not allowing FS_BASED mapping on VxWorks
4 participants