[OpenIndiana-discuss] Missing "dladm show-dev"

[James Carlson]

On 11/15/13 12:34, Jim Klimov wrote:
> On 2013-11-15 17:54, Saso Kiselkov wrote:
>> On 11/15/13, 4:51 PM, Jim Klimov wrote:
>>> Hello all,
>>>
>>>    Back in Solaris 10 I used "dladm show-dev" to list the devices
>>> (and more importantly bound drivers) for NICs. In Openindiana this
>>> command seems not implemented, or possibly removed? What gives? :)
>>
>> Hi Jim,
>>
>> Don't know about "show-dev", but does "show-phys" not serve the purpose?
>> (at least guessing from what you described above)
> 
> Yes, it does... but old scripts on new OSes complain and need some
> hammering ;)

I hope you're using the "-p" (parseable output) mode when you use this
in a script.  The default human-readable output has changed many times
and may change again.

As for the "show-dev" bit, I don't recall how that came to be, but I can
make a guess.  The previous stability level was "Evolving" and the PSARC
case I cited changed it to "Obsolete."  Normally, you can't just remove
(or otherwise change incompatibly) something even though it's
"Obsolete;" the previous stability matters, as does the engineering work
to determine if anyone is relying on the thing to be changed.  This
implies that someone felt that OpenSolaris was the one thing Sun
promised never to do again: a new Major Release.

> I was just a bit annoyed at a new box which was expected to have Intel
> gigabit NICs but refused to plumb "e1000g". Ultimately dladm reminded
> me that "igb" is also in the business, and apparently this was some
> slightly different revision of the server than those before it... and
> even the cheat-sheet diagnostics failed with unknown-parameter stuff ;)

There are several different Intel-related drivers, depending on chipset.
 I remember at least 82586 iee, 82595 eepro, 825[59]6 ieef, 8255[789]
iprb, 82575 igb, 8259[89] ixgbe, and 8254x e1000g for wired, and 5[13]00
iwh, 2200 ipw, and 2100 iwk/iwp for wireless.  I would not be shocked if
there were a few more lurking out there somewhere.  The families are
(apparently!) different enough that having a separate driver for each
was the solution.

(Well, there were other internal reasons that happened, but it's all
ancient history now.)

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>