There is nothing beyond SIGILL. Why would we want such a thing? We are operating in a source-code-available world. Why would any one us want to encourage a must-run-binaries future?
The history of syscall-compatibility in BSD operating systems has been forgotten. Back in the NetBSD days, Chris Torek had written 32-bit sparc code which was not part of 4.4BSD. His unmerged changes modified various parts of the kernel to be more like SunOS. To merge the code and transition the ABI to native, I created the first compat layer, including a stack-trick for argument rewriting. The SunOS compat later convered into BSDOS, hp300, and eventually linux compat. These approaches were eventually copied by other BSD's. None of the compat layers were ever complete -- maintaining such layers is always purely reactionary -- they will always be incomplete, very small numbers of developers use a small amount of their time to handle increasingly ugly edge cases on a best-effort basis, when an application requests something new. The compatibility is never 100%, therefore applications can hid edge cases and perform incorrectly. Therefore as time went by, we increasingly considered these incomplete poorly-maintained layers in the kernel, used by very few, as being BIG RISK, and deleted the code. Not interested in trying again. If you want to run binary garbage, setup a VM running an ACCURATE implimentation of the operating system the binary is intended to run on. Keegan Saunders <[email protected]> wrote: > Hello > > Is there functionality in OpenBSD similar to Linux's > "PR_SET_SYSCALL_USER_DISPATCH" [1] which provides a way for userspace to > handle foreign system calls? > > I am looking to run foreign software on OpenBSD after Linux compat was > removed. I think that this is a good middle ground as it would allow > developers to port these applications in userspace rather than adding more > code to the kernel. > > Please let me know if this is functionality that is welcome in the OpenBSD > kernel, I'd be interested in working on both the kernel and userspace code to > support this. > > [1] > https://lwn.net/ml/linux-kernel/[email protected]/ > > Thanks > K
