cvs commit: src/include string.h src/lib/libc/string
Makefile.inc memchr.3 memrchr.c src/sys/sys param.h
deischen at freebsd.org
Wed May 28 18:50:31 UTC 2008
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.
More information about the cvs-src