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

On Sun, Oct 7, 2012 at 8:02 AM, Luigi Rizzo <rizzo_at_iet.unipi.it> wrote:
> [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).

FWIW, I don't think that the problem is necessarily the fact that one
should do it either via ioctl, kvm, sysctl, etc: having a library/set
of interfaces as Adrian suggested would be indispensable for a number
of groups that copy code from FreeBSD net utilities wholesale --
effectively forking it the code, which in turn becomes a burden to the
project/company hacking on the code, and a loss to the community if
it's not given back. It would also make FreeBSD adoption a whole lot
easier for outside projects like net-snmp, as well as tools that
should be more tightly integrated into base OSes for networking
configuration and statistics, jail management, etc.

If something isn't done to make these interfaces more usable in a
generic manner and clean from the get-go, it doesn't matter what
interface I'll be getting the information via. The BSD socket
interfaces are extremely well thought out, but bits outside of struct
sockaddr* (e.g. stuff in net/...) could be better documented
(unfortunately the Unix Networking books are a bit long in the tooth,
in part because the original author passed on :(..).

My 2 cents for what little it may be worth,
-Garrett