From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 12:58:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 164ED16A4DE; Fri, 4 Aug 2006 12:58:01 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46BDE43D7F; Fri, 4 Aug 2006 12:57:53 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k74CvqhX020878; Fri, 4 Aug 2006 08:57:52 -0400 (EDT) Date: Fri, 4 Aug 2006 08:57:52 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John-Mark Gurney In-Reply-To: <20060804050242.GC58082@funkthat.com> Message-ID: References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> <20060802165604.GA970@troutmask.apl.washington.edu> <20060802172505.GA1935@troutmask.apl.washington.edu> <20060804050242.GC58082@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: "Matthew D. Fuller" , freebsd-current@freebsd.org, Andrew Thompson , Steve Kargl Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 12:58:01 -0000 On Thu, 3 Aug 2006, John-Mark Gurney wrote: > Steve Kargl wrote this message on Wed, Aug 02, 2006 at 10:25 -0700: >> Almost everything on a FreeBSD system depends on libc. Bumping >> its version number without careful coordination of bumping all >> other version numbers is full of landmines. Falling back of the >> retort "this is -current expect problesm" just glosses over what >> appears to be sloppy planning. > > Ummm.. don't we have have symbol versioning? isn't this exactly > what symbol versioning is for? I haven't been following this > particular discussion, but I thought now that we have symbol versioning > in the tree that we never have to bump the numbers? or is this failure > to have a proper document to tell someone what to do when they change > the API and provide the correct hooks for the new versions? We have symbol versioning but it isn't enabled by default yet. We're waiting for the library versions to be bumped before enabling it. We can't support old non-symbol-versioned ABIs (e.g. libc.so.6) in a symbol-versioned library so we need to bump the library versions before enabling it. -- DE