ISA hardware discovery -- the elegant solution
I've been thinking about the hardware-discovery problem for ISA devices, and there may be an elegant solution. It will take a number of small changes to the kernel sources, however.
The kernel's device drivers have, of course, to include probe routines, and those hard-compiled in typically log the presence of their hardware to /var/log/mesg when it loads. By scanning that file, we in effect get to use those probes.
My autoconfigurator's probe table now has a small number of tests than do regexp matches against the dmesg log. As is, this solution does not scale well, because each regexp has to be discovered by eyeball and then maintained in the table by hand.
But suppose the format of boot-time driver messages were standardized in a format that included their config symbol in a discoverable form?
I have hand-edited a copy of my current /var/log/dmesg to illustrate how I think this could work.
:MTRR: your CPUs had inconsistent fixed MTRR settings
:MTRR: probably your BIOS does not setup all CPUs
:PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=1
:PCI: Using configuration type 1
:PCI: Probing PCI hardware
BIOS disabled PCI ordering compliance, so we enabled it again. :IO_APIC: AMD Errata #22 may be present. In the event of instability try
: booting with the "noapic" option.
:NET: Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039 :RTNETLINK: Initializing RT netlink socket
Starting kswapd
allocated 32 pages and 32 bhs reserved for the highmem bounces :JBD: Journalled Block Device driver loaded
:UNIX_PTY: 2048 Unix98 ptys configured
block: 128 slots per queue, batch=32
:IDE: Uniform Multi-Platform E-IDE driver Revision: 6.31
:IDE: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx :SCSI: SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Vendor: IBM-PSG Model: ST318451LW !# Rev: B833 Type: Direct-Access ANSI SCSI revision: 03 Vendor: IBM-PSG Model: ST318451LW !# Rev: B833 Type: Direct-Access ANSI SCSI revision: 03 Vendor: HP Model: C5683A Rev: C005 Type: Sequential-Access ANSI SCSI revision: 02 scsi0:A:0:0: Tagged Queuing enabled. Depth 253 scsi0:A:1:0: Tagged Queuing enabled. Depth 253 Vendor: PIONEER Model: DVD-ROM DVD-305 Rev: 1.00 Type: CD-ROM ANSI SCSI revision: 02 Vendor: PLEXTOR Model: CD-R PX-W1210S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sda: 35548320 512-byte hdwr sectors (18201 MB)
Partition check:
sda: sda1 sda2 < sda5 >
(scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sdb: 35548320 512-byte hdwr sectors (18201 MB)
sdb: sdb1 sdb2
Attached scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi1, channel 0, id 1, lun 0
(scsi1:A:0): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
(scsi1:A:1): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray :USB_DEVFS: registered new driver usbdevfs
:USB: registered new driver hub
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 16384 buckets, 128Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 96k freed
Adding Swap: 1807272k swap-space (priority -1)
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,5), internal journal :BLK_DEV_MD: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
kjournald starting. Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,18), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
:BLK_DEV_ST: Version 20011103, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16 Attached scsi tape st0 at scsi0, channel 0, id 2, lun 0
The convention I propose is that at least one line of a driver probe message should begin with :, followed by the driver config symbol, followed by :. I am not attached to that particular punctuation, it is simply an unambiguous way of indicating "this is a config symbol".
With this change, generating a report on ISA hardware and other facilities configured in at boot time would be trivial. This would make the autoconfigurator much more capable. Best of all, the only change required to accomplish this would be safe edits of print format strings.
I would be willing to generate a patch to implement this change.
Signature · 5 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long
Quoted 5 lines
:MTRR: your CPUs had inconsistent fixed MTRR settings :MTRR: probably your BIOS does not setup all CPUs :PCI: PCI BIOS revision 2.10 entry at
0xfd7c0, last bus=1 :PCI: Using configuration type 1
:PCI: Probing PCI hardware
It's ugly and distracting and if this proposal goes anywhere, move the tag to end of the line. Then your eyes can scan the output and the tools can scan the end of the line.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 3 lines · Eric S. Raymond
I've been thinking about the hardware-discovery problem for ISA devices, and there may be an elegant solution. It will take a number of small changes to the kernel sources, however.
An elegant solution is writing a program like kudzu and placing the information it generates in a globally accessible place. The problem is that linux does really have a complete standard hardware database, and until such a thing is built there are no short cuts, no easy methods to get it. And there probably never will be guaranteed unprivledged user space access to the information. The system administrator may simply not want to let that information go.
The only thing that comes close to what you currently want is devfs.
dmesg is for people.
As for ISA there is a reason even the enhance version that allows software discovery is called Plug-and-Pray.
Quoted 4 lines
My autoconfigurator's probe table now has a small number of tests than do regexp matches against the dmesg log. As is, this solution does not scale well, because each regexp has to be discovered by eyeball and then maintained in the table by hand.
ISA is not a software enumerable bus especially not for unprivledged users. And no amount of complaining will change that. That is why we have PNP ISA and PCI.
Quoted 2 lines
But suppose the format of boot-time driver messages were standardized in a format that included their config symbol in a discoverable form?
If there was an ISA device in your example it might be interesting.
Quoted 5 lines
With this change, generating a report on ISA hardware and other facilities configured in at boot time would be trivial. This would make the autoconfigurator much more capable. Best of all, the only change required to accomplish this would be safe edits of print format strings.
It sounds like what you want is an lsmod that lists compiled in modules.
Quoted 1 line
I would be willing to generate a patch to implement this change.
Please don't until you understand the problem...
Eric
Eric W. Biederman <[email protected]>:
Quoted 3 lines
ISA is not a software enumerable bus especially not for unprivledged users. And no amount of complaining will change that. That is why we have PNP ISA and PCI.
But the kernel itself has to know how to probe and initialize these devices at boot time, correct? That information is implicitly exported via /var/log/dmesg -- I'm simply suggesting that it be a little more explicit.
Quoted 4 lines
Quoted 2 lines
But suppose the format of boot-time driver messages were standardized in a format that included their config symbol in a discoverable form?
If there was an ISA device in your example it might be interesting.
Some of the on-board devices on my Tyan Thunder are ISA.
Quoted 8 lines
Quoted 5 lines
With this change, generating a report on ISA hardware and other facilities configured in at boot time would be trivial. This would make the autoconfigurator much more capable. Best of all, the only change required to accomplish this would be safe edits of print format strings.
It sounds like what you want is an lsmod that lists compiled in modules.
Would that be feasible without root privileges in order to read kmem?
Signature · 8 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
[The disarming of citizens] has a double effect, it palsies the hand
and brutalizes the mind: a habitual disuse of physical forces totally
destroys the moral [force]; and men lose at once the power of
protecting themselves, and of discerning the cause of their
oppression.
-- Joel Barlow, "Advice to the Privileged Orders", 1792-93Followup to: <[email protected]> By author: "Eric S. Raymond" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 5 lines
But the kernel itself has to know how to probe and initialize these devices at boot time, correct? That information is implicitly exported via
/var/log/dmesg-- I'm simply suggesting that it be a little more explicit.
dmesg is lossy. Don't assume it is complete.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 8 lines · Eric S. Raymond
Eric W. Biederman <[email protected]>:
Quoted 3 lines
ISA is not a software enumerable bus especially not for unprivledged users. And no amount of complaining will change that. That is why we have PNP ISA and PCI.
But the kernel itself has to know how to probe and initialize these devices at boot time, correct? That information is implicitly exported via
/var/log/dmesg-- I'm simply suggesting that it be a little more explicit.
For ISA not necessarily. It could simply be told that it was there. /etc/modules.conf or it's compile time equivalent.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
But suppose the format of boot-time driver messages were standardized in a format that included their config symbol in a discoverable form?
If there was an ISA device in your example it might be interesting.
Some of the on-board devices on my Tyan Thunder are ISA.
I agree that ISA is a case. I simply didn't see it. And that was my real point. Usually we are pretty silent about most ISA devices in dmesg, because of most of them are mandated by the PC architecture and we just expect them to be there.
Quoted 10 lines
Quoted 8 lines
Quoted 5 lines
With this change, generating a report on ISA hardware and other facilities configured in at boot time would be trivial. This would make the autoconfigurator much more capable. Best of all, the only change required to accomplish this would be safe edits of print format strings.
It sounds like what you want is an lsmod that lists compiled in modules.
Would that be feasible without root privileges in order to read kmem?
Given that nothing in the linux world reads kmem...
Honestly you have two separate problems.
Problem 1: How do you find out all of the hardware you have, as root. Problem 2: How do you get that information as non-root.
Please try solving these problems separately.
Eric