From owner-freebsd-arch@FreeBSD.ORG Wed Sep 5 06:33:07 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07E55106564A; Wed, 5 Sep 2012 06:33:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C19648FC14; Wed, 5 Sep 2012 06:33:05 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA12902; Wed, 05 Sep 2012 09:33:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1T99Ad-0002MC-VQ; Wed, 05 Sep 2012 09:33:04 +0300 Message-ID: <5046F21F.2080603@FreeBSD.org> Date: Wed, 05 Sep 2012 09:33:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120901 Thunderbird/15.0 MIME-Version: 1.0 To: Andrey Zonov References: <503DD433.2030108@FreeBSD.org> <201208290906.q7T96C9j032802@gw.catspoiler.org> <20120829092318.GW33100@deviant.kiev.zoral.com.ua> <503F2D24.8050103@FreeBSD.org> <503F476E.1010505@FreeBSD.org> <50463610.6070805@FreeBSD.org> <50463EEB.60207@FreeBSD.org> In-Reply-To: <50463EEB.60207@FreeBSD.org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Edward Tomasz Napierala , freebsd-arch@FreeBSD.org Subject: Re: [patch] unprivileged mlock(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 06:33:07 -0000 on 04/09/2012 20:48 Andrey Zonov said the following: > On 9/4/12 9:10 PM, Andriy Gapon wrote: >> on 30/08/2012 13:58 Andrey Zonov said the following: [snip] >>> [2] http://people.freebsd.org/~zont/racct.patch >> >> This patch looks correct. >> > > There is no need for this patch as I mentioned earlier. racct_set() > doesn't add any additional locking here. I thought that hiding the racct call behind RACCT was a worthy target on its own. >> And it also makes me wonder why kern/kern_racct.c is marked as standard while >> all(?) uses of racct API are placed under RACCT option. > > Not all. I think some code was not easy to put under RACCT. But perhaps it should still have been a goal for this optional feature. Unfortunately, Edward hasn't replied yet. >> Ditto for kern_rctl.c/RCTL. >> I think that excluding these file if the options are not used would help to catch >> cases where the API is used unconditionally and it would also help to reduce >> kernel sizes a tiny bit too. -- Andriy Gapon