Conversation
|
Well, that's a bit of a disaster. :) |
ghost
left a comment
There was a problem hiding this comment.
I've started looking through the common code parts and putting stars where things look like they could be easily upstreamed independently.
configure.ac
Outdated
cmd/zed/zed_conf.c
Outdated
There was a problem hiding this comment.
Could this go in include/os/macos/spl/sys/uio.h?
There was a problem hiding this comment.
Ah, lib/libspl/include/os/macos/sys/uio.h
Nope - ZOL made the decision to not use include paths for some cmd/ entries, so that file isn't used - which is a shame. But far more work/frustration to touch their build system, then to include those prototypes.
include/sys/dbuf.h
Outdated
include/sys/dnode.h
Outdated
lib/libspl/asm-x86_64/atomic.S
Outdated
Very clearly says |
|
As a general note, the dist target (so DIST_SUBDIRS, EXTRA_DIST, stuff like that) is used for building the source distribution archive. It should include all the files necessary to build regardless of platform. |
Crow-Control
left a comment
There was a problem hiding this comment.
I've gone through some of the more style and procedure based changes.
While it looks generally sane, there are some nits here and there imho...
appveryor.yml
Outdated
There was a problem hiding this comment.
Github seems to also have a workflow runner for OSX, as we currently use either buildbot or workflows, that might be prefered....
There was a problem hiding this comment.
is CMD the right location for InvariantDisks?
Maybe also add a short readme listing what this thing is actually for, for those of us not familiar with the OSX codestack?
There was a problem hiding this comment.
Made a cmd/os/macos/ so that other platforms wouldn't need to worry about it, but some general description could be nice (same goes for ZOL cmds I have no idea what they do) As it happens, InvariantDisk is a separate process started by launchd to maintain a symlink-tree of storage devices, ie, /var/run/disk/by-serial/X -> /dev/diskX. To work around disk renumbering problem.
There was a problem hiding this comment.
Same indeed also goes for some ZoL commands, yes...
With that description, as a sub process is cmd the right location?
cmd/os/macos/zfs_util/PkgInfo
Outdated
There was a problem hiding this comment.
many ZoL references...
While we are actually working actively on removing those, in favor of OpenZFS
There was a problem hiding this comment.
Ah these pkg files haven't been looked at since the start - could do with a refresher.
There was a problem hiding this comment.
Are those actually compatible?
Why use a totally difference license for the OSX code? It doesn't really make sense to me.
We already have CDDL, GPL and BSD code mixed in, and now we also have 2(!?) different apple OSS licences?!
Before sneaking in licenses, it might actually be appropiate to get legal council specialised in US copyright law to sign off on mixing those.
There was a problem hiding this comment.
Some files are used verbatim, like kextsymboltool.c - so its more of a "3rd party license" list I think. All code I have written personally is CDDL.
There was a problem hiding this comment.
Good to know, but how is this made clear in-code?
|
Great to see this coming under the umbrella. Convincing clients to use it (on non-boot media) is somewhat of a challenge as its "out-of-tree" for OpenZFS and they worry that it will eat their data. We've used @lundman's installers/work for years whenever we have to do mac-stuff where ZFS helps achieve the goal. Will be great to have it in-sync with master and reviewed by that many more skilled eyes. |
Add macOS to the build system. Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Ditto here. In my case I've managed to convince the clients and I'm using an old version from Lundman's (1.9.3) successfully, but am unable to use newer (1.9.4+) versions due to subtle incompatibilities in zfs send/recv streams between it and FreeBSS 11 ZFS. My hope is that when it's all under one umbrella, these incompatibilities will be solved and it will all be one great ZFS family :-) So please, everyone keep up the good work and let's get this thing working. If needed, I will volunteer as a tester. |
Attempt to group most of the sweeping changes to headers in there, unless they fit better with an individual commit Signed-off-by: Jorgen Lundman <lundman@lundman.net> It appears FreeBSD did the same for zfs_ioctl_register_dataset_nolog() as they use it, so following suit for zfs_ioctl_register_pool()
Honestly, don't know if this is required, but XNU does like va_type and va_mode Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Apparently upstream has already made this change for mount, so add the same support to umount. OSX wants it for devdisks, and handling of snapshots. How unattractive is it with the type difference between mount, and unmount? Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Is this the best way? We could add ", func, private" to the existing IO, and either send by uio, or by func(private). Signed-off-by: Jorgen Lundman <lundman@lundman.net>
"zfs mount dataset@snapshot" as mounting of snapshot has to be done manually from userland in macOS. Signed-off-by: Jorgen Lundman <lundman@lundman.net>
For kernel to send snapshot mount/unmount events to zed. Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Add zfs_rollback_os() call to the rollback logic, so platforms can do specific requirements. macOS: need to kick Finder to update. Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Add all files required for the macOS port. Add new cmd/os/ for tools
which are only expected to be used on macOS.
This has support for all macOS version up to Catalina. (Not BigSur).
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
macOS: big uio change over.
Make uio be internal (ZFS) struct, possibly referring to supplied (XNU)
uio from kernel. This means zio_crypto.c can now be identical to upstream.
Update for draid, and other changes
macOS: Use SET_ERROR with uiomove. [squash]
macOS: they went and added vdev_draid
macOS: compile fixes from rebase
macOS: oh cstyle, how you vex me so
macOS: They added new methods - squash
macOS: arc_register_hotplug for userland too
Upstream: avoid warning
zio_crypt.c:1302:3: warning: passing 'const struct iovec *' to parameter of
type 'void *' discards qualifiers
[-Wincompatible-pointer-types-discards-qualifiers]
kmem_free(uio->uio_iov, uio->uio_iovcnt * sizeof (iovec_t));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
macOS: Update zfs_acl.c to latest
This includes commits like:
65c7cc4
1b376d1
cfdc432
716b53d
a741b38
485b50b
macOS: struct vdev changes
macOS: cstyle, how you vex me [squash]
Upstream: booo Werror booo
Upstream: squash baby
Not defined gives warnings.
Upstream: Include all Makefiles
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
double draid!
Due to some differences in assembler work, macOS will have own copies. It would be desirable to change all assembler files to use asm_linkage.h and the macros inside for better portability. Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Start to add macOS support to the zfs-tester environment, much more work is required still. Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Until the problem can be properly understood, save the original allocation size to avoid freeing with wrong size. This affects both FreeBSD and macOS but FreeBSD does not use size with free. Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
A little torn as to removing this call, or adding it to SPL, but since it is not used in a new special way, and would in-efficiently write nil when not needed, the old style will do. But flexible, say the word... Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Hoping to remove it eventually.
Upstream: cut redundant lines [squash autoconf]
Upstream: define EMPTY_TASKQ
This reverts commit 6d5691c. The recent upstream changes to abd and how the size is calculated appears to have addressed the size issue (as the VERIFY no longer gets triggered).
It appears that abd_get_offset_struct() can be called and supply an existing abd reference, which is initialised. But there is no "put" method, so when it is re-used, it will re-initialise the fields again, including mutex_init() which causes a panic: (abd.c:568)> abd_init_struct: avoiding panic for abd 0xffffff802f4f26e0 (abd.c:568)> abd_init_struct: avoiding panic for abd 0xffffff802f4e1900 (abd.c:568)> abd_init_struct: avoiding panic for abd 0xffffff802f4f8220 (abd.c:568)> abd_init_struct: avoiding panic for abd 0xffffff802f4e1900 (abd.c:568)> abd_init_struct: avoiding panic for abd 0xffffff802f4f26e0 (abd.c:568)> abd_init_struct: avoiding panic for abd 0xffffff802f4f8220
Even when supplied with an abd to abd_get_offset_struct(), the call to abd_get_offset_impl() can allocate a different abd. Ensure to call abd_fini_struct() on the abd that is not used. Signed-off-by: Jorgen Lundman <lundman@lundman.net>
|
Any updates on getting this merged? I absolutely love using ZFS on macOS and am excited to see this ported to the official repo. |
|
Working on it, just needs to ferment a bit more, to get a kick. We only just got ARM64 version to work, and it's been a decent step backwards to appease APPLE, that we need to recover from. |
|
Hmm this PR no longer notices that I've pushed to the branch. But it could have something to do with us de-Forking. Anything special needed to make the PR wake again? |
|
@lundman force updating the branch should be enough, maybe give it another try. It looks like for whatever reason Github didn't notice the branch update and post an event. |
|
Closing in favour of #12110 |
Add macOS support.
Work has progressed well, recent release of macOS-2.0.0rc7 version support macOS-10.9 to macOS-11 to include M1/arm64 architecture. It is our wish that this PR is close to the final version, and should probably start to take commits from here and promote to individual PRs where that make sense.
Motivation and Context
More the merrier, over, too many chefs.
Description
Commits prefixed with "Upstream:" change universal files and should be inspected.
Commits prefixed with "macOS:" only affects macOS specific files. Code review still appreciated though.
zfs-tester work is incomplete, much more tweaking needed for compatibility. A large zfs-tester PR is being worked on.
This is a large PR, and it is expected that code-review will ask many commit to be changed.
Currently macOS compile to pkg, or loading, would be:
How Has This Been Tested?
By users, by local zfs-tests, and Appveyor zfs-tests.
Types of changes
Checklist:
Signed-off-by.