3 ms·

> However, BSD's do not guarantee that their userlands will work with a mismatched kernel. Sure, it often does work, hence why jails only give a warning on mism

> However, BSD's do not guarantee that their userlands will work with a mismatched kernel. Sure, it often does work, hence why jails only give a warning on mismatch rather than refuse to run at all. FWIW, FreeBSD tends to go to pretty great lengths to ensure newer kernel with older userland works. A stock GENERIC kernel comes with COMPAT_FREEBSD* options back to COMPAT_FREEBSD4, and parts of the project's infrastructure tend to explicitly rely on at least supported releases to be functional in a jail on a -CURRENT kernel.

jsmith45 6y ago
Interesting, and good to hear. I know the other BSDs have a very different view of things. I had heard that Linux was the only OS with a stable kernel ABI guarantee. If FreeBSD does too, that certainly is better. Windows for example makes zero guarantees there. There are a lot of syscalls that they won't renumber because some applications have taken a dependency on using them directly, but officially using a syscall without going through NTDLL (or wherever the stub is located for private syscalls) is unsupported. Those syscalls they are not keeping fixed for compatibility can and do change from version to version. Mostly in numbering, but changes to semantics or arguments can happen too. Hence Windows Containers can only run in separate namespaces on a matching kernel version, and the hyper-v isolation (a.k.a. virtualization) option for containers is needed for mismatched versions. So creating an OCI runtime that wraps jails, adding any needed support for FreeBSD specific OCI container settings to containerd, and adding the needed code for things like networking to moby/moby (a.k.a. docker) sounds very feasible to me if some FreeBSD hacker wanted to get proper docker support. Offering Linux Emulation as an experimental option top be able to run more containers would be an added bonus, and should be feasible, since they once had that working with their old unofficial (presumably pre-containerd) builds of docker.

jsmith45 6y ago

Interesting, and good to hear. I know the other BSDs have a very different view of things. I had heard that Linux was the only OS with a stable kernel ABI guarantee. If FreeBSD does too, that certainly is better. Windows for example makes zero guarantees there. There are a lot of syscalls that they won't renumber because some applications have taken a dependency on using them directly, but officially using a syscall without going through NTDLL (or wherever the stub is located for private syscalls) is unsupported. Those syscalls they are not keeping fixed for compatibility can and do change from version to version. Mostly in numbering, but changes to semantics or arguments can happen too. Hence Windows Containers can only run in separate namespaces on a matching kernel version, and the hyper-v isolation (a.k.a. virtualization) option for containers is needed for mismatched versions. So creating an OCI runtime that wraps jails, adding any needed support for FreeBSD specific OCI container settings to containerd, and adding the needed code for things like networking to moby/moby (a.k.a. docker) sounds very feasible to me if some FreeBSD hacker wanted to get proper docker support. Offering Linux Emulation as an experimental option top be able to run more containers would be an added bonus, and should be feasible, since they once had that working with their old unofficial (presumably pre-containerd) builds of docker.