Cc: core@netbsd.org
   Date: Fri, 02 Dec 1994 09:12:48 -0800
   From: Greg Earle <earle@isolar.tujunga.ca.us>
   Sender: owner-current-users@netbsd.org
   Precedence: list
   X-Loop: current-users@NetBSD.ORG

   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.

A possibly correct behavior is to make the sysv shared-memory code be
a loadable kernel-module. If the kernel gets called with a sysvshm
system call and it finds that support is not present it can
dynamically load the sysvshm module. Then if the code isn't used after
a period of time it can dynamically unload the module untill someone
else demands it's services and start the cycle again. I think UnixWare
implements such a scheme.

Later,
David S. Miller
davem@nadzieja.rutgers.edu