Your input for adding slot info to ioscan output

[marie-noelle jeanson_1]

Hi,

Note: see attached file for better output formatting for the commands below.

HP is planning on adding some slot information to the ioscan command output.
We see two potential benefits by doing this:

1) Extend the functionality that is provided today by â olrad â qâ on OLAR capable systems only, to all systems, as this may be useful when diagnosing slot problems. Example of â olrad â qâ output (note: slot is in fact cabinet# bay# chassis# slot):
# olrad -q
Driver(s)
Capable
Slot Path Bus Max Spd Pwr Occu Susp OLAR OLD Max Mode
Num Spd Mode
0-0-3-1 4/0/1/0 21 66 N/A On Yes No Yes N/A PCI N/A
0-0-3-2 4/0/2/0 42 66 N/A On Yes No Yes N/A PCI N/A
0-0-3-3 4/0/3/0 63 66 N/A On Yes No Yes N/A PCI N/A

One way to provide this information is to add new lines to the ioscan output such as (note the new lines starting with slot):

class I H/W Path Driver S/W State H/W Type Description
=============================================================================
root 0 root CLAIMED BUS_NEXUS
ioa 0 0 sba CLAIMED BUS_NEXUS System Bus Adapter (803)
ba 0 0/0 lba CLAIMED BUS_NEXUS Local PCI Bus Adapter(782)
slot 0 0/0/0 pci CLAIMED SLOT 1
lan 0 0/0/0/0 btlan CLAIMED INTERFACE HP PCI 10/100Base-TXCore
slot 1 0/0/1 pci CLAIMED SLOT 2
ext_bus 0 0/0/1/0 c720 CLAIMED INTERFACE SCSI C895 Ultra Wide LVD
target 0 0/0/1/0.7 tgt CLAIMED DEVICE
ctl 0 0/0/1/0.7.0 sctl CLAIMED DEVICE Initiator


2) Make multi port cards more visible by showing more distinctly the slots contents, such as (there would be multiple rows for multi port cards):
class I H/W Path Driver S/W State H/W Type Description
=============================================================================

slot 0
lan 0 0/0/0/0 btlan CLAIMED INTERFACE HP PCI 10/100Base-TXCore

slot 1
ext_bus 0 0/0/1/0 c720 CLAIMED INTERFACE SCSI C895 Ultra Wide LVD


Questions:
- do you see a value of implementing 1) above? why? would is most important to display?
- do you see a value of implementing 2) above? why? what would you expect the output to show?
- would we break existing scripts by adding new lines to ioscan output using existing options? in other words, is it absolutely necessary to create new ioscan options to show this new information? why?

Thank you very mu

[Kent Ostby]

Given my choice of the 2, I would take format 1.

Will it break scripts ?

I'm sure it will break SOMEONE's scripts although I don't have anything that parses isocan output personally.

[TwoProc]

I like method two - but as such I'm afraid that I'm one of the ones that has scripts that would fail on this. That being said, it would still be worth my time to convert as I like the extra data. Just a question though - can we have an "-old" switch (or similar) to get the old output back for script compatibility ?

[marie-noelle jeanson_1]

Hi,

One precision: in the first output, slot itself would actually be considered as an additional ioscan entry (it is not just additional lines that are attached to an existing entry but a new entry by itself). Not sure if the output parsing would be less impacted knowing this though.

It would be nice to see some script examples to see what they do with the ioscan output (I have not been able to gather any so far but I keep being told that users do have scripts parsing ioscan output).

However it looks like we will have to provide this new functionality using new options in order not to break backward compatibility.

Thank you for your input so far. More feedback is still welcome **and so are script examples** !!!

Marie-Noelle

[Bill Hassell]

I often parse ioscan to make it more readable for error messages on specific devices such as tapes or CDROM drives. I would strongly recommend that slot info be an additional option, not he default. -f gives details, make -F give more details per line (slot numbers). Then make a separate option that categorizes the slots with separate lines. Putting all the data on a single line makes all the data pieces easy to parse, and creating a separation line for slots is OK for readability, just don't make it the default. Note that extra long lines (more than 80 chars) has been normal with the -f option. Whether the maximum line length is 85 or 150 is not important for parsing (ie, vmstat).

[Florian Heigl (new acc)]

I don't think that splitting multi-function cards into several slots, they only occupy one and I don't like the idea of what will happen if there was a system with two A60031 next to each other and the 'slot 2' card is to be replaced.


On the other question, I looked over my scripts, they won't get into any problems by the added field. But the -F option suggested sounds fine, too.

In general, I think it is a good idea:
Today I feel fine searching my way through ioscan -fnH and the regarding stickers on the system, but when I started on hp-ux a 'slot 1' would have made life a bit easier.

:)