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_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > >Received on Sun Oct 07 2012 - 17:32:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:31 UTC