From owner-svn-src-all@FreeBSD.ORG Wed Aug 21 15:59:56 2013 Return-Path: Delivered-To: svn-src-all@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 48C83D64; Wed, 21 Aug 2013 15:59:56 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B19992618; Wed, 21 Aug 2013 15:59:55 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id gf11so381706vcb.39 for ; Wed, 21 Aug 2013 08:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Qa72VUObh0GwmtRyz0TDezMH0kApgjxNl7v47uAj+uE=; b=V3V+5Fvxe8waaEWkjw/CN++06HLOc5vLy+y2dKnFeKy0mrj6GW3eOljkLGFj8uwgx3 +etflA5v4sX8sTKuIAHOhPzQDcMVxigSxA1Ayr93SqIWlJLMh0IAURCRz0N9n0gva+UF FI2zlJpMmFFmAhYUQMjiwJrzSaT/sIgLkjaahzaGDMSMkQjaG9T6/1gYq6Fgw9j6aVvI 6YdJDmtUTpYT2Oh+aFHKw5Eh5Jnw5EhQDrdKhbhWQenviYrQQmQYn7S4VXf27W7ct9k2 g6dgx0R6TtDdYoUmDbvOD6/AjTO2eWxvn2iWA7pr5hvQEKWcSNF+3rVNm/AduG5uy1oI MopQ== MIME-Version: 1.0 X-Received: by 10.52.35.171 with SMTP id i11mr5982177vdj.4.1377100794500; Wed, 21 Aug 2013 08:59:54 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.65.132 with HTTP; Wed, 21 Aug 2013 08:59:54 -0700 (PDT) In-Reply-To: <5214DD31.6010205@freebsd.org> References: <201308191356.r7JDuELE075073@svn.freebsd.org> <521257E2.4020502@FreeBSD.org> <5213AAA1.6020700@freebsd.org> <5214DD31.6010205@freebsd.org> Date: Wed, 21 Aug 2013 17:59:54 +0200 X-Google-Sender-Auth: PbEb1t4qWmkwpbWsbTgslT_-VWo Message-ID: Subject: Re: svn commit: r254524 - head/sys/sys From: Davide Italiano To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Navdeep Parhar X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 15:59:56 -0000 On Wed, Aug 21, 2013 at 5:30 PM, Andre Oppermann wrote: > 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 > I don't see in any way how flags reordering might be in any way connected to mbufs leaks, alas. There's a similar recent('ish) discussion and it was decided to not compact/reorder flags. See r253662/r253775 for references. So, I'm not sure what's the de-facto policy, but still, as a community FreeBSD should decide one strategy and be stuck with that. It's a matter of being consistent, which, IMHO, is something that should not be undervaluated. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare