In 1.0, if one calls, e.g., "shmget()" et al. without having a kernel that was
built with "options SYSVSHM", the program is delivered a SIGSYS (Bad system
call) and it usually core dumps.

Is this the proper behavior?  A program could catch SIGSYS and make some
appropriate assumptions ("Hmmn, I probably caught that SIGSYS because I tried
to do a shmget() and there must not be any support compiled into the kernel"),
but I should think that instead, "shmget()" and friends should return ENOSYS
if they can't call "symsys()", so that the program can react "normally" and
handle the error.

I mentioned previously that it looks like the shared memory stuff is going
through some changes.  I am anxious to know what the status is (and whether
a back-port patch for the above problem would be considered).  Two programs
that do MBONE video - "nv" and "vic" - have support for using the X11 MIT-SHM
extension and would really, really rather use shared memory if it is available.
Rather than build a binary to distribute with shared memory support disabled,
it would be better that the binary support SHM and have the OS return a
reasonable (ENOSYS) error that the program can handle if it is not enabled in
the kernel (i.e., no "options SYSVSHM").  Both programs, in fact, are set up
to do this - if shmget() were to return an error, they both know to disable
further operations involving use of shared memory.

	- Greg