On 10/7/12 8:02 AM, Luigi Rizzo wrote:
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.

this reminds me of the reason that we implemented a text based config mechanism for netgraph. A design goal was "you should never need a new executable in /sbin to configure a new netgraph node". no matter what the node is, you should be able to configure it from /sbin/ngctl.

In a very loose description, you could say that the base netgraph module includes a parser that takes a grammar description that comes with each module. It knows how to convert arbitrary text config messages for a given module and convert them into the strict binary messages that are passed around and use in the netgraph nodes themselves. Could probably do with some polishing after 14 years, but as far as I know not a line of that code has been changed,
and we now have over 50 netgraph node types.

[...]

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
_______________________________________________
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"



_______________________________________________
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"

Reply via email to