Linux hardware inventory: Current reality, future possibilities - - PowerPoint PPT Presentation

▶
linux hardware inventory current reality future
SMART_READER_LITE
LIVE PREVIEW

Linux hardware inventory: Current reality, future possibilities - - PowerPoint PPT Presentation

Oct 13, 2022 322 likes •1.41k views

AUUG 2003 Conference 1/33 Open Standards, Open Source, Open Computing 3 September 2003 Linux hardware inventory: Current reality, future possibilities Martin Schwenke IBM OzLabs Linux Technology Center < martins@au.ibm.com

slide-1
SLIDE 1

1/33

  • AUUG 2003 Conference

Open Standards, Open Source, Open Computing

3 September 2003

Linux hardware inventory: Current reality, future possibilities

Martin Schwenke

IBM OzLabs Linux Technology Center <martins@au.ibm.com> · <martin@meltin.net>

slide-2
SLIDE 2

2/33

  • The plan. . .
  • Introduction.

– Hardware inventory on Linux r

and AIX r .

  • Are we there yet?

– Progress on the Linux lsvpd project so far.

  • Where to now?
  • Conclusions, questions, . . .
slide-3
SLIDE 3

3/33

  • Current Linux reality
  • Linux has hardware inventory systems such as Red Hat’s kudzu and

SuSE’s hwinfo.

slide-4
SLIDE 4

3/33

  • Current Linux reality
  • Linux has hardware inventory systems such as Red Hat’s kudzu and

SuSE’s hwinfo.

  • Used mainly for device detection and automated driver selection.
slide-5
SLIDE 5

3/33

  • Current Linux reality
  • Linux has hardware inventory systems such as Red Hat’s kudzu and

SuSE’s hwinfo.

  • Used mainly for device detection and automated driver selection.
  • Information persists between boots.
slide-6
SLIDE 6

4/33

  • AIX reality
  • Large, mature hardware inventory system.
slide-7
SLIDE 7

4/33

  • AIX reality
  • Large, mature hardware inventory system.
  • Among other things, the Object Data Manager (ODM) contains

Vital Product Data (VPD):

slide-8
SLIDE 8

4/33

  • AIX reality
  • Large, mature hardware inventory system.
  • Among other things, the Object Data Manager (ODM) contains

Vital Product Data (VPD): – Generic, static information about components. – Dynamic information about components, including configuration.

slide-9
SLIDE 9

4/33

  • AIX reality
  • Large, mature hardware inventory system.
  • Among other things, the Object Data Manager (ODM) contains

Vital Product Data (VPD): – Generic, static information about components. – Dynamic information about components, including configuration.

  • Persistent device naming based on device/slot information (from

VPD).

slide-10
SLIDE 10

4/33

  • AIX reality
  • Large, mature hardware inventory system.
  • Among other things, the Object Data Manager (ODM) contains

Vital Product Data (VPD): – Generic, static information about components. – Dynamic information about components, including configuration.

  • Persistent device naming based on device/slot information (from

VPD).

  • lsvpd lists VPD in human/machine readable format.
  • lscfg lists VPD (and other info) in human readable format.
slide-11
SLIDE 11

5/33

  • Example of VPD (lsvpd-style)

*DS 2 RIO-PCI COPPER *SN YL1182260007 *PN 53P3820 *CC 2887 *FN 53P3800 *VK RS6K *YL U0.4-P1.1

slide-12
SLIDE 12

6/33

  • Example of VPD (explained)

*DS 2 RIO-PCI COPPER # Description *SN YL1182260007 # Serial Number *PN 53P3820 # Part Number *CC 2887 *FN 53P3800 # FRU (Field Replaceable Unit) Number *VK RS6K *YL U0.4-P1.1 # Physical Location: # Extender 1, on backplane 1, in drawer 4, in rack 0.

slide-13
SLIDE 13

7/33

  • Are we there yet?
  • General requirement:
slide-14
SLIDE 14

7/33

  • Are we there yet?
  • General requirement:

Implement lsvpd on Linux.

slide-15
SLIDE 15

7/33

  • Are we there yet?
  • General requirement:

Implement lsvpd on Linux.

  • Various iterations of:

– more specific requirements – ‘schedule’ – choice of implementation language(s) – implementation – future plans – . . .

