Date: Mon, 27 Aug 2007 17:38:08 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: src-committers@freebsd.org, peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, "M. Warner Losh" <imp@bsdimp.com>, yar@comp.chem.msu.su Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <Pine.GSO.4.64.0708271719510.28508@sea.ntplx.net> In-Reply-To: <200708271715.21462.jhb@freebsd.org> References: <200708270850.20904.jhb@freebsd.org> <20070827.141125.-1573947069.imp@bsdimp.com> <Pine.GSO.4.64.0708271648570.28508@sea.ntplx.net> <200708271715.21462.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 27 Aug 2007, John Baldwin wrote: > On Monday 27 August 2007 04:55:31 pm Daniel Eischen wrote: >> On Mon, 27 Aug 2007, M. Warner Losh wrote: >> >>> In message: <200708271529.42264.jhb@freebsd.org> >>> John Baldwin <jhb@freebsd.org> writes: >>> : And yes, I do think it's ok for -current to have rougher edges. After > all, we >>> : aren't really trying to get people running -current on production > systems. >>> >>> I think it is OK for -current to have rougher edges. I don't think it >>> is OK to require -current to have rougher edges. >> >> I think we can agree on that! I also think there is some confusion >> over whether adding ABI changes to an existing symbol version would >> force us to rebuild ports. It doesn't. Once symbol versioning is >> released in 7.0, we can create a new version (FBSD_1.1, or add to >> the existing FBSD_1.1 depending on how the FTS stuff goes) and add >> all the (non-overlapping) ABI changes we want to it _without_ having >> to rebuild ports. This is a tremendous advantage over -current as >> it is today. > > So you want to just bump the version everytime a change happens in HEAD? No, I don't see how you get that from what I said... > That > seems to contradict your earlier changes as you are now saying use 1.1 for > fts(3), etc. Also since you mentioned MFC'ing one ABI (say 1.5) but not > others (1.2-1.4), that implies each change in HEAD has its own first-level > version? FBSD_1.1 should get us out a few years. Unless you have an ABI change that is _already_ in FBSD_1.1, you don't have to create a new version. An example (for the sake of this example, let's assume that all non-fts symbols are in FBSD_1.0, and fts_* are in FBSD_1.1): FILE changes in -current, the new symbol map would add the FILE-related APIs. FBSD_1.1 { fts_open; <- existing fts_read; <- existing ... fts_close; <- existing fopen; <- new fread; <- new ... fclose; <- new } FBSD_1.0; A week later, pthread_mutex_t changes in -current. You add the pthread_mutex_t-related APIs: FBSD_1.1 { fts_open; <- existing fts_read; <- existing ... fts_close; <- existing fopen; <- existing fread; <- existing ... fclose; <- existing pthread_mutex_init; <- new pthread_mutex_lock; <- new ... pthread_mutex_destroy; <- new } FBSD_1.0; You are not forced to rebuild any ports by adding symbols to FBSD_1.1. Everything that was built before the pthread_mutex_t change will work after the change. You can keep adding to FBSD_1.1 and only need to go to FBSD_1.2 if one of the APIs in FBSD_1.1 undergoes yet another ABI change. If the fts_* stuff goes in now as FBSD_1.0, I guess you don't need to go to FBSD_1.1. You can stay at FBSD_1.0 until you have the next ABI change. If fts_* goes in now as FBSD_1.1 (and assuming all the other symbols stay at FBSD_1.0), then you can just keep adding to FBSD_1.1 after the branch/release. If all the symbols along with fts get pushed to FBSD_1.1, then you have to go to FBSD_1.2 at the next ABI change. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0708271719510.28508>