From owner-freebsd-current Wed Sep 12 13:12:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 3157B37B40C; Wed, 12 Sep 2001 13:12:13 -0700 (PDT) Received: from laptop.baldwin.cx (john@[147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA13464; Wed, 12 Sep 2001 13:11:00 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 12 Sep 2001 13:10:53 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: Re: HEADSUP!!!! KSE Milestone-2 COMMITTED Cc: current@FreeBSD.org, Ruslan Ermilov Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 12-Sep-01 Julian Elischer wrote: > My comment is that if this is a locking change than it should be part of > the locking changes.. > so it's just each of us 'batting' to put the patch in the other > set.. You could have done 'suser(td->td_proc)' but instead you have changed an API that now has to be unchanged. :( Hence we have people asking about whether or not to document the suser_td() function. This would not have required the 'p' variable and would have preserved the API, which is perfectly acceptable in this case seeing as how ucred's are per-proc and not per-thread, thus suser() still is a proc related check, not a thread related one as suser_td() seems to imply. No bother, it will all be backed out eventually anyways. :-/ -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message