From owner-freebsd-commit Mon Jan 8 03:37:57 1996 Return-Path: owner-commit Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA03122 for freebsd-commit-outgoing; Mon, 8 Jan 1996 03:37:57 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA03102 for cvs-all-outgoing; Mon, 8 Jan 1996 03:36:28 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA03021 for cvs-sys-outgoing; Mon, 8 Jan 1996 03:35:04 -0800 (PST) Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA03007 Mon, 8 Jan 1996 03:34:55 -0800 (PST) Received: (from peter@localhost) by jhome.DIALix.COM (8.7.3/8.7.3) id TAA02151; Mon, 8 Jan 1996 19:33:34 +0800 (WST) Date: Mon, 8 Jan 1996 19:33:33 +0800 (WST) From: Peter Wemm To: Doug Rabson cc: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= , CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern syscalls.master In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-commit@FreeBSD.ORG Precedence: bulk On Mon, 8 Jan 1996, Doug Rabson wrote: [..] > > No, not quite. Under the original system, all the syscall vectors > > pointed to enosys() if the appropriate option was no enabled. > > > > What I've done, is make the syscall vectors *always* call the functions > > and simply provide stubs that do a log() and enosys() if the option was > > not enabled. [] > What happens if a normal program (not a lkm) calls the ipc syscalls? It > used to generate a SIGSYS which was a good way to detect the presence of > shared memory support. I believe that people may use this in X servers > to optionally enable MIT-SHM extensions. Yeah, the enosys() is what was generating SIGSYS. I believe I've preserved the semantics of calling the syscall without the service being present. As I said above, the "new way" still ends up at enosys(). Before (without msgs for example): sysvec[SYS_MSGSYS] -> enosys(). After my change: sysvec[SYS_MSGSYS] -> msgsys() -> enosys(). The primary reason for this is that the two binary emulators wanted to call msgsys() and friends directly. So, you could not even load the linux LKM on a kernel without SYSVSHM, because there would be an ld error for undefined _shmsys. Now, it'll load into any kernel, and will return a SIGSYS signal and ENOSYS errno to the caller, as is normal.... The main difference is that there will be a log() as well. Well.. At least, that's what I *think* I've done.. :-) Cheers, -Peter > -- > Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com > Phone: +44 171 251 4411 > FAX: +44 171 251 0939 > >