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

[subject changed due to the shift of topic]

On Sun, Oct 07, 2012 at 07:08:54AM -0700, Adrian Chadd wrote:
> On 7 October 2012 03:43, Luigi Rizzo <rizzo_at_iet.unipi.it> wrote:
> >
> > Good point, thanks for mentioning this:
> 
> ew. ifconfig :-)
> 
> > <rant>
> > Could be done, but I consider the ifconfig one of the ugliest
> > configuration mechanisms we have in FreeBSD so I'd rather not
> > contribute to that.
> 
> Seconded; but compare to Linux which has mutiple different commands to
> do networking, as well as 'net'. :-)

we do too -- we have arp, route, ifconfig, sysctl and possibly
more that i am not aware of. Some ipfw features are controlled
by sysctl, and there is code in ipfw that maps "ipfw do something"
into "sysctl net.inet.ipfw.do.something-under-another-name"

I am not sure that a single frontend is the way to go.

And I understand that there are opportunity reasons (importing
external code, compatibility with others, etc.) which suggested to
look at ifconfig as a general purpose frontend for interface
manipulation.

Coming to 802.11 (and I am using it just as an example):
configuration of the various parameters is not too different from,
say, manipulating the various features that are available in modern
NICs: interrupt mitigation, queue parameters, multiqueue support,
RSS, and so on.  In this area linux has ethtool, while we have
mostly device-specific sysctls.

I'd love to have a device-independent mechanism to implement this.
I do not think we need to go through the definition of a new
ioctl/sockopt every time we find that a new parameter is
required/useful.

> > ifieee80211 is even worse -- over 5000 lines of code,
> > 153 between commands and arguments, and 31 different parameters:
> 
> I'd personally like to break these kinds of things out into libraries
> so other C code can use them.

my point was that this type of configuration is rarely if
ever done outside setup or management scripts, at an incredibly
low rate and as such does not need a C API (which in case the
sysctl gives you).

> I'm eventually going to do it to the net80211 code in ifconfig; maybe
> it's also worth doing to if_bridge for example.
> 
> Doing configuration via sysctl can be hokey, especially when you use
> sysctl and sysfs to do things which change the sysctl/sysfs layout (by
> creating/destroying nodes as you change the configuration.) It's ..

can you elaborate ? If i destroy an interface (or disable a function)
and kill a subtree, and this causes a subsequent configuration of the
non-existing parameter to fail, what is wrong with that ?

> ew.
> 
> Maybe for your bridge stuff its easy enough, but for something like
> net80211 where there's a lot of things to configure, doing it via
> sysctl would involve lots of parsing in the kernel.. and I like my
> kernels smaller. :-)

Here too i kind of fail to see how much additional parsing you would
need in the kernel when using sysctl as opposed to ioctl(), so
an example would help.
Integers and strcmp do not require any parsing,
and some small functions to parse MAC/IP addresses or chanlist
arguments are not going to cause incredible bloat (and besides
i think they already exist in multiple versions in the various
userspace utilities).

cheers
luigi