Date: Mon, 8 Jan 1996 13:04:26 +0800 (WST) From: Peter Wemm <peter@jhome.DIALix.COM> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= <ache@astral.msk.su> Cc: 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.960108124809.557B-100000@jhome.DIALix.COM> In-Reply-To: <cB3t9ymWJ1@ache.dialup.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Jan 1996, =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > In message <199601080413.UAA09911@freefall.freebsd.org> Peter Wemm > writes: > > Modified: sys/i386/ibcs2 syscalls.master > > sys/kern syscalls.master > > Log: > > Remove the #ifdef SYSVSHM etc. Always call the functions, some stubs > > are about to go in. This is to fix the problem with the ibcs2 and linux > > lkm's not being able to call the sysv ipc functions unless the build is > > modified. > > Does it means completely nuking of SYSV* options? > If yes, at least /sys/conf/options needs modifications, > if no, I don't understand this idea well, please, explain... 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. So, we still have the ability to build a kernel without 99% of the sysv_shm/sem/msg stuff. We simply have stubs in their place. This means that the linux and ibcs2 lkms can be compiled to use the sysv functions always.. As it is at the moment, they are #include "opt_sysvipc.h" #ifdef SYSVxxx .. and the lkm makefiles "touch opt_sysvipc.h", so the lkm's could not use ipc _at all_, regardless of whether the kernel had it. Now, it'll work if it's there and enosys() if not, all with the same LKM binary. (well, that's the aim anyway.. :-) Also, this would be one step closer to having a LKM for the sysv ipc stuff itself - all that's needed now is to figure out how to allocate the maps etc which are normally done before the VM starts up properly. -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960108124809.557B-100000>