slide-16
SLIDE 16

8/33

  • Requirements #1 (May 2001)
  • Find ibm,vpd properties in the Open Firmware device-tree and

pretty print them.

  • Time required: a few hours.
slide-17
SLIDE 17

9/33

  • Example of PCI VPD

82 10 00 32 20 52 49 4f 2d 50 43 49 20 43 4f 50 |...2 RIO-PCI COP| 50 45 52 90 3e 00 53 4e 0c 59 4c 31 31 38 32 32 |PER.>.SN.YL11822| 36 30 30 30 37 50 4e 07 35 33 50 33 38 32 30 43 |60007PN.53P3820C| 43 04 32 38 38 37 46 4e 08 20 35 33 50 33 38 30 |C.2887FN. 53P380| 30 56 4b 04 52 53 36 4b 59 4c 09 55 30 2e 34 2d |0VK.RS6KYL.U0.4-| 50 31 2e 31 79 ec |P1.1y.|

slide-18
SLIDE 18

10/33

  • This should take a few hours
  • Simple reverse-engineering, parsing and pretty-printing task.
slide-19
SLIDE 19

10/33

  • This should take a few hours
  • Simple reverse-engineering, parsing and pretty-printing task.
  • Single Perl script ‘lsvpd’.
slide-20
SLIDE 20

10/33

  • This should take a few hours
  • Simple reverse-engineering, parsing and pretty-printing task.
  • Single Perl script ‘lsvpd’.
  • ibm,vpd files in a format that is well defined in the PCI

specification.

slide-21
SLIDE 21

10/33

  • This should take a few hours
  • Simple reverse-engineering, parsing and pretty-printing task.
  • Single Perl script ‘lsvpd’.
  • ibm,vpd files in a format that is well defined in the PCI

specification.

  • Not so much reverse-engineering.
slide-22
SLIDE 22

11/33

  • Requirements #2 (June 2001?)
  • ‘Things like SCSI devices are missing!’
slide-23
SLIDE 23

11/33

  • Requirements #2 (June 2001?)
  • ‘Things like SCSI devices are missing!’
  • Find ibm,vpd properties in the Open Firmware device-tree and

pretty print them. Also print information about SCSI devices.

slide-24
SLIDE 24

11/33

  • Requirements #2 (June 2001?)
  • ‘Things like SCSI devices are missing!’
  • Find ibm,vpd properties in the Open Firmware device-tree and

pretty print them. Also print information about SCSI devices.

  • Time required: a few days.
slide-25
SLIDE 25

12/33

  • SCSI standard inquiry output

00 00 03 02 9f 00 01 3a 49 42 4d 20 20 20 20 20 |.......:IBM | 49 43 33 35 4c 30 33 36 55 43 44 32 31 30 2d 30 |IC35L036UCD210-0| 53 35 42 53 56 4d 46 39 39 33 31 38 30 37 4e 34 |S5BSVMF9931807N4| 39 30 38 20 20 20 20 20 0c 00 00 00 00 00 00 00 |908 ........| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 20 20 30 30 37 35 30 32 31 37 32 00 30 30 30 31 | 007502172.0001| 32 32 30 39 50 33 39 32 33 20 20 20 20 20 48 33 |2209P3923 H3| 32 30 35 31 20 20 20 20 30 37 4e 37 30 37 30 20 |2051 07N7070 | 20 20 20 20 46 38 30 34 37 30 20 20 20 20 32 30 | F80470 20| 30 32 00 00 |02..|

slide-26
SLIDE 26

13/33

  • Snazzy SCSI solutions
  • update-device-tree:
slide-27
SLIDE 27

13/33

  • Snazzy SCSI solutions
  • update-device-tree:
  • 1. Copy /proc/device-tree to /var/lib/device-tree.
slide-28
SLIDE 28

13/33

  • Snazzy SCSI solutions
  • update-device-tree:
  • 1. Copy /proc/device-tree to /var/lib/device-tree.
  • 2. Use sg inq to do SCSI inquiries.
slide-29
SLIDE 29

13/33

  • Snazzy SCSI solutions
  • update-device-tree:
  • 1. Copy /proc/device-tree to /var/lib/device-tree.
  • 2. Use sg inq to do SCSI inquiries.
  • 3. Extract ‘VPD fields’ from output according to templates.
