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, 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>