From owner-freebsd-hackers Mon Oct 23 15:09:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA01783 for hackers-outgoing; Mon, 23 Oct 1995 15:09:16 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA01761 for ; Mon, 23 Oct 1995 15:09:04 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id QAA23005; Mon, 23 Oct 1995 16:10:56 -0600 Date: Mon, 23 Oct 1995 16:10:56 -0600 From: Nate Williams Message-Id: <199510232210.QAA23005@rocky.sri.MT.net> To: Terry Lambert Cc: syssgm@devetir.qld.gov.au (Stephen McKay), swallace@ece.uci.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c In-Reply-To: <199510232105.OAA11752@phaeton.artisoft.com> References: <199510230953.TAA22795@orion.devetir.qld.gov.au> <199510232105.OAA11752@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > We need a better way to handle these syscall subcodes (as SYSV > > > calls 'em). > > > > Is it not true that this System V stuff can be written as library > > routines that use BSD facilities such as mmap() and sockets? I > > would be happy to see the effort expended this way so that I can > > keep my kernel free of such cruft. > > This assumes: > > 1) The SYSV code uses shared libraries > 2) Someone (you?) has written library replacements so that > real SYSV shared libraries need not be used > 3) No one is interested in running statically linked IBCS2 > binaries, only dynamically linked ones. I think Stephen is implying that instead of adding the code to do the syscalls inside the kernel, you could somehow 'call' a library routine which is external to the kernel. If you could do such a thing, then none of the above are applicable. But, I believe the current 'macro-kernel' system used in BSD precludes us doing such things. Nate