Backport FreeBSD support to the 9pfs device model#307
Closed
markjdb wants to merge 3 commits into
Closed
Conversation
When mapped POSIX ACL is used, we are ignoring errors when trying to remove a POSIX ACL xattr that does not exist. On Linux hosts we would get ENODATA in such cases, on macOS hosts however we get ENOATTR instead. As we can be sure that ENOATTR is defined as being identical on Linux hosts (at least by qemu/xattr.h), it is safe to fix this issue by simply comparing against ENOATTR instead of ENODATA. This patch fixes e.g. a command on Linux guest like: cp --preserve=mode old new Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Link: https://lore.kernel.org/qemu-devel/2866993.yOYK24bMf6@silver/ Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com> Message-Id: <34f81e9bffd7a3e65fb7aab5b56c107bd0aac960.1651228001.git.qemu_oss@crudebyte.com> (cherry picked from commit 9ea3164)
It doesn't compile on FreeBSD and has been removed upstream. Just do the minimum needed to get this to build.
This is largely derived from existing Darwin support. FreeBSD apparently has better support for *at() system calls so doesn't require workarounds for a missing mknodat(). The implementation has a couple of warts however: - The extattr(2) system calls don't support anything akin to XATTR_CREATE or XATTR_REPLACE, so a racy workaround is implemented. - Attribute names cannot begin with "user." or "system." on ZFS. However FreeBSD's extattr(2) system calls support two dedicated namespaces for these two. So "user." or "system." prefixes are trimmed off from attribute names and instead EXTATTR_NAMESPACE_USER or EXTATTR_NAMESPACE_SYSTEM are picked and passed to extattr system calls accordingly. The 9pfs tests were verified to pass on the UFS, ZFS and tmpfs filesystems. Signed-off-by: Mark Johnston <markj@FreeBSD.org> Link: https://lore.kernel.org/qemu-devel/aJOWhHB2p-fbueAm@nuc Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> (cherry picked from commit 6657f3bb55edba8f068cbc9ac40bb230ea1d7a09)
Member
|
Thanks this is great! Could you submit this PR against the Cheri-Alliance/qemu main branch? I plan to change cheribuild to default to that qemu soon. |
Author
Sure, done here: CHERI-Alliance/qemu#21 Shall we close this PR then? |
Member
Yes that sounds good, let's close this one. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This lets one use 9pfs from the guest on a host running FreeBSD. There were some conflicts but nothing too bad: there is no CONFIG_FREEBSD, so I changed preprocessor directives to check CONFIG_BSD, which is hopefully no great sin. I also disabled the 9p-proxy build as it fails on FreeBSD and has been removed entirely upstream.
Tested with cheribuild qemu --test and some quick manual testing of a CheriBSD guest.