[adrian_b]

While not basing the OS on POSIX is good, if you ever want to use it for more than a hobby, i.e. if you ever want to use it for your main personal computer, you will also need a translation layer for the LINUX syscalls, which would enable you to compile and run any of the existing open-source programs, or even run existing binaries.

Porting the programs that you are more interested in from Linux or *BSD to your own OS is the best, but this is necessarily slow and also the work of porting rarely used applications may not be worthwhile.

An alternative to a syscall translation layer is for your OS to act as a hypervisor for Linux or other OSes VMs. However, this would have a lower performance than using natively your IPC-based OS.

[noone_youknow]

I agree that for it to be generally useful, it’ll need to be easy to port existing software to. But I don’t think I’ll need a translation layer at the syscall level (unless I want to expose a Linux-compatible ABI as you suggest, which is totally a non-goal).

You can get surprisingly far in this area with a decent libc implementation - once you have that porting a lot of things becomes possible. There will always be harder problems (e.g. anything that hard-depends on fork) but with enough work pretty much anything in user-space should be possible to port eventually.

I’m using newlib for libc, with a custom Anos-specific libgloss that mostly talks to SYSTEM via IPC to get stuff done, and uses syscalls where needed (and a process has the appropriate capabilities). I’m filling out that low-level interface as I go, and will be using porting of exiting BSD or Linux software to drive that implementation :)

[adrian_b]

I agree that instead of implementing the Linux syscalls implementing just those libc functions that are OS dependent is sufficient for a large fraction of the existing programs.

However, this means implementing a POSIX layer, similarly to Windows NT. So it is a solution more distant from a "non-POSIX operating system".

While a large part of the Linux syscalls have been motivated by the necessities of implementing POSIX, there are also significant differences and the Linux applications that require the best performance must deviate significantly from POSIX, so they are no longer based on libc for I/O.

[noone_youknow]

There would likely be value in a POSIX layer as you describe, at least from the point of view of porting existing programs. And perhaps it will happen, if I get far enough along, but it will never be a kernel feature - it would be an entirely userspace concept intended only to speed up porting and building out said user space.

Perhaps in the fullness of time essential software can be rewritten to Anos’ “native API”, or perhaps that’s a pipe dream and not worth the work, but the option will be there.