Subject: Behavior of calling System V shared memory functions if not in kernel
To: None <firstname.lastname@example.org>
From: Greg Earle <earle@isolar.Tujunga.CA.US>
Date: 12/02/1994 09:12:48
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.