cvs commit: src/include string.h src/lib/libc/string Makefile.inc memchr.3 memrchr.c src/sys/sys param.h

[Daniel Eischen]

On Wed, 28 May 2008, David Schultz wrote:

> On Wed, May 28, 2008, Daniel Eischen wrote:
>> No, all new symbols in 8-current go into FBSD_1.1, not 1.2.  The
>> only time we go to 1.2 is when 8.x branches to 9.0.  If for some
>> reason memrchr() were to change its ABI, then we would go to 1.1.1
>> in -current for the ABI change and any subsequent new symbols, and
>> the MFC to 7.x would also be 1.1.1.
>>
>> It is ok for a FBSD_1.1 in -current to be a superset of FBSD_1.1
>> in a previous branch.  In fact you can't prevent them from being
>> different unless you mandate that all new symbols get MFC'd to
>> their respective namespaces in previous branches.
>
> Perhaps I misinterpreted what you said about this last year, but I
> thought you said you didn't want symbols added to existing
> namespaces in -STABLE. In 7.X, why would it be okay to add new
> symbols to FBSD_1.1 between releases but not to FBSD_1.0?

I think you're just off by a version.  -stable didn't have
FBSD_1.1, so we just _did_ add memrchr() to a _new_ namespace
in -stable.  All new and changed symbols in 8-current go
in FBSD_1.1, never in FBSD_1.0.  So they can be MFC'd
in the same namespace that -current as using.  After we
branched 7.0 from -current, the FBSD_1.0 namespace was
frozen.  This will happen everytime we branch from -current.

-- 
DE