Subject: Another pre-built SPARC kernel suggestion ... SYSVSHM
To: None <port-sparc@netbsd.org>
From: Greg Earle <earle@isolar.Tujunga.CA.US>
List: port-sparc
Date: 11/30/1994 04:26:43
I think Matthew Green's X11 R6 binaries were built to include the MIT-SHM
extension support (into the server and libXext). (I know mine are (-: )
If anyone runs a program that depends/wants to use that SHM support, it'll
undoubtedly try to grab a shared memory segment via shmget() & friends. If it
does, it will promptly dump core (SIGSYS - Bad system call) because the
two pre-built "install" kernels weren't built with "options SYSVSHM" defined.
Of course, this begats the question, does the System V Shared Memory segment
stuff work in 1.0, specifically in NetBSD/SPARC 1.0? I noticed this comment in
/usr/src/sys/arch/pc532/conf/NEWCONF:
#options SYSVSHM # System V shared memory; broken
I hope this just means it's broken in the PC532 port ... :-)
And whilel I'm asking, what is happening to it in -current? I just noticed
that /usr/src/lib/libc/gen no longer contains shmget.c, shmat.c, shmdt.c and
shmctl.c; is all this stuff being overhauled or thrown out completely?
(Adam? Charles?)
Thanks,
- Greg
P.S. I am asking because I'm well on my way to having a complete set of MBONE
tools - I've already a hacked SunOS "sd" and "vat" working (the Multicast
setsockopt() options in <netinet/in.h> got renumbered, grrrrr), and I'd
have a working set of "nv" and "vic" native binaries going if this SYSVSHM
stuff were solid/resolved. I can build the stuff with "NOSHM" switches
and the like to turn it all off, but performance is a lot better if it
were to work properly. So a definitive answer would be most appreciated!