From owner-freebsd-hackers  Mon Jun 26 16:46:20 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94])
	by hub.freebsd.org (Postfix) with ESMTP id A69A337B9C6
	for <hackers@freebsd.org>; Mon, 26 Jun 2000 16:46:14 -0700 (PDT)
	(envelope-from bp@butya.kz)
Received: from bp (helo=localhost)
	by relay.butya.kz with local-esmtp (Exim 3.13 #1)
	id 136iZV-000DSi-00; Tue, 27 Jun 2000 06:45:45 +0700
Date: Tue, 27 Jun 2000 06:45:45 +0700 (ALMST)
From: Boris Popov <bp@butya.kz>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: John Polstra <jdp@polstra.com>, chris@calldei.com,
	hackers@FreeBSD.ORG
Subject: Re: struct proc
In-Reply-To: <200006262204.PAA30219@apollo.backplane.com>
Message-ID: <Pine.BSF.4.10.10006270634460.51466-100000@lion.butya.kz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, 26 Jun 2000, Matthew Dillon wrote:

>     This whole p vs curproc thing is a huge mess.  95% of the time
>     p == curproc.  The only places where it might not is in I/O ops
>     that are completed by an interrupt or (in the case of NFS) some
>     other process.

	Any chances to clean this up ? Eg., change the policy to either
pass p as parameter or use curproc, but not both. As example of curproc/p
mess I can point to VFS_ROOT() call which misses p parameter, but
obviously needs it.

--
Boris Popov
http://www.butya.kz/~bp/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message