From owner-freebsd-hackers Tue Oct 31 17:12: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-178-14.dsl.snfc21.pacbell.net [63.202.178.14]) by hub.freebsd.org (Postfix) with ESMTP id C477A37B4C5 for ; Tue, 31 Oct 2000 17:11:56 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eA11GD429727; Tue, 31 Oct 2000 17:16:13 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011010116.eA11GD429727@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Lars Eggert Cc: hackers@freebsd.org Subject: Re: curproc question In-reply-to: Your message of "Tue, 31 Oct 2000 17:05:13 PST." <39FF6C49.31D1ABE8@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Oct 2000 17:16:13 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > > During a system call inside the kernel, can I safely assume that curproc > > > points to the process that issued the call? For example, will looking at > > > curproc in ip_output() tell me which process is responsible for generating > > > the packet? > > > > No. > > Too bad. In which cases wouldn't it point at the "correct" process? Maybe I > could tolerate those. Anytime the upcall process had been blocked, or when NATing, or when routing. Have a look at the way that per-UID limites are implemented in ipfw... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message