From owner-svn-src-all@FreeBSD.ORG Mon Dec 1 19:17:14 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A985EC56; Mon, 1 Dec 2014 19:17:14 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F3B2AAE; Mon, 1 Dec 2014 19:17:14 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id r20so18563374wiv.8 for ; Mon, 01 Dec 2014 11:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z7WajObiCzeBQnLHJeKq8GxacTAdHKfGh5hzHkTE0z0=; b=OL53GfjiBYgTIX8Lld3B6bpurfnj7SK/Xm0iD88CDKExpgMiXXabdQbcc8h3AOMVHE QTZPtvHw9TyvOlWZ2RExHuwYIzg3Qv5aoF7xXcVLUWPeU/gFteFrLLerOW9XUaUB6OEo 5osUJFGE/LGfsKmTW5s3oifcRy9fRPCyL01TzapLAE3ehbvcWSse2XL5AENCgkhfsK1I lcyBQ7AiqhcSpiaLP+fzta0K+91LwRUvQTDsQxQvkd0M1GSnMT49YwQfMVAWw4K2Zjmz FhHROziEDCP7M1x0quUVyQhT3Qp2pHV3CTJnEjCwiCnDh+wA8sqdwvpjoLn/D4NqzXyP n6oQ== MIME-Version: 1.0 X-Received: by 10.180.75.199 with SMTP id e7mr87888911wiw.21.1417461432653; Mon, 01 Dec 2014 11:17:12 -0800 (PST) Received: by 10.194.81.233 with HTTP; Mon, 1 Dec 2014 11:17:12 -0800 (PST) In-Reply-To: <547CBBC9.2070408@freebsd.org> References: <201411262019.sAQKJaw4043557@svn.freebsd.org> <39377603.10OyiSzjWY@ralph.baldwin.cx> <872C180A-6ADD-469F-A801-3728DF134EEC@mu.org> <547C88A9.1070007@selasky.org> <5E1B6CD4-BBA7-4AD0-9982-E981015AF138@mu.org> <547C8A9C.4080603@selasky.org> <547C8CA2.8040305@selasky.org> <547C8DEF.5020809@selasky.org> <547C974A.9050302@selasky.org> <4CE4C10D-93B0-4E27-878D-34C0A7CF3C94@mu.org> <547C995A.2060005@selasky.org> <547CBBC9.2070408@freebsd.org> Date: Mon, 1 Dec 2014 11:17:12 -0800 Message-ID: Subject: Re: svn commit: r275136 - in head/sys: dev/e1000 dev/ixgbe kern sys From: Jack Vogel To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky , Alfred Perlstein , John Baldwin , "svn-src-all@freebsd.org" , Alfred Perlstein , "src-committers@freebsd.org" , "svn-src-head@freebsd.org" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 01 Dec 2014 19:17:14 -0000 Not taking it personally, in this case I see some style things I don't like, and I'm not at all clear why this is even necessary, what the old way of doing queue config was missing for instance? Thanks Steve, Jack On Mon, Dec 1, 2014 at 11:04 AM, Steven Hartland wrote: > > On 01/12/2014 16:46, Alfred Perlstein wrote: > >> >> On Dec 1, 2014, at 8:37 AM, Hans Petter Selasky wrote: >>> >>> Hi, >>> >>> I think you maybe missed a point .... >>> >>> On 12/01/14 17:31, Alfred Perlstein wrote: >>>> >>>> Yes that is why it is being done by hand in the probe routine. I think >>>> proper thing might be a way to sort out how to get tunables to run at a >>>> driver load event? Is that possible? >>>> >>> All sysctls are tried init when they are created, both so-called >>> "static" and "dynamic" ones. >>> >>> If the sysctl is created inside the probe routine and has the tunable >>> flag set, it will get init before the creation is complete, if present in >>> the boot environment. >>> >>> If the sysctl is of a "static" kind, it will be created and initialized >>> when SI_SUB_KMEM is executing! >>> >> I totally understand this. It is in the phabricator review. :) >> >> As a more general comment, my personal preference when I ask for review > is that at least one of the reviewers accepts the final revision before I > commit, but preferably all that have taken part in the discussion. This > often takes a bit longer and some times takes a little prodding but should > be worth it in the long run. > > I know I commented on this one but I unfortunately didn't get chance to > look after changes where made and hence never accepted the revision. Had I > done so I would have caveat-ed it with it being accepted by Jack or other > Intel delegate in his absence, so sorry about that Jack. > > No one should take this personally, as know this is still new to everyone, > but it does raise the wider question of who should be counted as a > "reviewer" from phabric and do we need some additional guidelines on this, > or even better can it be automated? > > Regards > Steve > >