slide-30
SLIDE 30

13/33

  • Snazzy SCSI solutions
  • update-device-tree:
  • 1. Copy /proc/device-tree to /var/lib/device-tree.
  • 2. Use sg inq to do SCSI inquiries.
  • 3. Extract ‘VPD fields’ from output according to templates.
  • 4. Find device-tree node and drop in linux,vpd file.
slide-31
SLIDE 31

13/33

  • Snazzy SCSI solutions
  • update-device-tree:
  • 1. Copy /proc/device-tree to /var/lib/device-tree.
  • 2. Use sg inq to do SCSI inquiries.
  • 3. Extract ‘VPD fields’ from output according to templates.
  • 4. Find device-tree node and drop in linux,vpd file.
  • lsvpd:
slide-32
SLIDE 32

13/33

  • Snazzy SCSI solutions
  • update-device-tree:
  • 1. Copy /proc/device-tree to /var/lib/device-tree.
  • 2. Use sg inq to do SCSI inquiries.
  • 3. Extract ‘VPD fields’ from output according to templates.
  • 4. Find device-tree node and drop in linux,vpd file.
  • lsvpd:
  • 1. Find all files called ibm,vpd and render them.
slide-33
SLIDE 33

13/33

  • Snazzy SCSI solutions
  • update-device-tree:
  • 1. Copy /proc/device-tree to /var/lib/device-tree.
  • 2. Use sg inq to do SCSI inquiries.
  • 3. Extract ‘VPD fields’ from output according to templates.
  • 4. Find device-tree node and drop in linux,vpd file.
  • lsvpd:
  • 1. Find all files called ibm,vpd and render them.
  • 2. Find all files called linux,vpd and cat them.
slide-34
SLIDE 34

13/33

  • Snazzy SCSI solutions
  • update-device-tree:
  • 1. Copy /proc/device-tree to /var/lib/device-tree.
  • 2. Use sg inq to do SCSI inquiries.
  • 3. Extract ‘VPD fields’ from output according to templates.
  • 4. Find device-tree node and drop in linux,vpd file.
  • lsvpd:
  • 1. Find all files called ibm,vpd and render them.
  • 2. Find all files called linux,vpd and cat them.
  • This introduced a ‘database’.
slide-35
SLIDE 35

14/33

  • SCSI standard inquiry output

*DS 16 Bit LVD SCSI Disk Drive *AX /dev/sda *MF IBM *TM IC35L036UCD210-0 *YL U0.4-P1-I1/Z2-A8 *FN 09P3923 *RL 53354253 *SN VMF99318 *EC H32051 *PN 07N7070 *Z0 000003029F00013A *Z1 07N4908 *Z2 0075 *Z3 02172 *Z4 0001 *Z5 22 *Z6 F80470 *Z7 500507620CC4AC8E

slide-36
SLIDE 36

15/33

  • Perls of wisdom
  • Perl’s unpack function is very useful for parsing binary data,

including PCI VPD chunks.

slide-37
SLIDE 37

15/33

  • Perls of wisdom
  • Perl’s unpack function is very useful for parsing binary data,

including PCI VPD chunks.

  • SCSI inquiries reimplemented using Perl’s ioctl function.
slide-38
SLIDE 38

15/33

  • Perls of wisdom
  • Perl’s unpack function is very useful for parsing binary data,

including PCI VPD chunks.

  • SCSI inquiries reimplemented using Perl’s ioctl function.
  • Finding physical location was problematic:

– Easy to determine the SCSI host adapter associated with a device.

slide-39
SLIDE 39

15/33

  • Perls of wisdom
  • Perl’s unpack function is very useful for parsing binary data,

including PCI VPD chunks.

  • SCSI inquiries reimplemented using Perl’s ioctl function.
  • Finding physical location was problematic:

– Easy to determine the SCSI host adapter associated with a device. – Need to parse, for example, /proc/scsi/sym53c8xx/0.

slide-40
SLIDE 40

15/33

  • Perls of wisdom
  • Perl’s unpack function is very useful for parsing binary data,

including PCI VPD chunks.

  • SCSI inquiries reimplemented using Perl’s ioctl function.
  • Finding physical location was problematic:

