Robert Watson wrote:
> The method by which the distinction between ENOSYS+SIGSYS and plain
> ENOSYS is determined is in the implementation of the system call. If a
> system call is flagged as unimplemented (i.e., you never hit the
> function implementing it), you get SIGSYS+ENOSYS. If you enter the
> stub, you get ENOSYS. So the problem is that the compat code doesn't
> enter the stub, so never gets to the ENOSYS path. A casual glance at
> the system call arguments for audit suggest that wrappers aren't needed
> (no pointers embedded in structure arguments), so simply marking them as
> implemented will likely work.
Well unless I have confused something it is not really the case. For
example, getauid() system call takes pointer as an argument.
But in fact you did not answer my question. I think we should have
ability to flag the syscall as optional in the compatibility layer, just
like we have ability to do so in the native layer, so that attempt to
call it results in ENOSYS but not SIGSYS. There is no point to mandate
implementing wrapper for the otherwise optional syscall - all userland
binaries that can call it should be ready to handle ENOSYS properly, so
that just returning ENOSYS unconditionally will hurt nothing, while
promoting binary compatibility until the call gets real wrapper. Just
like my own experience with failing su(8) suggests.