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: <[EMAIL PROTECTED]>
           John Baldwin <[EMAIL PROTECTED]> 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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to