– Easy to determine the SCSI host adapter associated with a device. – Need to parse, for example, /proc/scsi/sym53c8xx/0. – File format is driver-specific.

slide-41
SLIDE 41

15/33

  • Perls of wisdom
  • Perl’s unpack function is very useful for parsing binary data,

including PCI VPD chunks.

  • SCSI inquiries reimplemented using Perl’s ioctl function.
  • Finding physical location was problematic:

– Easy to determine the SCSI host adapter associated with a device. – Need to parse, for example, /proc/scsi/sym53c8xx/0. – File format is driver-specific. – More templates. . .

slide-42
SLIDE 42

16/33

  • Missing bits
  • lspci:

[...] 241:1.0 SCSI storage controller: LSI Logic / Symbios 53c1010 [...] [...]

  • /proc/scsi/sym53c8xx/0:

Chip sym53c1010-66, device id 0x21, revision id 0x1 On PCI bus 65, device 1, function 0, IRQ 69 [...]

  • device-tree:

# od -t d /var/lib/lsvpd/device-tree/pci*/bus-range 0000000 254 254 * 0000460

slide-43
SLIDE 43

16/33

  • Missing bits
  • lspci:

[...] 241:1.0 SCSI storage controller: LSI Logic / Symbios 53c1010 [...] [...]

  • /proc/scsi/sym53c8xx/0:

Chip sym53c1010-66, device id 0x21, revision id 0x1 On PCI bus 65, device 1, function 0, IRQ 69 [...]

  • device-tree:

# od -t d /var/lib/lsvpd/device-tree/pci*/bus-range 0000000 254 254 * 0000460

  • Patched sym53c8xx 2 driver to print full bus number.
  • Patched pSeriesTMsetup code to drop linux,phbnum property in

for each PCI host bus.

slide-44
SLIDE 44

17/33

  • More Perls of wisdom
  • In June 2002, we decided Perl wasn’t appropriate for this purpose,

since it lives in /usr, which might not be available (early enough).

slide-45
SLIDE 45

17/33

  • More Perls of wisdom
  • In June 2002, we decided Perl wasn’t appropriate for this purpose,

since it lives in /usr, which might not be available (early enough).

  • The Perl version retrospectively became a prototype.
slide-46
SLIDE 46

17/33

  • More Perls of wisdom
  • In June 2002, we decided Perl wasn’t appropriate for this purpose,

since it lives in /usr, which might not be available (early enough).

  • The Perl version retrospectively became a prototype.
  • However, a scripting language was useful for the main programs.
slide-47
SLIDE 47

17/33

  • More Perls of wisdom
  • In June 2002, we decided Perl wasn’t appropriate for this purpose,

since it lives in /usr, which might not be available (early enough).

  • The Perl version retrospectively became a prototype.
  • However, a scripting language was useful for the main programs.
  • The templates for describing how to parse SCSI inquiry data were

too verbose and difficult to manage.

slide-48
SLIDE 48

17/33

  • More Perls of wisdom
  • In June 2002, we decided Perl wasn’t appropriate for this purpose,

since it lives in /usr, which might not be available (early enough).

  • The Perl version retrospectively became a prototype.
  • However, a scripting language was useful for the main programs.
  • The templates for describing how to parse SCSI inquiry data were

too verbose and difficult to manage.

  • Copy of device-tree as a database seemed to work. . .
slide-49
SLIDE 49

17/33

  • More Perls of wisdom
  • In June 2002, we decided Perl wasn’t appropriate for this purpose,

since it lives in /usr, which might not be available (early enough).

  • The Perl version retrospectively became a prototype.
  • However, a scripting language was useful for the main programs.
  • The templates for describing how to parse SCSI inquiry data were

too verbose and difficult to manage.

  • Copy of device-tree as a database seemed to work. . .
  • . . . as did the split in functionality between lsvpd and

update-device-tree.

slide-50
SLIDE 50

18/33

  • Requirements #3 (June 2002)
  • ‘Perl isn’t around early enough at boot time!’
slide-51
SLIDE 51

18/33

  • Requirements #3 (June 2002)
  • ‘Perl isn’t around early enough at boot time!’
  • Find ibm,vpd properties in the Open Firmware device-tree and

pretty print them. Also print information about SCSI devices. Use programming languages that are supported with just a root filesystem.

slide-52
SLIDE 52

