Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Jan 1996 19:33:33 +0800 (WST)
From:      Peter Wemm <peter@jhome.DIALix.COM>
To:        Doug Rabson <dfr@render.com>
Cc:        =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= <ache@astral.msk.su>, CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org
Subject:   Re: cvs commit: src/sys/kern syscalls.master
Message-ID:  <Pine.BSF.3.91.960108191804.496C-100000@jhome.DIALix.COM>
In-Reply-To: <Pine.BSF.3.91.960108105028.482M-100000@minnow.render.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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
> 
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960108191804.496C-100000>