From owner-freebsd-hackers Mon Jun 26 15: 4:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4E51B37B7EE for ; Mon, 26 Jun 2000 15:04:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA30219; Mon, 26 Jun 2000 15:04:49 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jun 2000 15:04:49 -0700 (PDT) From: Matthew Dillon Message-Id: <200006262204.PAA30219@apollo.backplane.com> To: John Polstra Cc: chris@calldei.com, hackers@FreeBSD.ORG Subject: Re: struct proc References: <3957ABBD.6010407@mail.ru> <20000626111453.E20702@holly.calldei.com> <200006262020.NAA16125@vashon.polstra.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> p is the process that made the syscall, curproc is the current :> running process. You should be using p for the process that :> called my_syscall. : :Since only one process can enter the kernel at a time (currently), :and p is the process that made the system call, it is also the :current process. I claim that (p == curproc) in this example, and :that it would be better to code with p than with curproc. : :John : John Polstra jdp@polstra.com :... Even in an MP system, curproc is not going to be ripped out from under a syscall. p will always be curproc. (curproc in an MP system is a per-cpu variable). 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message