18/33

  • Requirements #3 (June 2002)
  • ‘Perl isn’t around early enough at boot time!’
  • Find ibm,vpd properties in the Open Firmware device-tree and

pretty print them. Also print information about SCSI devices. Use programming languages that are supported with just a root filesystem.

  • Time required: a few weeks.
slide-53
SLIDE 53

19/33

  • C & shell (no seashores. . . )
  • Scripting languages are good. . .
slide-54
SLIDE 54

19/33

  • C & shell (no seashores. . . )
  • Scripting languages are good. . .
  • . . . but the only scripting language on the root filesystem is the

shell.

slide-55
SLIDE 55

19/33

  • C & shell (no seashores. . . )
  • Scripting languages are good. . .
  • . . . but the only scripting language on the root filesystem is the

shell.

  • /bin/bash can be assumed to be available. . .
slide-56
SLIDE 56

19/33

  • C & shell (no seashores. . . )
  • Scripting languages are good. . .
  • . . . but the only scripting language on the root filesystem is the

shell.

  • /bin/bash can be assumed to be available. . .
  • . . . and has good arithmetic support and other features.
slide-57
SLIDE 57

19/33

  • C & shell (no seashores. . . )
  • Scripting languages are good. . .
  • . . . but the only scripting language on the root filesystem is the

shell.

  • /bin/bash can be assumed to be available. . .
  • . . . and has good arithmetic support and other features.
  • C chosen for ‘helper utilities’.
slide-58
SLIDE 58

19/33

  • C & shell (no seashores. . . )
  • Scripting languages are good. . .
  • . . . but the only scripting language on the root filesystem is the

shell.

  • /bin/bash can be assumed to be available. . .
  • . . . and has good arithmetic support and other features.
  • C chosen for ‘helper utilities’.
  • glib-2.0 chosen as a utility library.
slide-59
SLIDE 59

20/33

  • Updating update-device-tree
  • update-device-tree is run relatively rarely.
  • lsvpd is run more often.
slide-60
SLIDE 60

20/33

  • Updating update-device-tree
  • update-device-tree is run relatively rarely.
  • lsvpd is run more often.
  • lsvpd should be as simple as possible — no rendering — just find

linux,vpd files and cat them.

slide-61
SLIDE 61

20/33

  • Updating update-device-tree
  • update-device-tree is run relatively rarely.
  • lsvpd is run more often.
  • lsvpd should be as simple as possible — no rendering — just find

linux,vpd files and cat them.

  • update-device-tree to do all the rendering.
slide-62
SLIDE 62

20/33

  • Updating update-device-tree
  • update-device-tree is run relatively rarely.
  • lsvpd is run more often.
  • lsvpd should be as simple as possible — no rendering — just find

linux,vpd files and cat them.

  • update-device-tree to do all the rendering.
  • sed is my best friend.
slide-63
SLIDE 63

20/33

  • Updating update-device-tree
  • update-device-tree is run relatively rarely.
  • lsvpd is run more often.
  • lsvpd should be as simple as possible — no rendering — just find

linux,vpd files and cat them.

  • update-device-tree to do all the rendering.
  • sed is my best friend.
  • Depend on busybox for find and sort.
slide-64
SLIDE 64

21/33

  • Rendering ibm,vpd
  • pci vpd to txt.[ch]
  • ibm vpd render.c
  • How is ibm,vpd different to PCI VPD?
slide-65
SLIDE 65

22/33

  • Rendering SCSI VPD
  • Obvious C helper is sg inq.
  • Small patch to add -r option (raw, binary output) accepted into

sg3 utils 1.01.

slide-66
SLIDE 66

22/33

  • Rendering SCSI VPD
  • Obvious C helper is sg inq.
  • Small patch to add -r option (raw, binary output) accepted into

sg3 utils 1.01.

  • scsi vpd std (in C) to parse 1st 32 bytes of standard inquiry.
slide-67
SLIDE 67

22/33

  • Rendering SCSI VPD
  • Obvious C helper is sg inq.
  • Small patch to add -r option (raw, binary output) accepted into

sg3 utils 1.01.

  • scsi vpd std (in C) to parse 1st 32 bytes of standard inquiry.
  • scsi vpd custom (in C) to extract custom fields via templates.
  • Template format (actually single-line):

