roemer wrote:Thanks for the link. So the rationale is pool-compatibility with Linux/Solaris.
In that discussion thread on Github, you pointed to the 'xattr_darwinacls' branch as potential alternative.
That branch was last modified about 4 months ago.
How is that branch kept up-to-date with bugfixes in the master branch?
Secondly, if I compile my own kernel extension from that branch, it is not signed and would hence create a warning at each boot from OS X 10.9?
Anyway to avoid this (other than paying 99 bucks/anno to Apple
That branch would need to be rebased off of master. However, although I put that branch out there to appease those who are bothered by this, I do not particularly like that method. A "correct" method would implement an entirely separate ACL type for Darwin ACLs. Basically we'd need to spoof Darwin ACLs which are meant to only be "extras" above and beyond the mode, which is not entirely possible since Darwin ACLs can create situations that NFSv4 ACLs cannot, or we'd need to introduce a pool incompatibility, with a feature flag, or later, when there is OpenZFS support for it, a per dataset flag.
In my opinion, a separate Darwin ACL type is an extremely low priority item.
The best discussion of the difference between Darwin ACLs and NFSv4 ACLs is here:
https://wiki.freebsd.org/NFSv4_ACLs
___
When it's your own kext, compiled by you and unsigned, it should be installed to /System/Library/Extensions instead of /Library/Extensions, which is reserved for signed kexts. You only get that warning once and then it gets white-listed.