From owner-freebsd-arch@FreeBSD.ORG Fri Jan 4 02:27:28 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED4FD16A417 for ; Fri, 4 Jan 2008 02:27:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outL.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id D132C13C44B for ; Fri, 4 Jan 2008 02:27:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 03 Jan 2008 18:27:28 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 93301126E0E; Thu, 3 Jan 2008 18:27:27 -0800 (PST) Message-ID: <477D999E.5080704@elischer.org> Date: Thu, 03 Jan 2008 18:27:42 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alfred Perlstein References: <477D931D.4000303@elischer.org> <20080104021905.GE76698@elvis.mu.org> In-Reply-To: <20080104021905.GE76698@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: RFC: sysctl additional functions/macros 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: Fri, 04 Jan 2008 02:27:29 -0000 Alfred Perlstein wrote: > Yes, but EINVAL please. I wondered who would be the first to complain about that.. "Gee you Juniper people have no sense of humour" :-) :-) > > Another idea would be a simplified SYSCTL_INT_PROC > that allowed one to define a function like so: > > int > sysctl_handle_int_proc(void *handle, int *newval, int *max, int *min) > { > > > } > > If this function returned '0' then 'newval' would be accepted. > Otherwise the function should return an error, most likely EINVAL. > > The point being that a lot of these maximums may take a calculation > and we should make it as easy as possible to do this calculation > and provide the function for doing so. > > One would also set the min/max values so that one could query > the acceptable bounds of a tunable, or even the bounds of of > the tuneable. > > (Note: if *newval == NULL, we're just querying max/min, not > doing a set operation.) > > (Note 2: "handle" is so you can have a common handler and > possibly switch() off of handle for multiple sysctl ints to > reduce the number of functions required.) > > -Alfred > > * Julian Elischer [080103 17:57] wrote: >> I would like to extend the current SYSCTL_INT() with >> SYSCTL_INT_CLAMPED() or similar, where you also supply a >> maximum acceptable value. (and maybe a clue as to what to say if it is >> a bad value). >> >> so many users of SYSCTL_INT don't check for bad values because it's so >> much harder (you need to supply your own handler), and so many >> simple handlers exist fo rthe people that DO check that it seems to >> me that we should provide a pre-canned way to do this.... >> >> we are limited to using the existing structure, >> but as we have no existing callers we can redefine >> one element.... >> >> I would suggest: >> >> I'd like to test for a minimum too but I think I can only squeeze one >> field out of the existing struct sysctl_oid. >> >> SYSCTL_INT_CLAMPED(parent, nbr, name, access, ptr, max, descr) >> ^^^^ >> >> anyone think it's a bad idea? >> After all the macros are evaluated, (etc.) it would call: >> ( off the top of my head ) >> >> int >> sysctl_handle_int_max(SYSCTL_HANDLER_ARGS) >> { >> int error = 0; >> >> error = SYSCTL_OUT(req, arg1, sizeof(int)); >> >> if (error || !req->newptr) >> return (error); >> >> if (*(int *)arg1 > (int)arg2) >> error = EDOOFUS; >> else >> error = SYSCTL_IN(req, arg1, sizeof(int)); >> return (error); >> } >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >