Mismatched kernel and userland

[lgrant]

I hope you will excuse this newbie question. (I am not a newbie to FreeBSD as a whole; just to parts of it.)

I read about distributions with a FreeBSD kernel and a Linux userland, or the other way around.

Am I correct in thinking that this would be a non-trivial project?

it would seem like the system calls would not match up exactly.

Or does POSIX standardize down to this level?

Thanks!

 

[SirDice]

I read about distributions with a FreeBSD kernel and a Linux userland, or the other way around.

Debian -- Debian GNU/kFreeBSD

Am I correct in thinking that this would be a non-trivial project?

It is. Project was pretty useless too in my opinion.

In any case, nothing of this is supported. Kernel and userland are treated as a whole. Even a mismatched version kernel and userland isn't supported.

 

[lgrant]

Debian -- Debian GNU/kFreeBSD

It is. Project was pretty useless too in my opinion.

In any case, nothing of this is supported. Kernel and userland are treated as a whole. Even a mismatched version kernel and userland isn't supported.

Thanks. Yes, it sounded kind of useless to me, too. (Kind of like the guy I knew who put a V6 engine in his Chevette. It was very fast, but almost impossible to control, and definitely unsupported.)

Luckily, I wasn't planning on using it; just trying to learn more about the kernel/userland boundary.

 

[ralphbsz]

it would seem like the system calls would not match up exactly.

Or does POSIX standardize down to this level?

For pure user space programs, written in C (or languages that use the C bindings) and which only use "boring" services, POSIX is (or more accurately was) a godsend. If you want to do things like open files, read and write, deal with sockets and threads, then just programming using the documented POSIX interfaces makes life much easier. For this reason, in the late 90s and early 00s, I refused to keep OS-specific documentation binders in my office; instead I had various O'Reilly POSIX books, which I used as references when writing portable programs.

BUT: This really doesn't go very far. It helps with C programs using system services. In theory, it might be possible to write shell scripts using only the POSIX standard shell; in practice, I've seen an engineering group have the discipline to do so. Even within things that POSIX standardizes (such as AIO), the implementations can be so radically different from each other (remember the Linux 2.4 and 2.6 AIO implementation, which in reality was faked in user space on RedHat, causing all manner of interesting race conditions and deadlocks, while technically conforming to POSIX) that writing programs that function well and efficient is often impossible without becoming OS specific. And once you get into interesting system services, POSIX is out of scope. For example: How do you implement the ps command? How do you enumerate attached USB devices, and get alerts when devices are attached/detached? And once you are into GUI interfaces, all standardization comes apart. Same with file systems and device drivers. It's hard.