cvs commit: src/lib/libc/locale utf8.c

[Rong-en Fan]

On 10/27/07, Scott Long <scottl at samsco.org> wrote:
> John Baldwin wrote:
> > On Thursday 25 October 2007 07:04:08 pm Scott Long wrote:
> >> Robert Watson wrote:
> >>> On Thu, 25 Oct 2007, Andrey Chernov wrote:
> >>>
> >>>> On Thu, Oct 25, 2007 at 12:05:40PM -0700, LI Xin wrote:
> >>>>> Well, I think the problem is not exposing a new symbol by itself, but
> >>>>> __mb_sb_limit is being used in _ctype.h, in a form of __inline
> >>>>> functions. Therefore, the change will break new binaries running on
> >>>>> older systems.
> >>>> Yes. Only vice versa compatibility supported.
> >>> I think the issue here is that the change occurred very quickly after
> >>> the branch, and when users wanted to 'change gears' back to RELENG_7
> >>> from HEAD once it was created immediately ran into the problem.  It
> >>> seems like a useful piece of post-branch advice to developers in the
> >>> future will be, "Please don't do things that make switching branches --
> >>> back or forward -- for the first few weeks after the branch is
> >>> created".  In general, I don't think we care about forward
> >>> compatibility, but we are currently getting lots of reports because this
> >>> is one of those few times where a lot of moving backward happens.
> >>>
> >> We do care about forward compatibility within STABLE branches, as Ken
> >> and I have discussed in side threads.  But yes, forward compat between
> >> major branches is merely desired; i.e. changes will happen, and
> >> hopefully not for gratuitous reasons.
> >
> > If we care about forward compatiblity then we can't add new features to
> > RELENG_X branches.  For example, MFCing MSI to 6.x broke forward compat since
> > a 6.3 module might call the MSI methods thus can't be used on a 6.2 kernel.
> > AFAIK, we have _never_ promised anything wrt forward compat, only backwards
> > ABI compat.  I can agree with Robert above that during a transition time such
> > as now it's really handy to be able to switch easily between branches, but I
> > didn't think it was ever a concern otherwise.  If we are going to change the
> > policy for that then there's a whole bunch of crap I need to go back out of
> > 6.x to restore compat. :-/
> >
>
> You're right that nothing can be promised, but you're ignoring what Ken
> and I are saying about having a justification for changes.  Yes, MSI
> added a feature that wasn't present in previous releases.  But it's
> something that is optional and can be easily ifdef'd in source.  The
> ctype ABI change isn't like that at all; it's mandatory and it can't be
> worked around.  We also asked that even justifiable changes be evaluated
> to see if there was any work-around to avoid breakage.  Several have
> already been suggested for the ctype change.

I admit that I really did a very bad abi damage on libc. I have been
working on it and
removing those inline __* functions in _ctype.h help. It can be upgraded and
also downgraded without problems. Without those inline stuffs,
buildworld+installworld
time difference is less than 60 seconds, which looks good. I will post the
patch after some more tests.

As for RELENG_7 and HEAD, I'm not 100% sure whether we should restore
the compatibility as 1) 7.0 is not released yet, 2) we don't promise
anything in
HEAD branch. However, if most people think get rid of inline stuffs and
have libc compatibility are nice, then we do the same for those two branches.

Regards,
Rong-En Fan

>
> Scott
>
> _______________________________________________
> cvs-src at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/cvs-src
> To unsubscribe, send any mail to "cvs-src-unsubscribe at freebsd.org"
>