Fix casper compilation on FreeBSD #26
Conversation
Include netinet/in.h for the definitions for sockaddr_in* and friends. While here, sort the includes per style(9) on FreeBSD and to ensure that types are declared before they're referenced in other headers. Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
`SO_PASSCRED` doesn't exist on other platforms, such as FreeBSD or OSX. Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
This is the case on FreeBSD at least Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
Only use libbsd headers on Linux; FreeBSD and OSX should provide these basic facilities. Create a fork in the road for FreeBSD and OSX when dealing with sys/_?endian.h and (lib)?util.h. OSX's naming scheme matches NetBSD's naming scheme, so apply that naming scheme as needed. Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
This doesn't appear to compile properly Just ditch it in favor of the autoconf/automake generated Makefile and to reduce redundantly defined targets. Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
|
Hmm, I wonder if it might be better to just ignore the IIRC the So if your aim is to have a cross-platform set of Casper tools, I'd suggest starting from the current FreeBSD version and making that version build and work on other platforms. OTOH if you're just fiddling with (And apologies – if I'd replied sooner on #25 I might have saved you some work) |
|
@daviddrysdale: hmm... I thought the tests in this repo were newer than the ones in the FreeBSD repo. What I would like to do is replace the ATF (https://github.com/jmmv/atf) test code with googletest and have the tests be available for all supported platforms. The former is less portable compared to the latter. |
|
Ah, the tests in By the way, where are the ATF-based tests you mention? I don't think I've seen those. Also, I'm still not clear about your overall goal – are you working on Casper, or the Capsicum test suite, or both? |
Gotcha! Well (sigh), I was wrong about there being a number of tests in the FreeBSD tree :D.. We have some tests, but not too terribly many. They're also all in TAP (well, shoehorned into it because they use assert(3) liberally to catch errors, which breaks kyua runs), not ATF :(. Tests integrated into Jenkins (CI)
Tests not integrated into Jenkins:
tl;dr: Both. I was directed to this repo originally by @emaste (another committer with the FreeBSD project; a co-mentor of mine), and he and I have a vested interest in getting more test coverage for system components. In particular, there are a number of gaps on the Capsicum side that we would like to cover. Fixing issues with this repo as they crop up, allows us (actually: me :P) to make progress towards achieving that goal. Having this project integrate into FreeBSD directly is less of a goal, since the build framework is so different (but it would be nice to have it build on FreeBSD so we can do side-by-side comparisons when upgrading the test suite). It's more important to have this integrate into Linux and OSX CI, so potential porting issues with FreeBSD can be caught earlier (FreeBSD can be closely approximated to Linux in some regards and OSX in other regards when it comes to building and testing the project). My gut feeling about this is that FreeBSD (and Linux) should be contributing to a common project with all of the involved components (libcapsicum, libcasper, libnv, libpjdlog, etc), so there aren't multiple divergent forks, separate parties can contribute to capsicum and casper as a whole, and the tests can be used on all platforms where capsicum and casper are supported. I acknowledge that this is a very lofty goal and I would need to involve all appropriate parties in order to make progress in this effort. -Enji (ngie@FreeBSD.org) |
At least some of these tests ended up directly in FreeBSD as the author wasn't interested in agreeing to the CLA required on the upstream repo. If we import capsicum-test into contrib we could at a minimum migrate them there. |
Yeah, that's been a problem for FreeBSD developers. The Google CLA is a barrier that they don't want to deal with--or can't maybe, because lawyers/bureaucracy, which was the case when I used to work for Dell EMC/Isilon. |
|
Backing up for a second, this repo is a bit of a mishmash of anything Capsicum-related that runs in userspace, so it helps to be clear about which of the 3 main parts we're talking about:
Top-level test suiteThe main test suite is only expected to run on Capsicum-enabled OSes, which is essentially just FreeBSD and a patched version of the Linux kernel. When last I checked, it built and ran on both1 with only a few minor test failures on FreeBSD. So the top-level test suite might well be a good candidate for integrating with FreeBSD testing, but isn't relevant to OSX (no Capsicum) and wouldn't work with stock Linux (no Capsicum without the patched kernel) so any CI integration would be FreeBSD-only. Codebase status-wise, AFAIK this repo is the master copy of the test suite and so is a good place to start from (but maybe the CLA thing means there are some extra tests out there too). However, I'm not actively developing anything on the Linux side so it may make sense to fork and treat a new location as the master. Casper directoryI like the idea of an independent, CI-tested repo for the various Casper-related tools and utilities, and also the idea that the Casper code could be more OS-agnostic and so build and have tests on multiple platforms (FreeBSD, Linux, OSX). However, this repo probably isn't the place to start from nor to hold the master copy of the code. tl;dr: don't start from here. Libcaprights directoryThis is entirely Linux-Capsicum specific, so can probably be ignored in this discussion. 1: The test suite currently has a hack involving the different priorities of |
|
Assuming all that makes sense, what I think it would boil down to as concrete suggestions:
|
|
I'm happy to fork it into either the freebsdfoundation or freebsd github orgs (although I don't have permission for the latter - should check into that). |
|
We could fork this into either the FreeBSD Foundation GitHub org (for which I have appropriate permissions) or preferably the FreeBSD project's org (for which I don't), but @bapt will fork it there if that is what we want. |
|
@daviddrysdale: I'm abandoning this PR because of the discussion we've had here and also #25 . I will work on your recommended steps for pushing #25 forward. Is there a way that we could work with the Google lawyers on the capsicum tests or just reassign the project to the FreeBSD project's care to avoid having to deal with the Google CLA and make sure that everything is in the clear for future contributions and such? |
The following change imports google/capsicum-test@9333154 from GitHub, omitting the embedded version of googletest, as well as the incomplete libcasper. This test suite helps verify capsicum(3) support via functional tests written in the GoogleTest test framework. Kernel support for capsicum(4) is tested by side-effect of testing capsicum(3). NB: as discussed in a previous [closed] PR [1], the casper(3) tests are incomplete/buggy and will not pass on FreeBSD. Thus, I have no intention of integrating them into the build/test on FreeBSD as-is. The import command used was: ``` curl -L https://github.com/google/capsicum-test/tarball/9333154 | tar --strip-components=1 -xvzf - -C dist/ rm -Rf dist/*/ ``` 1. google/capsicum-test#26 Reviewed by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D19261
The following change imports google/capsicum-test@9333154 from GitHub, omitting the embedded version of googletest, as well as the incomplete libcasper. This test suite helps verify capsicum(3) support via functional tests written in the GoogleTest test framework. Kernel support for capsicum(4) is tested by side-effect of testing capsicum(3). NB: as discussed in a previous [closed] PR [1], the casper(3) tests are incomplete/buggy and will not pass on FreeBSD. Thus, I have no intention of integrating them into the build/test on FreeBSD as-is. The import command used was: ``` curl -L https://github.com/google/capsicum-test/tarball/9333154 | tar --strip-components=1 -xvzf - -C dist/ rm -Rf dist/*/ ``` 1. google/capsicum-test#26 Reviewed by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D19261 git-svn-id: https://svn.freebsd.org/base/vendor/google/capsicum-test@345046 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
This makes some inroads towards fixing compilation on OSX, however, there are issues with the ad hoc copy of libnv, et al, that cause linker failures on OSX. This doesn't occur on FreeBSD because it comes with libnv, et al, since 10.x/11.x. This needs to be fixed up, since the tests should either be consistently pulling libraries from the base system, or not doing so (and in turn, pulling it from another appropriate source repository).
This pull request requires #25 in order to function.