>
> > >Core has stated in the past a strong desire for developers not to
> > >break kernel interfaces within minor releases.
> >
> >
> > 4.1 broke that "policy" rather badly. Perhaps its time to get rid of the
> > mbuf macros, as any change to that structure breaks binary compatibility
>in
> > the worst way possible.
> >
> > DB
>
> The "problem" was not with the macros themselves, but with the fact that
> your outdated binary was compiled with old definitions of some structures
> which were later changed (mbstat structure). The changes that happened
> there were relatively minor. I'm sure you would know all this had you
> debugged the problem yourself, but it turns out that all you provided in
> terms of "support" was whining and directing blame at the FreeBSD team.
The entire point is that "relatively minor" changes will break a binary
compiled for 4.1-RELEASE if -STABLE does not adhere to the principles of
binary compatibility. If the code has to be recompiled to work safely, then
binary compatibility is broken, for those of you who dont know what we are
talking about here.
A vendor cannot support every possible -STABLE release if binary
compatibility is not maintained. Usually, -RELEASE compilations work across
-STABLE.
We didnt "whine", you whined. You tried to use an unsupported version of
the OS and it didnt work. Surprise, surprise.
> I disagree with not merging in fixes to -STABLE that help maintain code
> in general, for the entire project; In this case, the change helped
>userland code
> such as netstat(1) deal with mbtypes. This wasn't a "big interface change"
>by
> any means. Plus, it was discussed on -net and since -net directly concerns
>you
> and your driver, perhaps you should read it every once in a while. Had we
>not
> merged this change to -STABLE, I'm sure we would have had just as many, if
> not more requests: "MFC MFC, you guys are ignoring -STABLE!" as we
> have now with you complaining about the change being made. A wise man
> once said something along the lines: "you can never win with tire-kickers,"
> and now I see how he was right.
Thats why there is a FreeBSD core team, so that only people that understand
the principles of OS distribution are involved in the process. You can
never make everyone happy, so you do whats correct and let the ignorant be
unhappy. Its why companies develop policies, so they dont have to cater to
every request individually. Not everyone will like every policy, but they
are consistent so that order can be maintained.
Do you see what happens when you give source code to amateurs? What a
headache. His argument "make the change because people need it" is more of
the LINUX camp mentality than what has been FreeBSD's policy. Its important
to make the distinction.
Stability is tantamount. Every time you make a change stabilty is
potentially compromised. -STABLE should imply that stability is not at issue.
DB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
