From owner-freebsd-arch@FreeBSD.ORG Sat Aug 2 07:46:35 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86A8C37B401 for ; Sat, 2 Aug 2003 07:46:35 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C68D843F93 for ; Sat, 2 Aug 2003 07:46:34 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h72EjUai001082; Sat, 2 Aug 2003 10:45:30 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h72EjTnn001079; Sat, 2 Aug 2003 10:45:29 -0400 (EDT) Date: Sat, 2 Aug 2003 10:45:29 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20030801235716.T2165@odysseus.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Another 4.x ABI question; uidinfo X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2003 14:46:35 -0000 On Sat, 2 Aug 2003, Mike Silbersack wrote: > Ok, so I took another at the uidinfo ui_ref field being only a u_short > in 4.x. As I recall, the reason this was not changed to a u_int was > binary compatibility... however, as I look around the source tree, it > appears that the only places uidinfos are used are within kern/, and > then generally only by things touching procs. Thirdly, it appears that > the refcount is only modified within three functions in kern_resource.c, > and that ui_ref is the last member in that structure. > > So, is there _really_ a problem in promoting ui_ref to an int from a > short? As far as I can tell, any network or sound driver should be > completely insulated from such a change; do we have any other class of > binary modules to worry about? I'm guessing it would be fine, then -- if nothing is accessing it using libkvm, it shouldn't be a problem. Changing the last field in the structure won't change dereferences from other compiled kernel modules -- the only thing I think you'd need to worry about are reference count changes in other modules (possibly, but unlikely), or statically allocated uidinfo storage (unlikely). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories