On Sun 14 Aug 2022 at 14:22, Doug Rabson <dfr(a)rabson.org> wrote:
I'm trying to come up with a few ground rules for this work and I'm
- Keep code duplication to a minimum, factoring out platform-specific
functions as needed ideally without reducing readability.
- Take the project one file at a time to keep the pace manageable.
Where a file with _linux suffix will be substantially shared with freebsd,
first move the file from foo_linux.go to foo_common.go and in separate
commits in the same PR, apply a minimum set of refactors to support the
- At least until the main branch contains a working freebsd port, do
not add freebsd to the cross-build smoke test - any build breaks I will
handle after the fact.
- Once basic functionality is present in the main branch, prioritise
enabling at least a subset of the unit test suite. If possible,
enable these in CI as a non-blocking signal - I'm aware this would add cost
to the CI infrastructure and this needs to be considered before changing CI.
In the short term, I have a small handful of PRs to add stubs to the tree
which allow a non-functional freebsd build after which I would like to
start working through libpod as described above, probably starting with
This sounds good to me, thanks!
On Wed, 10 Aug 2022 at 10:38, Doug Rabson <dfr(a)rabson.org> wrote:
> On Wed, 10 Aug 2022 at 09:19, Valentin Rothberg <vrothberg(a)redhat.com>
>> Thanks for reaching out, Doug! And thanks for your great work.
> Thanks for all your help getting this far! While working on buildah and
> its supporting modules, I have been particularly grateful for the
> thoughtful and detailed responses to my many PRs.
>> On Tue, Aug 9, 2022 at 5:31 PM Doug Rabson <dfr(a)rabson.org> wrote:
>>> Over the last few months, I have been working on porting the
tool stack to FreeBSD, using the FreeBSD jail
>>> subsystem for isolation. This builds on Samuel Karp's earlier work on
>>> which is a jail-based OCI runtime.
>>> Since buildah v1.27.0 contains working FreeBSD support for building
>>> container images and it looks like this will be vendored into podman quite
>>> soon, I would like to get the much larger set of changes for podman on
>>> FreeBSD into review somehow.
>>> The complete set of FreeBSD changes is much too large for a single PR,
>>> so I'm going to try to take this one file at a time. My plan is
>>> 1. Add enough stubs to libpod to make it compile on FreeBSD
>>> (without working at all)
>>> 2. Pick a file from libpod/*_freebsd.go, ideally with the smallest
>>> set of cross dependencies and make a PR which adds the freebsd file and
>>> a small stack of commits, factors out as much as possible of the shared
>>> code between linux and freebsd.
>>> 3. Work through review as normal until the PR can be merged.
>>> 4. Go to step 2 unless I'm done.
>>> Does this seem reasonable? It's going to take a while - my working
>>> branch has 21 freebsd files with varying degrees of complexity.
>> I would love to see Podman run on FreeBSD. But there are a number of
>> issues I want to discuss beforehand:
>> - *Who owns and maintains the FreeBSD code?* All current Podman
>> maintainers are Linux people and I don't think there are free cycles to
>> into FreeBSD. If it's only a single person maintaining the FreeBSD code
>> could be a threat to sustainability. Code must be maintained and evolved.
>> Bugs need to be fixed. Same applies to CI systems and tests.
>> Right now, it's just me working on this as a 'full time volunteer'
> is more efficient for the first pass zero-to-one phase (IMO). Having good
> support for industry-standard container tools is important for the FreeBSD
> project as a whole and is supported by the FreeBSD Foundation - I have
> copied Ed Mast from the Foundation into this thread and he may be able to
> comment on that. Personally, I believe that recruiting a little extra
> support from the FreeBSD community will be possible if we can reach the
> point where podman runs on FreeBSD.
>> - Related to the point above: *How can we prevent the FreeBSD
>> support from blocking Linux development?* There is a risk that
>> changes (e.g., new features) to Linux containers may require changes to the
>> FreeBSD code. I want to keep that to an absolute minimum, so we probably
>> need to add abstractions in the form of interfaces at some places.
>> This is a really important point. My experience so far working on a
> prototype podman-on-freebsd has shown me that many of these abstractions
> are already in place. In some places there are abstraction leakages but in
> general, the code is already quite portable. Large parts of the code, even
> code which currently is marked as Linux-only, worked unchanged on FreeBSD.
> While working on adding run support to buildah, I was able to limit the
> amount of FreeBSD-specific code to just 550 lines of code with more than
> 1800 lines shared between the two platforms. This isn't necessarily a good
> predictor for future work but it's encouraging (IMO).
> I absolutely do not want to impede Linux development. I want to do
> anything I can to prevent that, through participating in code review,
> consulting on differences in the platforms and fixing any breakage after
> the fact to free up the Linux workflow.
>> - *How can we test? *I have no experience in FreeBSD but assume
>> there is a way to run VMs with it and plug them into CI. Many tests
>> run on FreeBSD, so we may need a simplified FreeBSD-specified testsuite.
>> None of the points above must necessarily be blockers but I want to have
>> a common understanding and set expectations (e.g., the FreeBSD support
>> could very well be marked experimental). I am mostly afraid that it could
>> be a constant burden on Linux development and hence be expensive for the
>> entire project.
> Unit testing is also an extremely important factor. FreeBSD VMs are
> supported by Cirrus CI and I want to get at least some of the test suite
> functioning. At first glance, I think that some of the tests in
> podman/test/system will work unmodified if I can supply a suitable test
> image but I haven't actually tried this.
>> Kind regards,
>>> Podman mailing list -- podman(a)lists.podman.io
>>> To unsubscribe send an email to podman-leave(a)lists.podman.io