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.
-Maxim _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
