On Sun, 22 Oct 2006, Kris Kennaway wrote:
On Sun, Oct 22, 2006 at 08:48:20PM -0500, Jeremy Messenger wrote:
I guess I am safe then as I can ignore these cores.. Thanks! Isn't kernel
supposed to be avoid the crash? I don't see any of crash before I upgraded
to last night of RELENG_6.
It's not a crash, it's a configure script testing whether the syscall
exists, and the the test program gets the signal 12 to tell it that it
doesn't. This is expected behaviour.
We have several levels of "But that's not implemented". The level used for
system calls that are simply not defined is SIGSYS+ENOSYS. By default,
application calling these (undefined) system calls can catch the error if they
choose to, but will exit otherwise. The next level is to provide ENOSYS stubs
that return ENOSYS without generating SIGSYS; in some situations, this is
preferred. For example, we use this when AUDIT isn't compiled into the kernel
but login(1) calls an audit system call to see if audit is present. Finally,
there are a number of situations where a system call is implemented, but the
underlying object doesn't support the operation, in which case we often return
EOPNOTSUPP or variations on that them.
The SIGSYS+ENOSYS error code isn't a bug, but it seems likely that configure
would be a lot happier if we returned ENOSYS without SIGSYS. Right now, that
means hand-defining a stub that's conditionally compiled based on the feature
not being present. It might be nicer if we had a way to indicate that in the
system call table.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