IBM;disk;*; inquiry=RL:4,SN:8,Z1:12,_:42,Z2:4,Z3:5,_:1, Z4:4,Z5:2,FN:12,EC:10,PN:12,Z6:10,_:4; 0x83=_:8,Z7:8

slide-68
SLIDE 68

23/33

  • Enter lscfg
  • ‘Human readable’ output, plus platform specific information.
slide-69
SLIDE 69

23/33

  • Enter lscfg
  • ‘Human readable’ output, plus platform specific information.

sda U0.4-P1-I1/Z2-A8 16 Bit LVD SCSI Disk Drive (36400 MB) Manufacturer................IBM Machine Type and Model......IC35L036UCD210-0 Device Specific.(YL)........U0.4-P1-I1/Z2-A8 FRU Number..................09P3923 ROS Level and ID............53354253 Serial Number...............VMF99318 EC Level....................H32051 Part Number.................07N7070 Device Specific.(Z0)........000003029F00013A Device Specific.(Z1)........07N4908 Device Specific.(Z2)........0075 Device Specific.(Z3)........02172 Device Specific.(Z4)........0001 Device Specific.(Z5)........22 Device Specific.(Z6)........F80470 Device Specific.(Z7)........500507620CC4AC8E

  • Initially lscfg was a pretty printer.
slide-70
SLIDE 70

24/33

  • Cross platforms?
  • This could be useful on platforms other than pSeries.
slide-71
SLIDE 71

24/33

  • Cross platforms?
  • This could be useful on platforms other than pSeries.
  • Currently get PCI 2.0/2.1 VPD from device-tree.
slide-72
SLIDE 72

24/33

  • Cross platforms?
  • This could be useful on platforms other than pSeries.
  • Currently get PCI 2.0/2.1 VPD from device-tree.
  • Attempted to write pci vpd rom grab.
slide-73
SLIDE 73

24/33

  • Cross platforms?
  • This could be useful on platforms other than pSeries.
  • Currently get PCI 2.0/2.1 VPD from device-tree.
  • Attempted to write pci vpd rom grab.
  • Wrote pci vpd cap grab.
slide-74
SLIDE 74

25/33

  • Testing times (prelude)
  • In February 2003, people started testing out the lsvpd package. . .
slide-75
SLIDE 75

26/33

  • Requirements #4 (February 2003)
  • ‘lscfg is very different to the AIX version.’
  • ‘There’s a lot of stuff missing. . . ’
  • Find ibm,vpd properties in the Open Firmware device-tree and

pretty print them. Also print information about SCSI devices. Use programming languages that are supported with just a root

  • filesystem. Make lscfg work a lot more like the AIX version,

implement a whole bunch of options and make more components visible.

  • Required time: 6 weeks.
slide-76
SLIDE 76

27/33

  • Testing times (summary)
  • lscfg updated to show platform specific information. Tied more

closely to device-tree.

  • Synthesised VPD for SCSI and Ethernet adapters from information

in the device-tree.

slide-77
SLIDE 77

27/33

  • Testing times (summary)
  • lscfg updated to show platform specific information. Tied more

closely to device-tree.

  • Synthesised VPD for SCSI and Ethernet adapters from information

in the device-tree.

  • Distro kernels used sym53c8xx driver. Oops. . .
slide-78
SLIDE 78

27/33

  • Testing times (summary)
  • lscfg updated to show platform specific information. Tied more

closely to device-tree.

  • Synthesised VPD for SCSI and Ethernet adapters from information

in the device-tree.

  • Distro kernels used sym53c8xx driver. Oops. . .
  • . . . added IRQ-matching hack to compensate for broken bus

numbers.

slide-79
SLIDE 79

27/33

  • Testing times (summary)
  • lscfg updated to show platform specific information. Tied more

closely to device-tree.

  • Synthesised VPD for SCSI and Ethernet adapters from information

in the device-tree.

  • Distro kernels used sym53c8xx driver. Oops. . .
  • . . . added IRQ-matching hack to compensate for broken bus

numbers.

  • Released version 0.8.4 as part of SourceForge.net linux-diag project

in May 2003.

slide-80
SLIDE 80

27/33

  • Testing times (summary)
  • lscfg updated to show platform specific information. Tied more

