Subject: Re: Behavior of calling System V shared memory functions if not in kernel
To: None <firstname.lastname@example.org>
From: David S. Miller <email@example.com>
Date: 12/02/1994 22:55:00
Date: Fri, 02 Dec 1994 09:12:48 -0800
From: Greg Earle <firstname.lastname@example.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.
David S. Miller