From owner-svn-src-head@FreeBSD.ORG Wed Aug 21 15:31:05 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 07688E86 for ; Wed, 21 Aug 2013 15:31:05 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 519EF246B for ; Wed, 21 Aug 2013 15:31:04 +0000 (UTC) Received: (qmail 72800 invoked from network); 21 Aug 2013 16:14:08 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Aug 2013 16:14:08 -0000 Message-ID: <5214DD31.6010205@freebsd.org> Date: Wed, 21 Aug 2013 17:30:57 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Davide Italiano Subject: Re: svn commit: r254524 - head/sys/sys References: <201308191356.r7JDuELE075073@svn.freebsd.org> <521257E2.4020502@FreeBSD.org> <5213AAA1.6020700@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Navdeep Parhar X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 15:31:05 -0000 On 20.08.2013 20:13, Davide Italiano wrote: > On Tue, Aug 20, 2013 at 7:42 PM, Andre Oppermann wrote: >> On 19.08.2013 19:37, Navdeep Parhar wrote: >>> Why reuse the freed up bits so soon (at least one of which I think was >>> prematurely GC'ed -- see my other email on M_NOFREE). There was room >>> beyond M_HASHTYPEBITS, no? >> >> This is HEAD where kernel and modules have to be (re)compiled together >> at any point in time. On stable this reuse would not have been possible. >> >> In a subsequent commit I compacted and ordered the flags. There's a couple >> of free ones remaining. >> >> I have some additional mbuf changes coming up to be posted for possible >> objections later today. The close HEAD freeze deadline has got me rushed >> a bit to allow 10.x backporting of the checksum/offload overhaul. >> >> -- >> Andre >> > > In my opinion the possibility we have about breaking KPI/KBI should > not be abused, even if it's allowed in HEAD. In other words,people > should go for preserving it when (as in this case) it's easy and > without additional costs. Your point about "this is HEAD, it can be > broken at any time" makes relatively little sense to me. Note that in > the worst case such KPI/KBI breakages are annoying for $VENDORS who > maintain out-of-tree code, which need to rebuild/change their code, > or, if they get pissed off, drop FreeBSD support. > In your case, it's just a matter of "code cleaness" about few lines, > which, IMHO and always IMHO, doesn't justify the breakage. Preserving the API but having to recompile is always fair game in HEAD. In fact it happens all the time and the only supported way to track HEAD is to recompile kernel and modules together. For removing (crufty) functionality I agree that it shouldn't be done just for the sake of it and also shouldn't be done often. Sometimes it is necessary in the name of progress. Having to support old, crufty or broken ways of doing something is a waste of developer time too. It's always a judgement call. In this case there is a perfectly valid alternative way of doing that also is less dangerous to leak mbufs. -- Andre