On Sun, Oct 07, 2012 at 01:05:21PM -0400, Justin Hibbits wrote: > On Sun, 07 Oct 2012 10:16:40 -0600 > Ian Lepore <free...@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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"