Date: Mon, 01 Jan 2001 15:44:13 -0500 From: Dennis <dennis@etinc.com> To: "Bosko Milekic" <bmilekic@technokratis.com>, "Warner Losh" <imp@village.org>, "Taavi Talvik" <taavi@uninet.ee> Cc: "Bill Fumerola" <billf@mu.org>, "mouss" <usebsd@free.fr>, "G. Adam Stanislav" <adam@whizkidtech.net>, <hackers@FreeBSD.ORG> Subject: Re: FreeBSD vs Linux, Solaris, and NT Message-ID: <5.0.0.25.0.20010101152843.033da7f0@mail.etinc.com> In-Reply-To: <002201c071df$3e97df00$25cbca18@jehovah> References: <Your message of "Fri, 29 Dec 2000 01:40:19 %2B0200." <Pine.BSF.4.21.0012290117360.16998-100000@valu.uninet.ee> <Pine.BSF.4.21.0012290117360.16998-100000@valu.uninet.ee> <5.0.0.25.0.20001229140715.009c2c10@mail.etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > >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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.0.0.25.0.20010101152843.033da7f0>