closely to device-tree.

  • Synthesised VPD for SCSI and Ethernet adapters from information

in the device-tree.

  • Distro kernels used sym53c8xx driver. Oops. . .
  • . . . added IRQ-matching hack to compensate for broken bus

numbers.

  • Released version 0.8.4 as part of SourceForge.net linux-diag project

in May 2003.

  • Move various bits towards being ‘hotplug useful’.
slide-81
SLIDE 81

27/33

  • Testing times (summary)
  • lscfg updated to show platform specific information. Tied more

closely to device-tree.

  • Synthesised VPD for SCSI and Ethernet adapters from information

in the device-tree.

  • Distro kernels used sym53c8xx driver. Oops. . .
  • . . . added IRQ-matching hack to compensate for broken bus

numbers.

  • Released version 0.8.4 as part of SourceForge.net linux-diag project

in May 2003.

  • Move various bits towards being ‘hotplug useful’.
  • PCI domain support now in Linux 2.6.
  • Under 2.6, use sysfs to get PCI information.
slide-82
SLIDE 82

27/33

  • Testing times (summary)
  • lscfg updated to show platform specific information. Tied more

closely to device-tree.

  • Synthesised VPD for SCSI and Ethernet adapters from information

in the device-tree.

  • Distro kernels used sym53c8xx driver. Oops. . .
  • . . . added IRQ-matching hack to compensate for broken bus

numbers.

  • Released version 0.8.4 as part of SourceForge.net linux-diag project

in May 2003.

  • Move various bits towards being ‘hotplug useful’.
  • PCI domain support now in Linux 2.6.
  • Under 2.6, use sysfs to get PCI information.
  • 1500 lines of bash script and 1500 lines of C source.
slide-83
SLIDE 83

28/33

  • Goodbye glib!
  • The root-filesystem-only requirement meant statically linking to

libglib.a. Big executables!

  • Some code shoe-horned to work with glib to make it more

maintainable!

  • glib didn’t do everything. . .
slide-84
SLIDE 84

28/33

  • Goodbye glib!
  • The root-filesystem-only requirement meant statically linking to

libglib.a. Big executables!

  • Some code shoe-horned to work with glib to make it more

maintainable!

  • glib didn’t do everything. . .
  • Goodbye glib!
slide-85
SLIDE 85

28/33

  • Goodbye glib!
  • The root-filesystem-only requirement meant statically linking to

libglib.a. Big executables!

  • Some code shoe-horned to work with glib to make it more

maintainable!

  • glib didn’t do everything. . .
  • Goodbye glib!
  • Only had to ‘rewrite’ a tiny bit of glib’s self-expanding string

functionality.

slide-86
SLIDE 86

28/33

  • Goodbye glib!
  • The root-filesystem-only requirement meant statically linking to

libglib.a. Big executables!

  • Some code shoe-horned to work with glib to make it more

maintainable!

  • glib didn’t do everything. . .
  • Goodbye glib!
  • Only had to ‘rewrite’ a tiny bit of glib’s self-expanding string

functionality.

  • asprintf(3) is a thing of beauty!
slide-87
SLIDE 87

28/33

  • Goodbye glib!
  • The root-filesystem-only requirement meant statically linking to

libglib.a. Big executables!

  • Some code shoe-horned to work with glib to make it more

maintainable!

  • glib didn’t do everything. . .
  • Goodbye glib!
  • Only had to ‘rewrite’ a tiny bit of glib’s self-expanding string

functionality.

  • asprintf(3) is a thing of beauty!
  • So is fnmatch(3)
slide-88
SLIDE 88

29/33

  • Cross platforms with sysfs
  • sysfs contains useful information. . .
slide-89
SLIDE 89

29/33

  • Cross platforms with sysfs
  • sysfs contains useful information. . .
  • . . . enough for partial implementation of update-device-tree. . .
slide-90
SLIDE 90

29/33

  • Cross platforms with sysfs
  • sysfs contains useful information. . .
  • . . . enough for partial implementation of update-device-tree. . .
  • . . . without a device-tree.
slide-91
SLIDE 91

29/33

  • Cross platforms with sysfs
  • sysfs contains useful information. . .
  • . . . enough for partial implementation of update-device-tree. . .
  • . . . without a device-tree.
  • lsvpd even ‘runs’ on my ThinkPad r

