From owner-freebsd-current@FreeBSD.ORG Wed Jun 18 20:36:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FFF5C87; Wed, 18 Jun 2014 20:36:29 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14F5C2DCE; Wed, 18 Jun 2014 20:36:28 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E2CA11FE026; Wed, 18 Jun 2014 22:36:26 +0200 (CEST) Message-ID: <53A1F848.2020902@selasky.org> Date: Wed, 18 Jun 2014 22:36:24 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org Subject: Re: [RFC] Huge sysctl patch for the kernel coming - work in progress References: <53A179D5.8020604@selasky.org> <201406180944.17762.jhb@freebsd.org> In-Reply-To: <201406180944.17762.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 20:36:29 -0000 On 06/18/14 15:44, John Baldwin wrote: > On Wednesday, June 18, 2014 7:36:53 am Hans Petter Selasky wrote: >> Hi, >> >> Sometimes sysctl's default value needs to be setup at boot time and not >> when the rc.d/sysctl is running. Currently this is done by having two >> statements in the kernel: >> >> TUNABLE_INT("net.graph.mppe.log_max_rekey", &mppe_log_max_rekey); >> SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RW, >> >> I want to simplify this to: >> >> SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RWTUN, >> >> In other words if the existing CTLFLAG_TUN is set, the sysctl will >> automatically be pre-loaded with values from /boot/loader.conf. >> >> The reason we don't want the current approach is: >> >> 1) It duplicates the sysctl path in the TUNABLE statement. >> 2) It does not work very well for dynamically attached sysctls. There is >> a lot of code overhead computing the TUNABLE() path before the TUNABLE() >> can be fetched. >> >> Here is a work in progress: >> >> http://home.selasky.org:8192/sysctl_tunable.diff >> >> In most cases my patch is fine, but in some other cases I need some >> input, like in the VM subsystem when doing init, I'm not sure if the >> SYSINIT() for subsystem SI_SUB_KMEM, which sysctl's are using, has >> already been executed. > > I think this is a good idea, but it's also true you can just leave separate > TUNABLE_ statements without setting the CTLFLAG_TUN flag for cases you aren't > sure about for now. It probably makes sense to do these changes in stages. > > I was going to suggest using sbuf() for building the tunable name, but that > doesn't work since you have to build it in reverse. > Hi, After going through a lot of existing code, I've decided to make a new flag, CTLFLAG_FETCH rather than overload CTLFLAG_TUN, so that the new functionality can be added to drivers and tested. For example sysctls which implement function callbacks and are not trivial, this might cause locking of non-initialized mutexes and so on. And also I see some dependencies, that values are fetched at a certain point in the boot process and that existing CTLFLAG_TUN might confuse existing logic. I've updated my patch (same link): http://home.selasky.org:8192/sysctl_tunable.diff BTW: Can someone which have a beefy machine run a universe with this patch applied? I'll probably put it into the tree next week. --HPS