[parisc-linux] enumerating devices from user space

Lyonel Vincent vincentl@ec-lyon.fr
Wed, 12 Mar 2003 23:36:51 +0100


Hello Helge,

The goal is precisely that: *accurately* report installed hardware
(including the "standard" stuff) and how it's connected in a *unified*
way, without having to use dozens of inconsistent tools (pci-utils,
lsusb, sg-utils, cat, grep, black magic, etc.).
A good example of this being HP-UX's ioscan. DMI-aware PCs also have a
similar feature.

SCSI, PCI etc. are already enumerated platform-independently (without
needing pci-utils nor sg-utils, only pci.ids) but they currently seem to
come "out of the void" as the underlying hardware (LASI, various GSC
bridges, etc) is not enumerated.
Concerning the obvious /proc/cpuinfo, its info is reported too (on
PA-RISC, x86, IA-64, PowerPC and Alpha).

In short, that's why I'd like to access ioscan-like data under PA-RISC
Linux from user space.

cheers,
lv.

On Wed, 12 Mar 2003 21:50:50 +0100
Helge Deller <deller@gmx.de> wrote:

> Hi,
> 
> I think the most intesting thing is the name of the system, which is
> (untested!) in /proc/cpuinfo (should give you "Raven U 240
> (9000/780/C240)").
> 
> The rest is mostly and often standard serial, parallel, SCSI, pci
> (pci-utils!), and some strange GSC cards (which often give you some of
> the above devices).
> 
> Regards,
> Helge
> 
> On Wednesday 12 March 2003 18:30, Lyonel Vincent wrote:
> > many thanks for the prompt answer
> >
> > well... that's exactly the answer I didn't want to ear ;o)
> > lshw can't reasonably assume that /var/log/dmesg exists and is
> > correct (or even dmesg) and dig into the trash.
> >
> > My kernel programming skills are extremely limited (not to say
> > inexistent) but how difficult would it be to expose this information
> > to user space through /proc? (AFAICT, we already have PA-RISC
> > specific files like/proc/bus/runway) A simplistic format like
> > <hwpath>\t<type> <instance><hversion> <sversion> etc. would do.
> > Do you think it'd be useful to make that kind of information
> > available to user- space? (besides lshw of course ;op) If it's the
> > case I'll try to do my best...
> >
> > cheers,
> > lv.
> >
> > On Wed, Mar 12, 2003 at 04:48:52PM +0000, Matthew Wilcox wrote:
> > > On Wed, Mar 12, 2003 at 05:32:36PM +0100, Lyonel Vincent wrote:
> > > > I'm currently implementing a small tool called lshw (you can
> > > > find it on Freshmeat) that enumerates installed devices on a
> > > > machine and reports them as a device tree (text, HTML and XML).
> > >
> > > That's cool.
> > >
> > > > For now it knows about DMI, PCI busses, SCSI, IDE and PCMCIA and
> > > > I would like to port it to PA-RISC Linux. I already get some
> > > > very basic info from /proc/cpuinfo.
> > > > Does anyone know how I can access the device tree as seen by the
> > > > kernel? (much like HP-UX's ioscan does and what is shown in
> > > > dmesg)
> > >
> > > You can look in /var/log/dmesg.  For example...
> > >
> > > Found devices:
> > > 1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580,
> > > 0xf, 0xb 2. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions
> > > 0x680, 0x0, 0xa, additional addresses: 0xf2800000 3. Raven U/L2
> > > Dino PS/2 Port (10) at 0xf2001000 [8/1], versions 0x6, 0x0, 0x96
> > > 4. Raven U/L2 Dino RS-232 (10) at 0xf2003000 [8/3], versions 0x6,
> > > 0x0, 0x8c 5. Raven U/L2 Core FW-SCSI(4) at 0xf200c000 [8/12],
> > > versions 0x3b, 0x0, 0x89 6. Raven U/L2 Core BA(11) at 0xffd00000
> > > [8/16], versions 0x3b, 0x0, 0x81,  additional addresses:
> > > 0xffd0c000 0xffc00000 7. Raven U/L2 Core Centronics (10) at
> > > 0xffd02000 [8/16/0], versions 0x3b, 0x0, 0x74,  additional
> > > addresses: 0xffd01000 0xffd03000 8. Raven U/L2 Core Audio (10) at
> > > 0xffd04000[8/16/1], versions 0x3b, 0x4, 0x7b 9. Raven U/L2 Core
> > > RS-232 (10) at 0xffd05000 [8/16/4], versions 0x3b, 0x0, 0x8c 10.
> > > Raven U/L2 Core SCSI(10) at 0xffd06000 [8/16/5], versions 0x3b,
> > > 0x0, 0x82 11. Raven U/L2 Core LAN (802.3) (10) at 0xffd07000
> > > [8/16/6], versions 0x3b, 0x0, 0x8a 12. Raven U/L2 Core PS/2 Port
> > > (10) at 0xffd08000 [8/16/7], versions 0x3b, 0x0, 0x84 13. Raven
> > > U/L2 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x3b,
> > > 0x0, 0x84 14. Raven Backplane Wax BA (11) at 0xffe00000[8/20],
> > > versions 0x17, 0x0, 0x8e 15. Raven Backplane Wax HIL (10) at
> > > 0xffe01000 [8/20/1], versions 0x17, 0x0, 0x73 16. Raven Backplane
> > > RS-232(10) at 0xffe02000 [8/20/2], versions 0x17, 0x0, 0x8c 17.
> > > Raven Backplane Wax EISA BA (11) at 0xfc000000 [8/20/5], versions
> > > 0x17, 0x0, 0x90, additional addresses: 0xffc88000 0xfc00000b 18.
> > > Gecko GSC Core Graphics(10) at 0xfa000000 [8/24], versions 0x16,
> > > 0x0, 0x85,  additional addresses: 0xf0026000 19. U2-IOA BC GSC+
> > > Port (7) at 0xf203f000 [8/63], versions 0x501, 0x1, 0xc 20. U2-IOA
> > > BC Runway Port (12) at 0xfff8a000[10], versions 0x580, 0xf, 0xb
> > > 21. U2-IOA BC GSC+ Port (7) at 0xf103f000[10/63], versions 0x501,
> > > 0x1, 0xc 22. Raven U 240 (9000/780/C240) (0) at 0xfffa0000 [32],
> > > versions 0x599, 0x0, 0x4 23. Memory (1) at 0xfffb1000[49],
> > > versions 0x6f, 0x0, 0x9
> > >
> > > The numbers in [] tell you what the tree looks like.  In this
> > > example, we have 4 top-level devices: #1, #20, #22 & #23.
> > >
> > > > I've tried digging in /proc without much success... is there a
> > > > way to get this information from user space? PPC Linux exposes
> > > > the device tree in /proc for example. A mechanism similar to
> > > > /proc/bus/pci/devices(machine- parseable text) would be great,
> > > > too.
> > >
> > > In 2.5, this information's available via sysfs.  I don't think
> > > we'll expose it in /proc.
> > >
> > > > PS: I noticed that /proc/iomem lists 00000000-000009ff as "PDC
> > > > data(Page Zero)", is there a chance I can find what I need
> > > > there? (I dd-ed it from /dev/mem but I can't say if it contains
> > > > useful data...)
> > >
> > > No, you need to actually make firmware calls and you can't do that
> > > from user mode.
> > >
> > > --
> > > "It's not Hollywood.  War is real, war is primarily not about
> > > defeat or victory, it is about death.  I've seen thousands and
> > > thousands of dead bodies. Do you think I want to have an academic
> > > debate on this subject?"-- Robert Fisk
>