From owner-freebsd-hackers Sun Dec 20 15:48:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07477 for freebsd-hackers-outgoing; Sun, 20 Dec 1998 15:48:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07472 for ; Sun, 20 Dec 1998 15:48:13 -0800 (PST) (envelope-from benedict@echonyc.com) Received: from localhost by echonyc.com (8.9.1/8.9.1) with ESMTP id SAA06894; Sun, 20 Dec 1998 18:48:11 -0500 (EST) Date: Sun, 20 Dec 1998 18:48:11 -0500 (EST) From: Snob Art Genre Reply-To: ben@rosengart.com To: Alfred Perlstein cc: hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 20 Dec 1998, Alfred Perlstein wrote: > Or.... what i'm now thinking is that once a process enters the kernel it > must run until it exits the system call. I have a problem with this > though, processes such as nfsiod/nfsd enter the kernel through a syscall > and never exit (according to design and implementation) how then are other > processes allowed into the kernel? As I understand it, more than one process can be in the kernel as long as all but one are asleep. That's why the kernel stack is per-process instead of per-system. I'm not sure about your splfoo() question. I suspect that kernel code is not supposed to sleep while interrupts are blocked. Chuck Youse told me that interrupts on the i386 use a mask instead of a level, so it may be that a process can sleep in the kernel with an interrupt blocked as long as no one else will be needing that particular interrupt. But this is pure speculation. Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message