lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 29 Jun 2007 11:21:54 -0700 From: David Stevens <dlstevens@...ibm.com> To: Andi Kleen <andi@...stfloor.org> Cc: ak@...e.de, Chris Snook <csnook@...hat.com>, Linux Network Development list <netdev@...r.kernel.org>, Rick Jones <rick.jones2@...com> Subject: Re: a maze of twisty stats, most different ak@...e.de wrote on 06/29/2007 10:30:23 AM: > David Stevens <dlstevens@...ibm.com> writes: > > > I think there's a more general problem that's a huge hassle. There are > > lots of > > new SNMP MIB's, but no conventions (that I'm aware of, at least) to allow > > for > > changes to the /proc entries that get them to applications. > > Actually /proc/net/snmp and netstat -s are extensible. If you add a new > MIB or field there it should just show up in netstat -s. It won't know about > the text decoding that is done for the early traditional MIBs, but that > is already not there for most of the newer fields. That works ok for some things, like new global counters, but some items really fit best in existing files and the concern there is about other uses of them beyond the standard tools. Examples: -addition of route age in /proc/net/route and /proc/net/ipv6_route -per-group data in /proc/net/igmp & igmp6 -per-interface MLD MIB info, which ought to go with other per-interface data I think everything that uses this kind of interface ought to do label matching, so additional columns in a row (anywhere in the row) would just be skipped/ignored by things that don't understand them, and similarlarly for single-row tagged items. You can do that in scripts with awk, but if existing items don't, they'll break. On the other hand, we don't want to create a new instance for every addition or modification, so it seems the middle ground is to go with new entries now and state that scripts and code that don't match tags and handle changes in the format in the future are broken. We could dump everything in /proc/net/snmp{,6}, of course, but I'm not sure it's a good idea to replicate all the routing and interface data that is not there now just to get a few additional fields for those items. +-DLS - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists