sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?)

[Luigi Rizzo]

On Sun, Oct 07, 2012 at 01:05:21PM -0400, Justin Hibbits wrote:
> On Sun, 07 Oct 2012 10:16:40 -0600
> Ian Lepore <freebsd at damnhippie.dyndns.org> 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