OSX Support

[kainz]

Support DIOD on OSX. Also clean out some of the autogenerated stuff.

This is not a complete port, see OSX-TODO for what doesn't work.

In particular: user mapping, anything depending on setfsuid() and friends.

What does work:
diodcat, diodls, diodload, dioddate, diodtop, mounting diod from linux, basic file operations.
misc/ tests

user/ tests need fixing.

[garlick]

Bryon,

Thanks for taking enough of an interest in diod to submit patches! I have some questions and they may sound critical, but please don't let that put you off.

Could you let me know why diod needs to work on OSX? 9P2000.L is a linux-specific protocol, and during the implementation of diod, I made no effort (as you now know :-) to make it portable to non-Linux platforms.

That said, I have no objection to making the code more portable if we can do it without making the code messy. #ifdef HAVE_FEATURE style conditionals (with associated m4 tests) are less messy IMHO than #ifdef platform style conditions. I'd go that way.

I consider the "whether to check in autotools products" to be a developers choice issue, unrelated to OSX. I need those products there for now. Perhaps long term we could discuss removing them but I'm not really open to that right now, sorry. We can .gitignore them though.

There are a number of touchy areas in the code: setfsuid, capability code, byte range locking, etc. that were hard to get right (and in some cases are less than right) on Linux and may be very hard on OSX. Depending on what your goals are, disabling features based on autoconf tests may be OK but we will need to be sure the user has a sane set of config options for all possible configs, and no nasty suprises (e.g. setfsuid doesn't work so server just does everything as root :-)

Jim

[kainz]

Jim, thanks for your input.

I certainly don't have any issues with moving all the conditionals in the code to HAVE_FEATURE type tests, nor with the autotools products. The .gitignore will still be useful to ensure they don't get autoclobbered then as you noted.

As for portability, the only really tricky spots are in missing syscalls and the like. While trying to do generic changes with HAVE_WHATEVER may be workable, I am not sure if the OSXish differences also translate to other BSDs, so I'll consider that an ancillary issue, for the moment.

The meat of the matter: Having diod on OSX is useful in that it allows me a fairly transparent and hypervisor-neutral method of sharing data between a host machine and multiple guest linux containers & VMs. That is my entire motivation, for the moment.

As for the touchy bits, I am not 100% confident on the byte range locking, but I am fairly confident that the semantics there have not changed, and the unit test still seems to pass, mostly. misc/t04 (the fcntl one) is giving me some trouble with errno setting though:

6c6
< tfcntl: child0: fcntl F_SETLK: Resource temporarily unavailable
---
> tfcntl: child0: fcntl F_SETLK: (null)
8c8
< tfcntl: child1: fcntl F_SETLK: Resource temporarily unavailable
---
> tfcntl: child1: fcntl F_SETLK: (null)

For the capabilities and setuid/gid bits, OSX does not has setfs*id, so it would be necessary I think to implement a sysdeps/ directory to implement the switching differently depending on OS. (i.e. you would have to use setuid() and setegid() on OSX I believe.) Capabilities are a whole different matter, as well, I'd be happy just slapping up a big WARNING for OSX users that that would not be guaranteed, or even implemented.

So, I've rebased this PR to not nuke the autoconf product. This should still compile out of the box and produce the same code on linux, let also work at least in an adhoc fashion on OSX. I do most of my testing in squash-all mode.

To test the kern/ directory, I think I would have to implement the diod run/mount bits in tests/kernel/runtest somewhat differently. I could probably get to that if I get some free time this weekend.

[garlick]

Hi Byron,

That does seem like a reasonable use case.

flock - I think the issue is that some flocks are implemented in terms of fcntl F_SETLK, which has the POSIX-mandated behavior of dropping the lock if any fd referring to the file in the current process is closed. If that's the way it works on OSX, locks won't be properly arbitrated by diod.

Regarding setfsuid, I think it's trickier than substituting seteuid() as (on linux at least) seteuid applies to the whole process and diod has multiple threads in its pool running on behalf of different users.

On second look it may be OK not to have the capability support for bypassing discretionary access control. I forget exactly how that works but I think it's an optimization one can safely skip. (It's already got an autoconf check as well as a runtime option).

How are you going to run the kern/ tests with the server on OSX and the client on Linux over a socketpair? That hurts my brain, but maybe you have found a way?

Jim

[kainz]

@garlick been awhile since I've looked at this, but I may be revisiting it soon. I've moved back to linux as my primary usecase, but I am also supporting OSX users, and am still dissatisfied with the host<->guest folder sharing solutions there.

As for running the kern/ tests, I would have to set them up to run via remote execution and TCP instead of the socket pair.

Setting up the mount options would be slightly painful, but it should be possible without too much headpain by adjusting the runtest driver script. For actually executing said test, I could just spawn a kernel in virtualbox, or the like. It's certainly not self-contained like a socket pair, but tools like Vagrant can largely automate that environment setup.

For DAC and set*id(), I still have no idea how I'd tackle that. FWIW IMO it would be more important to run the kern/ tests first.

[garlick]

It's been a while for me too (working on other things), but I'll try to be on tap if you're planning to rework the PR.

Autotools products are no longer in the repo so waiting at least fixed that one.

[garlick]

@kainz I hate to see all your work languishing here. You put quite a lot into this.

I'm going to close this PR for now as it minimally needs to be rebased to reflect the fact that autotools products are no longer in the repo, and to switch to feature tests. However, I do need to do some work on the build/test infrastructure in this project and will likely mine the closed PR for goodies if you don't have time to rebase and resubmit before I get to it.

[kainz]

No worries @garlick. Turns out NFS over vtap or the vbox/VMware equivalent was good enough for most people that I was doing this work around. I have my own reasons to prefer p9p, but I ended up back in an environment where linux was my primary workstation, so I don't really have the gear to test this, either, at the moment. I hope some of the conditionalization and mocking comes in useful.

[diclophis]

Is any work currently being done to support OSX?

[garlick]

Sorry, not that I'm aware of.

[diclophis]

mmm... maybe I will try to dust off this PR and try to see if I can map something from a running https://github.com/moby/hyperkit process... it recently has been upgraded to include 9p file system support... not sure if there is any protocol compatibility between the two implementations but it is certainly worth investigating if 9p has any chance of being faster than NFS

(See: https://github.com/moby/hyperkit/blob/master/src/lib/pci_virtio_9p.c )