Hello Donald, Here here !, I concure . BUT the complete MIB
and nothing less. This also means that if the MIB std gets
modified so does /proc/dev/??? . Ttys
On Sun, 8 Nov 1998, Donald Becker wrote:
> On Sun, 8 Nov 1998, Alan Cox wrote:
> > Subject: Re: Suggestion for /proc/net/dev: Additional field "Bandwidth"
> > > This may not be for the kernel's own sake, but for applications that could
> > > make use of such a piece of information.
> >
> > And could load it from a user configured file. Contrary to rumour many
> > network devices don't know their speeds. You also need to keep rx/tx speed
> > seperately and know if its half duplex.
>
> Thanks for stating this Alan.
> To be more precise: there is no standard way to read the current data rate
> from a MII transceiver. And even on transceivers that provide this info,
> it's expensive to read the MII management registers -- up to 100us. each.
> It's even possible that a non-Ethernet MII transceiver might be built that
> has an unusual or variable data rate.
>
> In addition I would like to implore people to *not* extend /proc/net/dev.
> When I wrote that code I wanted it to fit in 80 columns, so I summarized a
> few error fields. In retrospect that was something of a mistake. The
> summarized fields makes it more difficult to isolate problems. It's not as
> bad as the simplistic "good stuff / bad stuff" count that BSDs keep, but
> when people have problems they usually need to know the exact error type.
>
> Over the years I avoided changing /proc/net/dev because it would both break
> programs that depended on the format and make the column-oriented output
> unreadable for most people. Unfortunatlely the 2.1.* change of adding byte
> counts had both of these undesireable effects, and it broke them *without*
> emitting the additional fields! We should not repeat this error by
> adding even more info fields to /proc/net/dev. IMHO, we should revert
> /proc/net/dev to its old format, and have a new /proc/net/??? output that
> emits more complete (SNMP-II/MIB) device-level info, including the station
> address and perhaps a best-guess at the current media type/speed.
>
> Donald Becker [EMAIL PROTECTED]
> USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to [EMAIL PROTECTED]
>
, JimL
+-----------------------------------------------------------------------+
| James W. Laferriere - Network Engineer - [EMAIL PROTECTED] |
| System Techniques - 25416 - 22nd S. - Des-Moines, WA 98198 |
| Give me VMS -or- Give me Linux -but- only on AXP |
+-----------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
