netdev - Re: a maze of twisty stats, most different

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <OFAD87D0AB.C0688B5F-ON88257309.006374DE-88257309.0064D4D0@us.ibm.com>
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