From owner-freebsd-current@FreeBSD.ORG Fri Jun 27 09:20:27 2014 Return-Path: Delivered-To: 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 65A24D24 for ; Fri, 27 Jun 2014 09:20:27 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2C20B25AE for ; Fri, 27 Jun 2014 09:20:26 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id EF27C7300A; Fri, 27 Jun 2014 11:14:59 +0200 (CEST) Date: Fri, 27 Jun 2014 11:14:59 +0200 From: Luigi Rizzo To: current@freebsd.org Subject: do we have a generic string-number sysctl mapping library ? Message-ID: <20140627091459.GA50710@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) 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: Fri, 27 Jun 2014 09:20:27 -0000 Hi, I have frequently found myself using sysctls to control some kernel feature where a string would be a better (and sometimes the only) option than using a numeric value, yet the internal representation should be numeric for speed and robustness. Examples are the kern.timecounter, the default scheduler in dummynet, and now in netmap the selection between native and emulated mode. I am sure many of you can come up with other cases. I wonder if we have some support for that already in the sysctl code, or i should build a generic one next time i need to do that. Feel free to criticise the approach and suggest better ones. Right now i am using sysctls because i have a set of macros and wrapper functions that let me convert them to sysfs entries when building kernel code on linux, so I have a portable solutions. For the details, I'd like to have a mechanism that requires the kernel programmer supply a (possibly extensible) table of supported values, and matching constants to be used within the kernel. A single declaration should generate entries to get/set the current value as well as list options. We can discuss frills (such as wildcards, multiple values,etc). cheers luigi