.

slide-92
SLIDE 92

30/33

  • Self-selecting modules
  • Modularised update-device-tree, lsvpd & lscfg.
slide-93
SLIDE 93

30/33

  • Self-selecting modules
  • Modularised update-device-tree, lsvpd & lscfg.
  • Self-selecting modules. For example:

/lib/lsvpd/scan.d/30device-tree: [...] source_device_tree="/proc/device-tree" [ -f "${source_device_tree}/system-id" ] || return 0 [...]

  • Current modules:

scan.d/{00minimal,01ethtool,10devfs, 20sysfs,30device-tree,40ibm,vpd} lscfg.d/{00minimal,40ibm,vpd} common.d/00minimal

  • Subsequent modules redefine bash functions from earlier modules.
slide-94
SLIDE 94

31/33

  • Future possibilities
  • PCI expansion ROM blobs in sysfs?
slide-95
SLIDE 95

31/33

  • Future possibilities
  • PCI expansion ROM blobs in sysfs?
  • lsvpd helping to support persistent device naming.
slide-96
SLIDE 96

31/33

  • Future possibilities
  • PCI expansion ROM blobs in sysfs?
  • lsvpd helping to support persistent device naming.
  • Change management (mostly device/name changes).
slide-97
SLIDE 97

31/33

  • Future possibilities
  • PCI expansion ROM blobs in sysfs?
  • lsvpd helping to support persistent device naming.
  • Change management (mostly device/name changes).
  • Large systems (> 128 SCSI disks)?
slide-98
SLIDE 98

31/33

  • Future possibilities
  • PCI expansion ROM blobs in sysfs?
  • lsvpd helping to support persistent device naming.
  • Change management (mostly device/name changes).
  • Large systems (> 128 SCSI disks)?
  • Larger major/minor numbers?
slide-99
SLIDE 99

31/33

  • Future possibilities
  • PCI expansion ROM blobs in sysfs?
  • lsvpd helping to support persistent device naming.
  • Change management (mostly device/name changes).
  • Large systems (> 128 SCSI disks)?
  • Larger major/minor numbers?
  • sysfs support for sg driver?
slide-100
SLIDE 100

31/33

  • Future possibilities
  • PCI expansion ROM blobs in sysfs?
  • lsvpd helping to support persistent device naming.
  • Change management (mostly device/name changes).
  • Large systems (> 128 SCSI disks)?
  • Larger major/minor numbers?
  • sysfs support for sg driver?
  • lsvpd scalability?
slide-101
SLIDE 101

31/33

  • Future possibilities
  • PCI expansion ROM blobs in sysfs?
  • lsvpd helping to support persistent device naming.
  • Change management (mostly device/name changes).
  • Large systems (> 128 SCSI disks)?
  • Larger major/minor numbers?
  • sysfs support for sg driver?
  • lsvpd scalability?
  • A standard backend?

– sysfs-based? – Common-Information-Model (CIM) Object Manager (or CIMOM)? – Database used by kudzu?

slide-102
SLIDE 102

32/33

  • Conclusions
  • Started as a ‘toy’.
slide-103
SLIDE 103

32/33

  • Conclusions
  • Started as a ‘toy’.
  • Now used ‘in anger’.
slide-104
SLIDE 104

32/33

  • Conclusions
  • Started as a ‘toy’.
  • Now used ‘in anger’.
  • Lots of work to do. . .
slide-105
SLIDE 105

32/33

  • Conclusions
  • Started as a ‘toy’.
  • Now used ‘in anger’.
  • Lots of work to do. . .
  • Time required:
slide-106
SLIDE 106

32/33

  • Conclusions
  • Started as a ‘toy’.
  • Now used ‘in anger’.
  • Lots of work to do. . .
  • Time required:

?

slide-107
SLIDE 107

33/33

  • Questions?

?

Legal Statement

  • This work represents the view of the author and does not necessarily represent the view of IBM.
  • Linux is a registered trademark of Linus Torvalds.
  • The Linux lsvpd package is distributed under the GNU General Public License.
  • The following terms are trademarks or registered trademarks of International Business Machines Corporation in the

United States and/or other countries: IBM, , pSeries, ThinkPad and AIX.

  • Other company, product, and service names may be trademarks or service marks of others.