From owner-freebsd-current@FreeBSD.ORG Sun Oct 7 17:50:52 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AE5E1065672; Sun, 7 Oct 2012 17:50:52 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E67008FC23; Sun, 7 Oct 2012 17:50:51 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 498537300B; Sun, 7 Oct 2012 20:11:00 +0200 (CEST) Date: Sun, 7 Oct 2012 20:11:00 +0200 From: Luigi Rizzo To: Justin Hibbits Message-ID: <20121007181100.GA79447@onelab2.iet.unipi.it> References: <20121006172834.GB63649@onelab2.iet.unipi.it> <20121007104330.GA75115@onelab2.iet.unipi.it> <20121007150219.GA76853@onelab2.iet.unipi.it> <20121007155356.GA77558@onelab2.iet.unipi.it> <1349626600.1112.30.camel@revolution.hippie.lan> <20121007130521.76dc7e5e@narn.knownspace> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121007130521.76dc7e5e@narn.knownspace> User-Agent: Mutt/1.4.2.3i Cc: Garrett Cooper , Ian Lepore , Adrian Chadd , current@freebsd.org Subject: Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 07 Oct 2012 17:50:52 -0000 On Sun, Oct 07, 2012 at 01:05:21PM -0400, Justin Hibbits wrote: > On Sun, 07 Oct 2012 10:16:40 -0600 > Ian Lepore wrote: > > > On Sun, 2012-10-07 at 17:53 +0200, Luigi Rizzo wrote: > > > Access through sysctl is incredibly easy from both userspace and > > > from a C application, because all the work is done in the kernel > > > side, whereas other mechanisms (ioctl, i'd rather leave kvm apart > > > as we really don't want that!) require the definition of a specific > > > API (ioctl, structs) _and_ some amount of wrapping code in > > > userspace. > > > > > > cheers > > > luigi > > > > A potential problem with sysctl is its "one thing at a time" nature. > > When you pack up a bunch of related data into a structure and hand it > > off to an implementation, that implementation can pretty easily make > > sure that all the data related to the config request is sane. If you > > have to make a series of sysctl calls to achieve some complex config > > task, what happens when you're 2/3 of the way through the series and a > > call fails? Who backs out the partial config that got accomplished? > > > > If you go too far down this path you end up with something that looks > > a lot like the unmitigated mess which is the SNMP control API. > > > > -- Ian > > I agree with Ian here. As messy as ioctl+structs are from a user > standpoint, they're the easiest way to guarantee atomic configuration > changes. Not a single function in ifbridge.c uses it (I have checked), and very likely the same happens for 802.11. sys/net80211/ieee80211_ioctl.h contains over 100 #define's for various subfunctions for the ioctl(s, SIOCS80211, &ireq) which are issued one at a time with no atomicity requirement. cheers luigi