On Tue, 24 Oct 2006, Maxim Sobolev wrote:
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.
I believe the problem is not taking a pointer as a direct argument;
copyin/copyout deal with that fine. The problem is embedded pointers within
data structures, causing the passed data structure to be different sizes for
32-bit/64-bit processes. I could be mistaken.
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.
The real problem here is that freebsd32 remains a second class citizen, with
many important system calls not implemented. For new system calls, the
responsibility for that lies with the implementor (in the case of audit, me).
For old ones, presumably that lies with incomplete work done in the freebsd32
compat code, and will continue to be a problem until that is fixed.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
