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> > 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>> > 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> > 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 ifdata. -- Brooks
pgpzSFdgYUejT.pgp
Description: PGP signature
