[netdrivers] Re: [vortex] Quick poll

[Donald Becker]

On Thu, 3 Apr 2003, Bogdan Costescu wrote:

> On Wed, 2 Apr 2003, Donald Becker wrote:
> 
> > [[ Quick poll: I've been considering changing the configuration EEPROM
> > report.  The current semantics are
> >    -e  Show the interpreted settings
> >    -ee  Also show the whole EEPROM contents numerically
> >    -eee  For EEPROM values that look like ASCII, print the characters at the
> >          end of each numeric output line.
> 
> I don't know how useful the last entry is, but if kept I would suggest 
> merging the last two. IMHO the added value of this is too small to have 
> its own verbosity level...

The ASCII text option was added primarily for CardBus cards, to make it
easy to read the card identification strings.  Some other types of
NICs have an ASCII string even on their non-CardBus cards.

I added it as "-eee" to keep backwards compatibility.  But I suspect
that I'm the only person that has a program that parses the output, and
it's trivial to change.  (That program is used to convert the diag
output to a C array, so that I can restore the original EEPROM contents
when there is a development screw-up.)

> As to having everything available from one "e"... I don't know but I think 
> that the current output from the debug tools is a bit scary for a first 
> time user with all the numerical output and the fact that the output is 
> long. So my suggestion would be to:
> - put some important interpreted output but from each category (card 
> status, MII, EEPROM) in the default invocation (without any options) and 
> make it such that everything fits on one screen (80x24 lines max). This 
> allows a quick check from the user if he/she understands what the output 
> means :-) But also print a message that, in case of problems, the diag 
> reports sent to the list should be obtained with some more verbosity - to 
> save bandwidth from questions like "this is the diag output, what else can 
> I provide"

You are right: I should have a boilerplate message describing how to
report the status.

> - allow more verbosity for reports; this could probably be also only 
> interpreted output, but as complete as possible. This is to save 
> debugger's time from checking in the docs what different values mean :-)

While it's sometimes painful to interpret that the numeric status
values, I find it mistake-prone to convert the text output back to the
register settings.  And there are a whole bunch of registers values,
most of which can be ignored for a specific problem.

> Another suggestion which is a bit separate and probably harder to 
> implement but would also probably help is to allow the diag program to 
> read raw data spit by a previous run (last level or verbosity) and try to 
> interpret it - I guess this would be doable once the intermediate 
> completely interpreted output is done... This would save some of my time 
> at least :-)
> 
> In any case, let the user know that the basic output is not enough for 
> debugging and more verbose output is needed.
> 
> Huh, after going back through the message, I think that some of the 
> suggestions are a bit radical, so take them only as a wish-list :-)
> 
> 

-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Scyld Beowulf cluster system
Annapolis MD 21403			410-990-9993