OSDev.org

Title.

I don't think it would be *too* difficult to get a very basic compatibility, but I think it's interesting to ponder nonetheless.

Are there any major obstacles that would render this impossible?

Hi,

hexcoder wrote:I don't think it would be *too* difficult to get a very basic compatibility, but I think it's interesting to ponder nonetheless.

Are there any major obstacles that would render this impossible?

If you're writing a "monolithic Unix-like kernel", this might actually be easier than not providing Linux ABI compatibility because you won't need to make minor changes to things like C/POSIX libraries (e.g. you'd be able to use GNU's libraries "as is").

If you're not writing a "monothic Unix-like kernel" then it's impossible to say - it could be relatively easy, but it could be an extreme nightmare too.

Of course ABI compatibility isn't very useful on its own - almost all of the software is open source and easy to recompile; and to run Linux binaries without recompiling you'd have to provide more than just the ABI (e.g. same file system layout, same "/proc" file system, same environment variables, compatible graphics and sound libraries, ...).

Cheers,

Brendan

There will probably always be the need to rewrite some software and use only standard libraries across systems more and more.

The programming environment wasn't probably ready to be distributed across many OSes when there were only 1 or 2 of them for desktop PCs. So now the code needs to be cleaned so that a single developer can realistically manage to port software portably by relying on implementing everything based on standard libraries present in any system, and clean the rest to use wrapper functions to minimize the usage of non-portable libraries and language versions that aren't currently supported in your own OS or others that you might need to use as a devloper.

I'm writing an microkernel-based OS that is source-compatible to Linux (but not binary compatible). That means implies implementing Linux-specific functions like epoll(), signalfd(), timerfd() just to name a few, Linux /proc and /sys file systems, netlink sockets, the Linux ioctl()s for devices in /dev. I definitely can be done, but if you're not writing a monolithic UNIX-like kernel, you'll have to spend a lot of time on designing IPC primitives that enable you to efficiently emulate the Linux stuff in user-space.

~ wrote:There will probably always be the need to rewrite some software and use only standard libraries across systems more and more.

The programming environment wasn't probably ready to be distributed across many OSes when there were only 1 or 2 of them for desktop PCs. So now the code needs to be cleaned so that a single developer can realistically manage to port software portably by relying on implementing everything based on standard libraries present in any system, and clean the rest to use wrapper functions to minimize the usage of non-portable libraries and language versions that aren't currently supported in your own OS or others that you might need to use as a devloper.

I get the distinct impression that this is just a small snippet from a larger conversation. Either than, or ~ forgot his meds again.