kern/110720: [net] [patch] support for interface descriptions
brooks at freebsd.org
Sun Mar 25 01:57:40 UTC 2007
On Sat, Mar 24, 2007 at 06:37:59PM +0100, Hartmut Brandt wrote:
> On Sat, 24 Mar 2007, Eugene Grosbein wrote:
> EG>On Sat, Mar 24, 2007 at 11:30:44AM +0100, Andre Oppermann wrote:
> EG>> Harti Brandt wrote:
> EG>> >Nice feature, although it would be nice to align the maximum length with
> EG>> >IF-MIB::ifDescr (255 byte + \0). Also I suppose that the field more
> EG>> >naturally fits into struct if_data (see net/if.h) given the comment for
> EG>> >that struct:
> EG>> >
> EG>> >/*
> EG>> > * Structure describing information about an interface
> EG>> > * which may be of interest to management entities.
> EG>> > */
> EG>> The string array should most likely not be part of struct ifnet as that
> EG>> would bloat it quite a bit. If it is in there it should be at the end
> EG>> of the struct to avoid cache line busting effects.
> EG>Also vote for this. And is it possible to make it a pointer instead
> EG>of array? The bloat would be minimal for system with tons of interfaces,
> EG>think about large pptp or pppoe server or similar that never would
> EG>utilize arrays.
> That makes sense. If it is a pointer it should not live in struct ifdata
> which can be retrieved via sysctl().
> As for access to this field perhaps it makes more sense to use the sysctl
> net.link.generic.ifdata subtree. We have already IFDATA_DRIVERNAME there
> which returns a string. Could be IFDATA_DESCRIPTION (4). This would
> probably be more in line with the management nature of the data. Just a
> thought... Would be slightly easier for the SNMP daemon to use...
If must not live in struct ifdata as the size of struct ifdata is part
of the routing socket API. :( There are two bytes avaible in struct
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-bugs/attachments/20070325/e2a2f887/attachment.pgp
More information about the freebsd-bugs