Date: Sat, 2 Aug 2003 10:45:29 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Mike Silbersack <silby@silby.com> Cc: arch@freebsd.org Subject: Re: Another 4.x ABI question; uidinfo Message-ID: <Pine.NEB.3.96L.1030802104301.98114E-100000@fledge.watson.org> In-Reply-To: <20030801235716.T2165@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030802104301.98114E-100000>