svn commit: r269106 - head/tools/tools/cxgbetool

[Navdeep Parhar]

On Sat, Jul 26, 2014 at 09:26:07PM +0300, Konstantin Belousov wrote:
> On Sat, Jul 26, 2014 at 12:51:45AM +0000, Navdeep Parhar wrote:
> > Author: np
> > Date: Sat Jul 26 00:51:45 2014
> > New Revision: 269106
> > URL: http://svnweb.freebsd.org/changeset/base/269106
> > 
> > Log:
> >   Add a 'raw' parameter to the 'modinfo' subcommand.  This is handy when
> >   trying to figure out why a QSFP+/SFP+ connector or cable wasn't
> >   identified correctly by cxgbe(4).  Its output looks like this:
> >   
> >   # cxgbetool t5nex0 modinfo 0 raw
> >   00:  03 04 21 00  00 00 00 00  ..!. ....
> >   08:  04 00 00 00  67 00 00 00  .... g...
> >   10:  00 00 05 00  41 6d 70 68  .... Amph
> >   18:  65 6e 6f 6c  20 20 20 20  enol
> >   20:  20 20 20 20  00 41 50 48       .APH
> >   28:  35 37 31 35  34 30 30 30  5715 4000
> >   30:  33 20 20 20  20 20 20 20  3
> >   38:  4b 20 20 20  01 00 00 fa  K    ....
> >   40:  00 00 00 00  41 50 46 31  .... APF1
> >   48:  30 30 34 30  30 33 30 30  0040 0300
> >   50:  30 33 20 20  31 30 30 31  03   1001
> >   58:  33 30 20 20  00 00 00 97  30   ....
> >   
> >   MFC after:	3 days
> > 
> > Modified:
> >   head/tools/tools/cxgbetool/cxgbetool.c
> 
> I do not remember if this question was already asked.
> 
> Why cxgbetool lives in tools and not installed into /usr/sbin as
> cxgbecontrol(8) ?

cxgbetool was originally meant to be just a debug tool, not something
that would be of interest to most users (not even those using cxgbe).
But once written, it offered an easy way to interface with the driver
and chip, and so it gradually grew a number of commands for features for
which there is no system CLI (packet filtering/steering, QoS-ish stuff,
packet sniffing, pluggable optics/copper modules, etc.).

In its current state I think it fits in tools/tools or usr/sbin equally
well.  Moving it to usr/sbin will force the issue of a manpage -- I have
one that has been 80% complete for 2 years now :-(

Regards,
Navdeep