[parisc-linux] enumerating devices from user space

[parisc-linux] enumerating devices from user space

[Lyonel Vincent]

Hi there,

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).
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)
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.

thanks for your help,
Lyonel.

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...)

-- 
The software said it requires Windows 2000 or better, so I installed Linux.

Re: [parisc-linux] enumerating devices from user space

[Matthew Wilcox]

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

Re: [parisc-linux] enumerating devices from user space

[Lyonel Vincent]

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

-- 
The software said it requires Windows 2000 or better, so I installed Linux.

Re: [parisc-linux] enumerating devices from user space

[Helge Deller]

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

Re: [parisc-linux] enumerating devices from user space

[Lyonel Vincent]

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
> 

Re: [parisc-linux] enumerating devices from user space

[Matthew Wilcox]

On Wed, Mar 12, 2003 at 11:36:51PM +0100, Lyonel Vincent wrote:
> 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.

Right -- and you'll get this in 2.5 from sysfs.  Given this, I'm reluctant
to introduce a new file in /proc.

-- 
"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

Re: [parisc-linux] enumerating devices from user space

[Derek Engelhaupt]

[-- Attachment #1: Type: text/plain, Size: 6918 bytes --]


Being as I just got done with a class from HP Education on Linux, this very issue was brought up by all of us HP-UX guys.  We love our IOSCAN.  The instructor told us that someone within HP actually wrote an "ioscan" for Red Hat.  I'm thinking that getting a copy of that source code would be a good place to start.  I'm going to do a search for the guy tomorrow or get his name from our instructor to see if I can get a hold of his code.
derek
 Lyonel Vincent <vincentl@ec-lyon.fr> wrote: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 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
> > \t 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
> 
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux


---------------------------------
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online

[-- Attachment #2: Type: text/html, Size: 8475 bytes --]

Re: [parisc-linux] enumerating devices from user space

[Lyonel Vincent]

If you can find this, I will be VERY interested in having a look at it...
Thinking of it, this HP guy may well be me ;o)
You can contact me privately, it may happen that I know your instructor.

cheers,
lv.

> Being as I just got done with a class from HP Education on Linux, this very
> issue was brought up by all of us HP-UX guys.  We love our IOSCAN.  The
> instructor told us that someone within HP actually wrote an "ioscan" for
> Red Hat.  I'm thinking that getting a copy of that source code would be a
> good place to start.  I'm going to do a search for the guy tomorrow or get
> his name from our instructor to see if I can get a hold of his code.
> 
> derek

-- 
The software said it requires Windows 2000 or better, so I installed Linux.

Re: [parisc-linux] enumerating devices from user space

[bruno_vidal]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

    Hi guys.
While developping the dump modules, I had to find a way to retrieve
the hardware path of disk/hba. So I had to developpe a small hack
in the kernel/firmware.c in order to retrive the right hba.
But it is parisc dependant. Do you want I try to add an ioctl in my
dump modules in order to print in user space this informations ?
Example:

size:1500160 nr_sects:3000320 start_sect:374784
hwpath: 0/0/1/1.15.0.0.
dump device opened: 0x813 with index: 0 at hpa: 0x900

So my functions are able to print the hw path of each io modules.
Is it what you are looking for ?

--
        Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
        bruno_vidal@admin.france.hp.com



[-- Attachment #2: Card for --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] enumerating devices from user space

[Lyonel Vincent]

Hi Bruno,

That sounds like what I was looking for (HW path + version information)!
What do you think is the best approach?

cheers,
lv.

On Thu, 13 Mar 2003 12:30:44 +0100
bruno_vidal@hp.com wrote:

>     Hi guys.
> While developping the dump modules, I had to find a way to retrieve
> the hardware path of disk/hba. So I had to developpe a small hack
> in the kernel/firmware.c in order to retrive the right hba.
> But it is parisc dependant. Do you want I try to add an ioctl in my
> dump modules in order to print in user space this informations ?
> Example:
> 
> size:1500160 nr_sects:3000320 start_sect:374784
> hwpath: 0/0/1/1.15.0.0.
> dump device opened: 0x813 with index: 0 at hpa: 0x900
> 
> So my functions are able to print the hw path of each io modules.
> Is it what you are looking for ?
> 
> --
>         Vidal Bruno, (770-4271)
>         SSD-HA Team, HP-UX & LINUX Support
>         bruno_vidal@admin.france.hp.com
> 
> 

Re: [parisc-linux] enumerating devices from user space

[bruno_vidal]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

    Hi
I'll try to add an ioctls in my dump driver to print this list. It will
give a good starting point, isn't it ?
The other choice is to create a new modules that use my functions
in firmware.c. But keep in mind that it will usefull only for pa-risc.
I don't know if it is the best practice.

    cheers.

Lyonel Vincent wrote:

> Hi Bruno,
>
> That sounds like what I was looking for (HW path + version information)!
> What do you think is the best approach?
>
> cheers,
> lv.
>
> On Thu, 13 Mar 2003 12:30:44 +0100
> bruno_vidal@hp.com wrote:
>
> >     Hi guys.
> > While developping the dump modules, I had to find a way to retrieve
> > the hardware path of disk/hba. So I had to developpe a small hack
> > in the kernel/firmware.c in order to retrive the right hba.
> > But it is parisc dependant. Do you want I try to add an ioctl in my
> > dump modules in order to print in user space this informations ?
> > Example:
> >
> > size:1500160 nr_sects:3000320 start_sect:374784
> > hwpath: 0/0/1/1.15.0.0.
> > dump device opened: 0x813 with index: 0 at hpa: 0x900
> >
> > So my functions are able to print the hw path of each io modules.
> > Is it what you are looking for ?
> >
> > --
> >         Vidal Bruno, (770-4271)
> >         SSD-HA Team, HP-UX & LINUX Support
> >         bruno_vidal@admin.france.hp.com
> >
> >
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

--
        Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
        bruno_vidal@admin.france.hp.com



[-- Attachment #2: Card for --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] enumerating devices from user space

[Lyonel Vincent]

Hi Bruno,

The ioctl sounds great to me.
On which device would you "attach" it (as some of the devices I'd like
to report don't even have an entry in /dev), create a new one? Correct
me if I'm wrong (I don't know much about IOCTLs)
If you want me to help testing/developing, I have a 9000/C180 w/ Debian
(unstable) ready to use.

cheers,
lv.

PS: being PA-RISC dependent is not a problem, I already have ifdefs for
x86, PowerPC and Alpha

On Fri, 14 Mar 2003 09:45:59 +0100
bruno_vidal@hp.com wrote:

>     Hi
> I'll try to add an ioctls in my dump driver to print this list. It
> will give a good starting point, isn't it ?
> The other choice is to create a new modules that use my functions
> in firmware.c. But keep in mind that it will usefull only for pa-risc.
> I don't know if it is the best practice.
> 
>     cheers.
> 
> Lyonel Vincent wrote:
> 
> > Hi Bruno,
> >
> > That sounds like what I was looking for (HW path + version
> > information)! What do you think is the best approach?
> >
> > cheers,
> > lv.
> >
> > On Thu, 13 Mar 2003 12:30:44 +0100
> > bruno_vidal@hp.com wrote:
> >
> > >     Hi guys.
> > > While developping the dump modules, I had to find a way to
> > > retrieve the hardware path of disk/hba. So I had to developpe a
> > > small hack in the kernel/firmware.c in order to retrive the right
> > > hba. But it is parisc dependant. Do you want I try to add an ioctl
> > > in my dump modules in order to print in user space this
> > > informations ? Example:
> > >
> > > size:1500160 nr_sects:3000320 start_sect:374784
> > > hwpath: 0/0/1/1.15.0.0.
> > > dump device opened: 0x813 with index: 0 at hpa: 0x900
> > >
> > > So my functions are able to print the hw path of each io modules.
> > > Is it what you are looking for ?
> > >
> > > --
> > >         Vidal Bruno, (770-4271)
> > >         SSD-HA Team, HP-UX & LINUX Support
> > >         bruno_vidal@admin.france.hp.com
> > >
> > >
> >
> > _______________________________________________
> > parisc-linux mailing list
> > parisc-linux@lists.parisc-linux.org
> > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 
> --
>         Vidal Bruno, (770-4271)
>         SSD-HA Team, HP-UX & LINUX Support
>         bruno_vidal@admin.france.hp.com
> 
> 

Re: [parisc-linux] enumerating devices from user space

[Matthew Wilcox]

On Fri, Mar 14, 2003 at 01:33:05PM +0100, Lyonel Vincent wrote:
> The ioctl sounds great to me.

It sounds like an awful idea to me.  I'll never take that kind of patch
into my tree.

-- 
"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

Re: [parisc-linux] enumerating devices from user space

[Lyonel Vincent]

okokok I won't argue then.
I would have liked to have ioscan-like support, but anyway...

On Fri, 14 Mar 2003 13:19:21 +0000
Matthew Wilcox <willy@debian.org> wrote:

> On Fri, Mar 14, 2003 at 01:33:05PM +0100, Lyonel Vincent wrote:
> > The ioctl sounds great to me.
> 
> It sounds like an awful idea to me.  I'll never take that kind of
> patch into my tree.
> 

Re: [parisc-linux] enumerating devices from user space

[Matthew Wilcox]

On Fri, Mar 14, 2003 at 03:05:49PM +0100, Lyonel Vincent wrote:
> okokok I won't argue then.
> I would have liked to have ioscan-like support, but anyway...

Well, you can have it in 2.5; start looking at sysfs.

-- 
"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

Re: [parisc-linux] enumerating devices from user space

[Grant Grundler]

On Fri, Mar 14, 2003 at 02:08:48PM +0000, Matthew Wilcox wrote:
> On Fri, Mar 14, 2003 at 03:05:49PM +0100, Lyonel Vincent wrote:
> > okokok I won't argue then.
> > I would have liked to have ioscan-like support, but anyway...
> 
> Well, you can have it in 2.5; start looking at sysfs.

willy and I talked offline and it seems like the right
answer is to backport _the user interface_ - ie something
that *looks* like sysfs but could be based on /proc.

I'd basically like to see all resources in struct parisc_device
exported using the same name as the field - matching sysfs field
names use for PCI where appropriate. Willy suggested id be broken
out into it's struct parisc_device_id parts and provided
directly has hex strings (eg hw_type  entry could contain "0x5").
Details of how sysfs currently looks are still changing - don't get
hung up in the current details.

grant

Re: [parisc-linux] enumerating devices from user space

[Lyonel Vincent]

Hi Grant,

sounds very good to me (and way cleaner)...
I'll be happy to try to help.

cheers,
lv.

On Fri, Mar 14, 2003 at 10:29:24AM -0700, Grant Grundler wrote:
> On Fri, Mar 14, 2003 at 02:08:48PM +0000, Matthew Wilcox wrote:
> > On Fri, Mar 14, 2003 at 03:05:49PM +0100, Lyonel Vincent wrote:
> > > okokok I won't argue then.
> > > I would have liked to have ioscan-like support, but anyway...
> > 
> > Well, you can have it in 2.5; start looking at sysfs.
> 
> willy and I talked offline and it seems like the right
> answer is to backport _the user interface_ - ie something
> that *looks* like sysfs but could be based on /proc.
> 
> I'd basically like to see all resources in struct parisc_device
> exported using the same name as the field - matching sysfs field
> names use for PCI where appropriate. Willy suggested id be broken
> out into it's struct parisc_device_id parts and provided
> directly has hex strings (eg hw_type  entry could contain "0x5").
> Details of how sysfs currently looks are still changing - don't get
> hung up in the current details.
> 
> grant

-- 
The software said it requires Windows 2000 or better, so I installed Linux.