I have FreeBSD's actual libc/runtime running on the Linux kernel via syscall translation.

zester

zester

Been messing around with a personal project porting FreeBSD libc, mostly unmodified, running directly on Linux kernel syscalls. There’s no glibc or musl involved, just a thin translation layer for the places where the two kernels disagree. Termios encoding was probably the most annoying part so far.

This week I got LLVM’s libc++, libc++abi, and libunwind building against it through LLVM’s own build system. C++ code, containers, exceptions, all of it now compiles, links, and runs.I also have 106 FreeBSD base-system commands working. That includes things like cat, ls, cp, mv, find, expr, the interactive sh, localedef, tsort, getconf, and a long list of older BSD utilities like caesar, primes, jot, ministat, col, soelim, and others.

It's mostly unmodified FreeBSD source that go through structural ELF checks and most of them have their own functional tests beyond that.

So, if anyone ever wondered whether the FreeBSD kernel could be replaced cleanly with the Linux kernel, the answer is 100% yes, and with surprisingly few source modifications.
 
That's an interesting bit of work. It reminded me of the hybrid GNU/kFreeBSD project, which is essentially the Debian userland running on top of the freebsd kernel. So they went the other way round, from your experiement, but otherwise a similar idea.

Exploring the Hybrid Debian GNU/kFreeBSD Distribution | Linux Journal

www.linuxjournal.com www.linuxjournal.com

I guess both hybrids have a reasonable chance of working, since both kernels implement the posix core set of system calls, and the two userlands are written to run on top of that core. It's quite encouraging, that it actually works!

Personally I hope the two projects continue to develop independently. Having more than one option available, is always good. :)
 
Perhaps some areas like linux cgroups ('resource limits' is the FreeBSD equivalent) and parts of the network stack (eg, the linux ip command, linux style interface aliasing) will require a bit more work. And then things like jails and virtualizers, memory management. And there are bound to be differences in the fine details of multi-threading and the different kernel schedulers. Also when we come to audio, secret rabbit code v. OSS... still, it's an interesting experiment. I guess the graphics stack is another area where there could be differences, although since freebsd ports some of the open source code developed primarily for linux anyway (eg, the intel open source driver), there may be more commonality than appears at first glance.
 
What in my opinion would be bad, would be 'one kernel to rule them all', ie replace the freebsd kernel with the linux kernel, which is essentially owned by IBM now, whether it be 'open source' or not. I think it's a very good thing to have a full-featured unix kernel available, that is not linux. Still, these are interesting technical experiments.
 
I was mostly just wondering what it would actually take to pull it off. That being said, you probably don’t want to do this, it’s like walking around with a live hand grenade in your pocket. The better approach would be to preserve the same look, feel, commands, and overall user experience while porting everything over to musl and the Linux kernel. It would still be bsd, because what makes something bsd is part lineage and part user experience, in the end whether its linux, minix, bsd, ... they all have the same grandfather.
 
You must log in or register to reply here.
Back
Top