Re: /proc/pci deprecation?

Re: /proc/pci deprecation?

[Petr Vandrovec]

On  6 Dec 02 at 16:13, Patrick Mochel wrote:
> 
> > IIRC it was one of (a) deprecated, (b) removed, or (c) almost removed in
> > the past, and Linus un-deprecated it.  The logic back then was that it
> > provides a quick summary of a lot of useful info, a la /proc/cpuinfo and
> > /proc/meminfo.  i.e. you don't need lspci installed, just been /bin/cat.
> 
> Ok, I can see that. But, are there really many systems that do not come with
> lspci(8) pre-installed? I would expect that most distributions do; at least
> the one I use does..
> 
> But, look the usage model. Who queries PCI information from the system? I
> would argue a) developers, b) power users, and c) users hitting a bug. 

It is invaluable during installation, when no lspci is installed yet.
I know that I need e100/eepro100 for 
'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not
have even slightest idea what device 8086:2449 is, whether USB or NIC or
VGA or some bridge.

Next problem is that some drivers want to print "user readable" hardware
name to user, and although some have its own name database (e100), some
use name from pcidev...
 
> > I do grant you it would make various __init sections and in-memory 
> > structures smaller if we eliminated the names...   do we want to?  Sure we
> > have lseisa and lspci and lsusb, et. al.  Does that obviate the need for a
> > simple summary of attached hardware?
> 
> IMO, yes, since those tools provide the summary, and exist almost purely in
> userspace. I forgot to mention in the orginal email that we could also drop
> the PCI names database, right? This would save a considerable amount in the
> kernel image alone..

If you want, make it user configurable like it was during 2.2.x. But
I personally prefer descriptive names and system overview I can parse 
without having mounted /usr to get working lspci.
                                                Best regards,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    

Re: /proc/pci deprecation?

[Willy Tarreau]

On Sat, Dec 07, 2002 at 12:18:05AM +0100, Petr Vandrovec wrote:
> It is invaluable during installation, when no lspci is installed yet.
> I know that I need e100/eepro100 for 
> 'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not
> have even slightest idea what device 8086:2449 is, whether USB or NIC or
> VGA or some bridge.

at least, the file "modules.pcimap" tells you which modules support these
devices, by vendor/model codes. I once developped a little installation script
which loaded all the NICs it could by listing /proc/bus/pci/devices and
modules.pcimap. I too agree that names in /proc/pci are *really* useful, but I
often omit them when I need a very little image. Perhaps having a list of names
only for devices supported by the kernel and modules at compile time would be
an acceptable compromise ?

Regards,
Willy

Re: /proc/pci deprecation?

[Tomas Szepe]

> > It is invaluable during installation, when no lspci is installed yet.
> > I know that I need e100/eepro100 for 
> > 'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not
> > have even slightest idea what device 8086:2449 is, whether USB or NIC or
> > VGA or some bridge.
> 
> at least, the file "modules.pcimap" tells you which modules support these
> devices, by vendor/model codes. I once developped a little installation script
> which loaded all the NICs it could by listing /proc/bus/pci/devices and
> modules.pcimap. I too agree that names in /proc/pci are *really* useful, but I
> often omit them when I need a very little image. Perhaps having a list of names
> only for devices supported by the kernel and modules at compile time would be
> an acceptable compromise?

I've been using the following script in my install images to find kernel
modules for various PCI devices (the mechanism's not perfect, though,
I know of at least one module that "doesn't put" its ids in modules.pcimap):

#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin

PCIMAP=/lib/modules/$(uname -r)/modules.pcimap
ALLDEV=$(lspci -n| sed -e 's/^.*:[[:blank:]]\+\([^[:blank:]]\+\).*$/\1/')

if [ -n "$ALLDEV" -a -r $PCIMAP ]; then
  for i in $ALLDEV; do
    VENDOR="$(echo $i| cut -d':' -f1)"
    DEVICE="$(echo $i| cut -d':' -f2)"
    MODULE=$(grep "0x0000$VENDOR[[:blank:]]\+0x0000$DEVICE" $PCIMAP| \
      awk '{ print $1; }')
    echo -n "Vendor $VENDOR, dev $DEVICE: "
    if [ -n "$MODULE" ]; then
      echo $MODULE
    else
      echo "(no matching module)"
    fi
  done
fi

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: /proc/pci deprecation?

[Linus Torvalds]

One thing that /proc/pci gives you that 'lspci' historically didn't was
the correct interrupt setup (because kernel irq routing has nothing to do
with the PCI irq config byte on most "interesting" machines).

I don't know if lspci gets that right these days, and the information does
exist in /sys, so there is certainly at least the _potential_ of dropping
/proc/pci.

			Linus

Re: /proc/pci deprecation?

[Patrick Mochel]

> One thing that /proc/pci gives you that 'lspci' historically didn't was
> the correct interrupt setup (because kernel irq routing has nothing to do
> with the PCI irq config byte on most "interesting" machines).
> 
> I don't know if lspci gets that right these days, and the information does
> exist in /sys, so there is certainly at least the _potential_ of dropping
> /proc/pci.

It appears to: 

[mochel@tina mochel]$ lspci -v | grep -B 2  IRQ | fgrep -v Subsystem 

00:07.4 USB Controller: Advanced Micro Devices [AMD] AMD-765 [Viper] USB (rev 07) (prog-if 10 [OHCI])
        Flags: bus master, medium devsel, latency 16, IRQ 19
--
00:09.0 Multimedia audio controller: Creative Labs: Unknown device 0004 (rev 03)
        Flags: bus master, medium devsel, latency 64, IRQ 17
--
00:09.2 FireWire (IEEE 1394): Creative Labs: Unknown device 4001 (prog-if 10 [OHCI])
        Flags: bus master, medium devsel, latency 64, IRQ 18
--

00:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
        Flags: bus master, medium devsel, latency 64, IRQ 19
--

00:0c.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 01)
        Flags: bus master, medium devsel, latency 66, IRQ 16
--
01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5144 (prog-if 00 [VGA])
        Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel, latency 66, IRQ 18

[mochel@tina mochel]$ fgrep -B 1 IRQ /proc/pci 
    USB Controller: Advanced Micro Devic AMD-766 [ViperPlus]  (rev 7).
      IRQ 19.
--
    Multimedia audio controller: Creative Labs SB Audigy (rev 3).
      IRQ 17.
--
    FireWire (IEEE 1394): Creative Labs SB Audigy FireWire P (rev 0).
      IRQ 18.
--
    Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boo (rev 0).
      IRQ 19.
--
    Ethernet controller: Intel Corp. 82557/8/9 [Ethernet  (rev 1).
      IRQ 16.
--
    VGA compatible controller: ATI Technologies Inc Radeon QD (rev 0).
      IRQ 18.


The appended patch both make /proc/pci a compile-time option and 
deprecates it and the PCI names database. Text has been added to the 
configuration options, and the top of the file. 

The /proc/pci functionality has been moved from drivers/pci/proc.c to 
drivers/pci/names.c, to make it closer to the PCI names interface. It 
ain't the prettiest, but it's simple to understand. 


	-pat

diffstat:

 Documentation/Changes |    4 +
 drivers/pci/Kconfig   |   38 ++++++++---
 drivers/pci/names.c   |  167 +++++++++++++++++++++++++++++++++++++++++++++++++-
 drivers/pci/proc.c    |  113 ---------------------------------
 4 files changed, 199 insertions(+), 123 deletions(-)


===== Documentation/Changes 1.28 vs edited =====
--- 1.28/Documentation/Changes	Fri Nov  8 01:47:19 2002
+++ edited/Documentation/Changes	Sat Dec  7 20:53:59 2002
@@ -347,6 +347,10 @@
 ----------
 o  <http://powertweak.sourceforge.net/>
 
+pci-utils
+---------
+o  <ftp://ftp.kernel.org/pub/software/utils/pciutils/>
+
 Networking
 **********
 
===== drivers/pci/Kconfig 1.1 vs edited =====
--- 1.1/drivers/pci/Kconfig	Tue Oct 29 19:16:55 2002
+++ edited/drivers/pci/Kconfig	Sat Dec  7 20:37:24 2002
@@ -1,18 +1,38 @@
 #
 # PCI configuration
 #
+
+config PCI_OLD_PROC
+	bool "/proc/pci Interface"
+	depends on PCI && PROC_FS
+	---help---
+	  This option is deprecated.
+
+	  This option provides the traditional /proc/pci interface, which lists
+	  every PCI device and some information extracted from their configuration
+	  space. 
+
+	  This option has been deprecated as of kernel version 2.5.51. The option
+	  and the /proc/pci interface will be removed at a futre date. The 
+	  preferred alternative is to use the lspci(8) utility. Please refer to
+	  Documentation/Changes for information on where to get the latest version.
+
+	  If unsure, say N and use lspci(8) instead. 
+
 config PCI_NAMES
 	bool "PCI device name database"
 	depends on PCI
 	---help---
-	  By default, the kernel contains a database of all known PCI device
-	  names to make the information in /proc/pci, /proc/ioports and
-	  similar files comprehensible to the user. This database increases
-	  size of the kernel image by about 80KB, but it gets freed after the
-	  system boots up, so it doesn't take up kernel memory. Anyway, if you
-	  are building an installation floppy or kernel for an embedded system
-	  where kernel image size really matters, you can disable this feature
-	  and you'll get device ID numbers instead of names.
+	  This option is deprecated. 
+
+	  This option adds a database of PCI device names to make the names of 
+	  PCI devices in /proc/pci and /proc/ioports more sensible. The /proc/pci
+	  interface has been deprecated, and when it is removed, the PCI names 
+	  database will also probably be removed.
+
+	  This option increases the size of the kernel by about 55KB. If 
+	  CONFIG_HOTPLUG is not set, then this memory is freed after the system
+	  boots up. 
 
-	  When in doubt, say Y.
+	  When in doubt, say N.
 
===== drivers/pci/names.c 1.5 vs edited =====
--- 1.5/drivers/pci/names.c	Sat Nov 16 16:54:29 2002
+++ edited/drivers/pci/names.c	Sat Dec  7 20:45:23 2002
@@ -1,8 +1,16 @@
 /*
- *	PCI Class and Device Name Tables
+ *	PCI Class and Device Name Tables and /proc/pci interface.
  *
  *	Copyright 1993--1999 Drew Eckhardt, Frederic Potter,
  *	David Mosberger-Tang, Martin Mares
+ *
+ *	These features have been depcrecated as of v2.5.51. 
+ *	The PCI names interface was useful only for presenting meaningful names
+ *	in /proc/pci and /proc/ioports.
+ *	The /proc/pci interface is deprecated, as lspci(8) is a much more useful
+ *	tool that provides all the info in /proc/pci and more, while existing
+ *	completely in userspace. That is now the preferred method of extracting
+ *	PCI device data. 
  */
 
 #include <linux/config.h>
@@ -11,6 +19,7 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 
+
 #ifdef CONFIG_PCI_NAMES
 
 struct pci_device_info {
@@ -136,3 +145,159 @@
 
 #endif /* CONFIG_PCI_NAMES */
 
+
+#ifdef CONFIG_PCI_OLD_PROC
+
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+
+/* iterator */
+static void *pci_seq_start(struct seq_file *m, loff_t *pos)
+{
+	struct list_head *p = &pci_devices;
+	loff_t n = *pos;
+
+	/* XXX: surely we need some locking for traversing the list? */
+	while (n--) {
+		p = p->next;
+		if (p == &pci_devices)
+			return NULL;
+	}
+	return p;
+}
+static void *pci_seq_next(struct seq_file *m, void *v, loff_t *pos)
+{
+	struct list_head *p = v;
+	(*pos)++;
+	return p->next != &pci_devices ? p->next : NULL;
+}
+static void pci_seq_stop(struct seq_file *m, void *v)
+{
+	/* release whatever locks we need */
+}
+
+
+/*
+ *  Backward compatible /proc/pci interface.
+ */
+
+/*
+ * Convert some of the configuration space registers of the device at
+ * address (bus,devfn) into a string (possibly several lines each).
+ * The configuration string is stored starting at buf[len].  If the
+ * string would exceed the size of the buffer (SIZE), 0 is returned.
+ */
+static int show_dev_config(struct seq_file *m, void *v)
+{
+	struct list_head *p = v;
+	struct pci_dev *dev;
+	struct pci_driver *drv;
+	u32 class_rev;
+	unsigned char latency, min_gnt, max_lat, *class;
+	int reg;
+
+	if (p == &pci_devices) {
+		seq_puts(m, "PCI devices found:\n");
+		return 0;
+	}
+
+	dev = pci_dev_g(p);
+	drv = pci_dev_driver(dev);
+
+	pci_read_config_dword(dev, PCI_CLASS_REVISION, &class_rev);
+	pci_read_config_byte (dev, PCI_LATENCY_TIMER, &latency);
+	pci_read_config_byte (dev, PCI_MIN_GNT, &min_gnt);
+	pci_read_config_byte (dev, PCI_MAX_LAT, &max_lat);
+	seq_printf(m, "  Bus %2d, device %3d, function %2d:\n",
+	       dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+	class = pci_class_name(class_rev >> 16);
+	if (class)
+		seq_printf(m, "    %s", class);
+	else
+		seq_printf(m, "    Class %04x", class_rev >> 16);
+	seq_printf(m, ": %s (rev %d).\n", dev->dev.name, class_rev & 0xff);
+
+	if (dev->irq)
+		seq_printf(m, "      IRQ %d.\n", dev->irq);
+
+	if (latency || min_gnt || max_lat) {
+		seq_printf(m, "      Master Capable.  ");
+		if (latency)
+			seq_printf(m, "Latency=%d.  ", latency);
+		else
+			seq_puts(m, "No bursts.  ");
+		if (min_gnt)
+			seq_printf(m, "Min Gnt=%d.", min_gnt);
+		if (max_lat)
+			seq_printf(m, "Max Lat=%d.", max_lat);
+		seq_putc(m, '\n');
+	}
+
+	for (reg = 0; reg < 6; reg++) {
+		struct resource *res = dev->resource + reg;
+		unsigned long base, end, flags;
+
+		base = res->start;
+		end = res->end;
+		flags = res->flags;
+		if (!end)
+			continue;
+
+		if (flags & PCI_BASE_ADDRESS_SPACE_IO) {
+			seq_printf(m, "      I/O at 0x%lx [0x%lx].\n",
+				base, end);
+		} else {
+			const char *pref, *type = "unknown";
+
+			if (flags & PCI_BASE_ADDRESS_MEM_PREFETCH)
+				pref = "P";
+			else
+				pref = "Non-p";
+			switch (flags & PCI_BASE_ADDRESS_MEM_TYPE_MASK) {
+			      case PCI_BASE_ADDRESS_MEM_TYPE_32:
+				type = "32 bit"; break;
+			      case PCI_BASE_ADDRESS_MEM_TYPE_1M:
+				type = "20 bit"; break;
+			      case PCI_BASE_ADDRESS_MEM_TYPE_64:
+				type = "64 bit"; break;
+			}
+			seq_printf(m, "      %srefetchable %s memory at "
+				       "0x%lx [0x%lx].\n", pref, type,
+				       base,
+				       end);
+		}
+	}
+	return 0;
+}
+
+static struct seq_operations proc_pci_op = {
+	.start	= pci_seq_start,
+	.next	= pci_seq_next,
+	.stop	= pci_seq_stop,
+	.show	= show_dev_config
+};
+
+static int proc_pci_open(struct inode *inode, struct file *file)
+{
+	return seq_open(file, &proc_pci_op);
+}
+static struct file_operations proc_pci_operations = {
+	.open		= proc_pci_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= seq_release,
+};
+
+
+static int __init pci_old_proc_init(void)
+{
+	struct proc_dir_entry * entry;
+	entry = create_proc_entry("pci", 0, NULL);
+	if (entry)
+		entry->proc_fops = &proc_pci_operations;
+	return 0;
+}
+
+module_init(pci_old_proc_init);
+
+#endif /* CONFIG_PCI_OLD_PROC */
===== drivers/pci/proc.c 1.21 vs edited =====
--- 1.21/drivers/pci/proc.c	Mon Nov 18 01:09:47 2002
+++ edited/drivers/pci/proc.c	Sat Dec  7 20:27:46 2002
@@ -473,106 +473,6 @@
 }
 
 
-/*
- *  Backward compatible /proc/pci interface.
- */
-
-/*
- * Convert some of the configuration space registers of the device at
- * address (bus,devfn) into a string (possibly several lines each).
- * The configuration string is stored starting at buf[len].  If the
- * string would exceed the size of the buffer (SIZE), 0 is returned.
- */
-static int show_dev_config(struct seq_file *m, void *v)
-{
-	struct list_head *p = v;
-	struct pci_dev *dev;
-	struct pci_driver *drv;
-	u32 class_rev;
-	unsigned char latency, min_gnt, max_lat, *class;
-	int reg;
-
-	if (p == &pci_devices) {
-		seq_puts(m, "PCI devices found:\n");
-		return 0;
-	}
-
-	dev = pci_dev_g(p);
-	drv = pci_dev_driver(dev);
-
-	pci_read_config_dword(dev, PCI_CLASS_REVISION, &class_rev);
-	pci_read_config_byte (dev, PCI_LATENCY_TIMER, &latency);
-	pci_read_config_byte (dev, PCI_MIN_GNT, &min_gnt);
-	pci_read_config_byte (dev, PCI_MAX_LAT, &max_lat);
-	seq_printf(m, "  Bus %2d, device %3d, function %2d:\n",
-	       dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
-	class = pci_class_name(class_rev >> 16);
-	if (class)
-		seq_printf(m, "    %s", class);
-	else
-		seq_printf(m, "    Class %04x", class_rev >> 16);
-	seq_printf(m, ": %s (rev %d).\n", dev->dev.name, class_rev & 0xff);
-
-	if (dev->irq)
-		seq_printf(m, "      IRQ %d.\n", dev->irq);
-
-	if (latency || min_gnt || max_lat) {
-		seq_printf(m, "      Master Capable.  ");
-		if (latency)
-			seq_printf(m, "Latency=%d.  ", latency);
-		else
-			seq_puts(m, "No bursts.  ");
-		if (min_gnt)
-			seq_printf(m, "Min Gnt=%d.", min_gnt);
-		if (max_lat)
-			seq_printf(m, "Max Lat=%d.", max_lat);
-		seq_putc(m, '\n');
-	}
-
-	for (reg = 0; reg < 6; reg++) {
-		struct resource *res = dev->resource + reg;
-		unsigned long base, end, flags;
-
-		base = res->start;
-		end = res->end;
-		flags = res->flags;
-		if (!end)
-			continue;
-
-		if (flags & PCI_BASE_ADDRESS_SPACE_IO) {
-			seq_printf(m, "      I/O at 0x%lx [0x%lx].\n",
-				base, end);
-		} else {
-			const char *pref, *type = "unknown";
-
-			if (flags & PCI_BASE_ADDRESS_MEM_PREFETCH)
-				pref = "P";
-			else
-				pref = "Non-p";
-			switch (flags & PCI_BASE_ADDRESS_MEM_TYPE_MASK) {
-			      case PCI_BASE_ADDRESS_MEM_TYPE_32:
-				type = "32 bit"; break;
-			      case PCI_BASE_ADDRESS_MEM_TYPE_1M:
-				type = "20 bit"; break;
-			      case PCI_BASE_ADDRESS_MEM_TYPE_64:
-				type = "64 bit"; break;
-			}
-			seq_printf(m, "      %srefetchable %s memory at "
-				       "0x%lx [0x%lx].\n", pref, type,
-				       base,
-				       end);
-		}
-	}
-	return 0;
-}
-
-static struct seq_operations proc_pci_op = {
-	.start	= pci_seq_start,
-	.next	= pci_seq_next,
-	.stop	= pci_seq_stop,
-	.show	= show_dev_config
-};
-
 static int proc_bus_pci_dev_open(struct inode *inode, struct file *file)
 {
 	return seq_open(file, &proc_bus_pci_devices_op);
@@ -583,16 +483,6 @@
 	.llseek		= seq_lseek,
 	.release	= seq_release,
 };
-static int proc_pci_open(struct inode *inode, struct file *file)
-{
-	return seq_open(file, &proc_pci_op);
-}
-static struct file_operations proc_pci_operations = {
-	.open		= proc_pci_open,
-	.read		= seq_read,
-	.llseek		= seq_lseek,
-	.release	= seq_release,
-};
 
 static int __init pci_proc_init(void)
 {
@@ -607,9 +497,6 @@
 		pci_for_each_dev(dev) {
 			pci_proc_attach_device(dev);
 		}
-		entry = create_proc_entry("pci", 0, NULL);
-		if (entry)
-			entry->proc_fops = &proc_pci_operations;
 	}
 	return 0;
 }

Re: /proc/pci deprecation?

[Linus Torvalds]

On Sat, 7 Dec 2002, Patrick Mochel wrote:
>
> > I don't know if lspci gets that right these days, and the information does
> > exist in /sys, so there is certainly at least the _potential_ of dropping
> > /proc/pci.
>
> It appears to:
>
> [mochel@tina mochel]$ lspci -v | grep -B 2  IRQ | fgrep -v Subsystem
>
> 00:07.4 USB Controller: Advanced Micro Devices [AMD] AMD-765 [Viper] USB (rev 07) (prog-if 10 [OHCI])
>         Flags: bus master, medium devsel, latency 16, IRQ 19

Just out of interest, where _does_ it get the information? Does it try to
do its own irq routing (bad!) or does it do it from /proc/bus/pci/devices?

		Linus

Re: /proc/pci deprecation?

[Richard Henderson]

On Sat, Dec 07, 2002 at 08:21:21PM -0800, Linus Torvalds wrote:
> >         Flags: bus master, medium devsel, latency 16, IRQ 19
> 
> Just out of interest, where _does_ it get the information? Does it try to
> do its own irq routing (bad!) or does it do it from /proc/bus/pci/devices?

It just reports what's in the PCI_INTERRUPT_LINE register.

At least on Alpha, we wrote into this register during pci
configuration, so the value matches what's in /proc/interrupts.
I guess I always assumed we did the same on x86, but I've
never checked.


r~

Re: /proc/pci deprecation?

[Linus Torvalds]

On Sun, 8 Dec 2002, Richard Henderson wrote:
>
> It just reports what's in the PCI_INTERRUPT_LINE register.

That's wrong, then.

> At least on Alpha, we wrote into this register during pci
> configuration, so the value matches what's in /proc/interrupts.
> I guess I always assumed we did the same on x86, but I've
> never checked.

It _shouldn't_ be done. The PCI_INTERRUPT_LINE register is just a byte,
which isn't even _enough_ to identify the irq "for real" on many
architectures. It's also a totally different namespace at least on x86
machines: the PCI_INTERRUPT_LINE register should contain the "legacy
interrupt", while the remapped interrupt will depend on whether the
io-apic is enabled or not.

Writing it back is actively _bad_, since it will make it very hard to
re-boot the machine without the BIOS re-enumarating the PCI bus and
filling it in again (ie it would definitely screw up using things like
kexec() on PC's, if the kernel we boot _from_ is an APIC kernel, but the
kernel we boot _into_ is not).

So the rule should be:
 - the PCI config space is _not_ the same as "pci->irq"
 - we should _never_ update the PCI_INTERRUPT_LINE register, because it
   destroys boot loader information (the same way we need to not overwrite
   BIOS extended areas and ACPI areas etc in order to be able to reboot
   cleanly)
 - we need _some_ way of getting the "kernel irq line" from /sys or /proc.

Sounds like /proc/pci still does something for us. Or is the info
available in /proc/bus/pci/devices?

		Linus

Re: /proc/pci deprecation?

[Patrick Mochel]

> > It just reports what's in the PCI_INTERRUPT_LINE register.
> 
> That's wrong, then.

Actually, it doesn't. IIUC, it gets it from /proc/bus/pci/devices. That 
info is formatted in drivers/pci/proc.c::show_device().

> > At least on Alpha, we wrote into this register during pci
> > configuration, so the value matches what's in /proc/interrupts.
> > I guess I always assumed we did the same on x86, but I've
> > never checked.
> 
> It _shouldn't_ be done. The PCI_INTERRUPT_LINE register is just a byte,
> which isn't even _enough_ to identify the irq "for real" on many
> architectures. It's also a totally different namespace at least on x86
> machines: the PCI_INTERRUPT_LINE register should contain the "legacy
> interrupt", while the remapped interrupt will depend on whether the
> io-apic is enabled or not.
> 
> Writing it back is actively _bad_, since it will make it very hard to
> re-boot the machine without the BIOS re-enumarating the PCI bus and
> filling it in again (ie it would definitely screw up using things like
> kexec() on PC's, if the kernel we boot _from_ is an APIC kernel, but the
> kernel we boot _into_ is not).

I couldn't find any place that ia32 writes the PCI_INTERRUPT_LINE register 
during boot. And, manually reading in various places (before, during, and 
after enabling a device) always returned the same info. 

> So the rule should be:
>  - the PCI config space is _not_ the same as "pci->irq"
>  - we should _never_ update the PCI_INTERRUPT_LINE register, because it
>    destroys boot loader information (the same way we need to not overwrite
>    BIOS extended areas and ACPI areas etc in order to be able to reboot
>    cleanly)
>  - we need _some_ way of getting the "kernel irq line" from /sys or /proc.
> 
> Sounds like /proc/pci still does something for us. Or is the info
> available in /proc/bus/pci/devices?

AFAICT, lspci is getting it from /proc/bus/pci/devices. I'm getting the 
source now to sift through and verify. Alternatively, the data is also 
available in the 'irq' file in each PCI device's sysfs directory. 

	-pat

kernel isapnp (2.4.20)

[h-peter recktenwald]

kernel 2.4.20 inbuilt isapp returns false data:
-----------------------------------------------
from /var/log/messages
sb creative 'vibra16', 

1) non-functional with isapnp by kernel:

kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
kernel: sb: Creative ViBRA16X PnP detected
Dec  2 18:16:57 Lux3 kernel: sb: ISAPnP reports 'Creative ViBRA16X PnP' at 
i/o 0x220, irq 10, dma 1, 3
kernel: SB 4.16 detected OK (220)
kernel: SB16: Bad or missing 16 bit DMA channel
Dec  2 18:16:57 Lux3 kernel: sb: 1 Soundblaster PnP card(s) found.
------------------------------------------------

2) all but /dev/sndstat (which worked w. 2.4.19, same set-up) 
if kernel-isapnp disabled and, configured after <pnpdump> otput:

kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
kernel: SB 4.16 detected OK (220)
kernel: <Sound Blaster 16 (4.16)> at 0x220 irq 7 dma 1,5
kernel: <Sound Blaster 16> at 0x330 irq 7 dma 0,0
kernel: YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft 
1993-1996
kernel: <Yamaha OPL3> at 0x388
kernel: MIDI Loopback device driver

# -----------------------------------

system, <ver_linux>:
 ---
Linux Lux3 2.4.20 #2 Sat Dec 7 09:50:48 GMT 2002 i586 unknown
 ---
C compiler             2.95.4
make                   3.79.1
binutils               20020814
util-linux             v2.11n
mount                  2.11n
modutils               2.4.15
e2fsprogs              1.27
ppp                    2.4.1
isdn4k-utils           3.1pre4
C library              2.2.5
dynamic linker (ldd)   2.2.5
procps                 2.0.7
net-tools              1.60
console-tools          0.2.3
sh-utils               2.0.11
modules                isdn_bsdcomp hisax isdn ipchains bridge romfs nls_utf8 
nls_koi8-u nls_koi8-ru nls_koi8-r nls_iso8859-7 nls_iso8859-5 nls_iso8859-4 
nls_iso8859-15 nls_iso8859-14 nls_iso8859-13 nls_iso8859-1 nls_gb2312 
nls_cp936 nls_cp866 nls_cp865 nls_cp864 nls_cp855 nls_cp852 nls_cp850 
nls_cp775 nls_cp437 nls_cp1251 nls_cp1250 nls_cp950 nls_big5 minix autofs acm 
usbcore v_midi opl3 sb sb_lib uart401 sound soundcore 8139too mii nbd

# -----------------------------------

statistics (after pnpdump config, only):

cat /dev/sndstat:
-----------------
	-/-

cat /proc/modules:
------------------
isdn_bsdcomp            5888   0
hisax                 131104  29 (autoclean)
isdn                  115200  30 (autoclean) [isdn_bsdcomp hisax]
ipchains               35876   0 (unused)
bridge                 15308   0 (unused)
romfs                   3584   0 (unused)
nls_utf8                 800   0 (unused)
    ...(more lang. mods)
nls_koi8-u              3872   1 (autoclean)
nls_iso8859-13          3392   0 (unused)
nls_iso8859-1           2880   2
minix                  18176   0 (unused)
autofs                  8932   0 (unused)
acm                     5024   0 (unused)
usbcore                53536   0 [acm]
v_midi                  4992   0 (unused)
opl3                   10792   0 (unused)
sb                      1792   0
sb_lib                 32288   0 [sb]
uart401                 6048   0 [sb_lib]
sound                  52588   0 [v_midi opl3 sb_lib uart401]
soundcore               3460   7 [sb_lib sound]
8139too                13376   1
mii                     2224   0 [8139too]
nbd                    14944   0 (unused)

cat /proc/interrupts:
---------------------
           CPU0       
  0:   44823924          XT-PIC  timer
  1:    1045591          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  4:    5026848          XT-PIC  HiSax
  7:        350          XT-PIC  soundblaster
  8:          3          XT-PIC  rtc
 10:          0          XT-PIC  eth0
 12:    3054844          XT-PIC  PS/2 Mouse
 14:     147687          XT-PIC  ide0
 15:    1403251          XT-PIC  ide1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

cat /proc/ioports:
------------------
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0220-022f : soundblaster
0240-0240 : HiSax hscx A fifo
02f8-02ff : serial(set)
0330-0333 : MPU-401 UART
0376-0376 : ide1
0378-037a : parport0
0388-038b : Yamaha OPL3
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
0640-065f : HiSax hscx A
0a40-0a40 : HiSax hscx B fifo
0cf8-0cff : PCI conf1
0e40-0e5f : HiSax hscx B
1240-1240 : HiSax isac fifo
1640-165f : HiSax isac
1a40-1a47 : avm cfg
5c20-5c3f : Acer Laboratories Inc. [ALi] M7101 PMU
d400-d40f : Acer Laboratories Inc. [ALi] M5229 IDE
  d400-d407 : ide0
  d408-d40f : ide1
d800-d8ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
  d800-d8ff : 8139too

cat /proc/dma:
 1: SoundBlaster8
 4: cascade
 5: SoundBlaster16

Re: /proc/pci deprecation?

[Ivan Kokshaysky]

On Sun, Dec 08, 2002 at 05:54:16PM -0800, Linus Torvalds wrote:
> Writing it back is actively _bad_, since it will make it very hard to
> re-boot the machine without the BIOS re-enumarating the PCI bus and
> filling it in again (ie it would definitely screw up using things like
> kexec() on PC's, if the kernel we boot _from_ is an APIC kernel, but the
> kernel we boot _into_ is not).

True. This applies to alpha as well because of the way how modern consoles
encode IRQs routed through the ISA bridge (actual IRQ + 0xe0).

Probably we should eliminate pcibios_update_irq() call in
drivers/pci/setup-irq.c and see what happens. Nothing bad, I guess.

Ivan.

Re: /proc/pci deprecation?

[Alan Cox]

On Mon, 2002-12-09 at 01:54, Linus Torvalds wrote:
>  - we should _never_ update the PCI_INTERRUPT_LINE register, because it
>    destroys boot loader information (the same way we need to not overwrite
>    BIOS extended areas and ACPI areas etc in order to be able to reboot
>    cleanly)

I wonder if this is why we have all these problems with VIA chipset
interrupt handling. According to VIA docs they _do_ use
PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"

Alan

Re: /proc/pci deprecation?

[Linus Torvalds]

On 9 Dec 2002, Alan Cox wrote:
>
> I wonder if this is why we have all these problems with VIA chipset
> interrupt handling. According to VIA docs they _do_ use
> PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
> between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"

Whee.. That sounds like a load of crock in the first place, since the
PCI_INTERRUPT_LINE thing should be just a scratch register as far as I
know. However, it doesn't really matter - we definitely should never write
to it anyway, so the VIA behaviour while strange should still be
acceptable.

Anyway, to get back on the original discussion, I think we should remove
the writing, and then make sure that /sbin/lspci (or some other tool) can
be made to easily show either the kernel irq mapping value _or_ the
"original PCI config space" value. At that point I'd agree that /proc/pci
has outlived its usefulness.

(Although I still think the name database is nice to have - I certainly
prefer it over having a lot of drivers having their _own_ name databases
for printout purposes).

		Linus

Re: /proc/pci deprecation?

[Alan Cox]

On Mon, 2002-12-09 at 17:00, Linus Torvalds wrote:
> On 9 Dec 2002, Alan Cox wrote:
> > I wonder if this is why we have all these problems with VIA chipset
> > interrupt handling. According to VIA docs they _do_ use
> > PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
> > between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"
> 
> Whee.. That sounds like a load of crock in the first place, since the
> PCI_INTERRUPT_LINE thing should be just a scratch register as far as I
> know. However, it doesn't really matter - we definitely should never write
> to it anyway, so the VIA behaviour while strange should still be
> acceptable.

Tested and verified. If I leave it alone non apic mode works. To use
APIC mode I have to write the new IRQ value into that register. I've
shoved that into the driver for now, since its a demented chip specific
horror.

Re: /proc/pci deprecation?

[Linus Torvalds]

On 9 Dec 2002, Alan Cox wrote:
>
> Tested and verified. If I leave it alone non apic mode works. To use
> APIC mode I have to write the new IRQ value into that register. I've
> shoved that into the driver for now, since its a demented chip specific
> horror.

That's definitely where it should be - the behaviour of the
PCI_INTERRUPT_LINE register is clearly chip-specific, so it should be in
the chip-specific drivers..

It's a kind of strange behaviour, though. What chip is this? It sounds
kind of convenient, but as far as I can tell it can only work for those
kinds of PCI devices that are on the same chip as the irq controller..

		Linus

Re: /proc/pci deprecation?

[Jeff Garzik]

On Mon, Dec 09, 2002 at 10:11:39AM -0800, Linus Torvalds wrote:
> 
> On 9 Dec 2002, Alan Cox wrote:
> >
> > Tested and verified. If I leave it alone non apic mode works. To use
> > APIC mode I have to write the new IRQ value into that register. I've
> > shoved that into the driver for now, since its a demented chip specific
> > horror.
> 
> That's definitely where it should be - the behaviour of the
> PCI_INTERRUPT_LINE register is clearly chip-specific, so it should be in
> the chip-specific drivers..
> 
> It's a kind of strange behaviour, though. What chip is this? It sounds
> kind of convenient, but as far as I can tell it can only work for those
> kinds of PCI devices that are on the same chip as the irq controller..

As a reminder of ancient times, one of the reasons I wanted to do
per-PCI-device interrupt routing was due to the older incarnation of
these chips, the Via 686 a/b southbridges.  They have a similar method
of routing interrupts, where writing to PCI_INTERRUPT_LINE directly
makes internal chip magic occur.  So you are correct WRT
"only work ... on the same chip as the irq controller"

	Jeff

Re: /proc/pci deprecation?

[Alan Cox]

On Mon, 2002-12-09 at 18:11, Linus Torvalds wrote:
> That's definitely where it should be - the behaviour of the
> PCI_INTERRUPT_LINE register is clearly chip-specific, so it should be in
> the chip-specific drivers..
> 
> It's a kind of strange behaviour, though. What chip is this? It sounds
> kind of convenient, but as far as I can tell it can only work for those
> kinds of PCI devices that are on the same chip as the irq controller..

VIA bridges. In my case its a CLE266 (onchip video, 5.1 audio, ide, usb,
firewire, ethernet, floppy, serial, irda. parallel...) [See why I don't
want to hack each driver 8)]

Re: /proc/pci deprecation?

[Linus Torvalds]

On 10 Dec 2002, Alan Cox wrote:

> On Mon, 2002-12-09 at 18:11, Linus Torvalds wrote:
> > That's definitely where it should be - the behaviour of the
> > PCI_INTERRUPT_LINE register is clearly chip-specific, so it should be in
> > the chip-specific drivers..
> >
> > It's a kind of strange behaviour, though. What chip is this? It sounds
> > kind of convenient, but as far as I can tell it can only work for those
> > kinds of PCI devices that are on the same chip as the irq controller..
>
> VIA bridges. In my case its a CLE266 (onchip video, 5.1 audio, ide, usb,
> firewire, ethernet, floppy, serial, irda. parallel...) [See why I don't
> want to hack each driver 8)]

Oh, I didn't mean each sub-chip driver, I meant the "southbridge driver".
Right now that's really only the PIRQ table mini-driver (all ten lines of
it ;)

Sadly, we do _not_ have a really good generic model for setting interrupt
lines. The PIRQ stuff comes closest to a driver model, but it gets
disabled by the MP table parsing, and then we don't have anything good to
fall back on, I'm afraid.

			Linus

Re: /proc/pci deprecation?

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Mon, 2002-12-09 at 17:00, Linus Torvalds wrote:
> > On 9 Dec 2002, Alan Cox wrote:
> > > I wonder if this is why we have all these problems with VIA chipset
> > > interrupt handling. According to VIA docs they _do_ use
> > > PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
> > > between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"
> > 
> > Whee.. That sounds like a load of crock in the first place, since the
> > PCI_INTERRUPT_LINE thing should be just a scratch register as far as I
> > know. However, it doesn't really matter - we definitely should never write
> > to it anyway, so the VIA behaviour while strange should still be
> > acceptable.
> 
> Tested and verified. If I leave it alone non apic mode works. To use
> APIC mode I have to write the new IRQ value into that register. I've
> shoved that into the driver for now, since its a demented chip specific
> horror.

Think you can put in a reboot notifier/device shutdown method to restore
it to it's old value, so kexec has a chance of working correctly with
this hardware.


Eric

Re: /proc/pci deprecation?

[Vojtech Pavlik]

On Mon, Dec 09, 2002 at 09:00:44AM -0800, Linus Torvalds wrote:

> On 9 Dec 2002, Alan Cox wrote:
> >
> > I wonder if this is why we have all these problems with VIA chipset
> > interrupt handling. According to VIA docs they _do_ use
> > PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing
> > between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"
> 
> Whee.. That sounds like a load of crock in the first place, since the
> PCI_INTERRUPT_LINE thing should be just a scratch register as far as I
> know. However, it doesn't really matter - we definitely should never write
> to it anyway, so the VIA behaviour while strange should still be
> acceptable.

I can confirm that on most builtin VIA southbridge devices (namely USB)
the register isn't just a scratch register and that indeed it is used by
the interrupt router.

> Anyway, to get back on the original discussion, I think we should remove
> the writing, and then make sure that /sbin/lspci (or some other tool) can

I guess only the irq re-routing code specific to VIA would then write
those values, because it has to if the BIOS didn't set them up correctly.

> be made to easily show either the kernel irq mapping value _or_ the
> "original PCI config space" value. At that point I'd agree that /proc/pci
> has outlived its usefulness.
> 
> (Although I still think the name database is nice to have - I certainly
> prefer it over having a lot of drivers having their _own_ name databases
> for printout purposes).

It definitely made many drivers simpler.

-- 
Vojtech Pavlik
SuSE Labs

Re: /proc/pci deprecation?

[Alan Cox]

A PS to this btw reading over the code - currently it seems to write it
with our IRQ data if we do a suspend/resume but not initially. If so we
have an inconsistency to resolve

Re: /proc/pci deprecation?

[Martin Mares]

Hi Linus!

> Just out of interest, where _does_ it get the information? Does it try to
> do its own irq routing (bad!) or does it do it from /proc/bus/pci/devices?

The latter (unless you use `lspci -b' which reads the config registers
directly) and it's doing it this way since the first version ;)

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Anything is good and useful if it's made of chocolate.

Re: /proc/pci deprecation?

[Erik Hensema]

Petr Vandrovec (VANDROVE@vc.cvut.cz) wrote:
> On  6 Dec 02 at 16:13, Patrick Mochel wrote:
>> 
>> > IIRC it was one of (a) deprecated, (b) removed, or (c) almost removed in
>> > the past, and Linus un-deprecated it.  The logic back then was that it
>> > provides a quick summary of a lot of useful info, a la /proc/cpuinfo and
>> > /proc/meminfo.  i.e. you don't need lspci installed, just been /bin/cat.
>> 
>> Ok, I can see that. But, are there really many systems that do not come with
>> lspci(8) pre-installed? I would expect that most distributions do; at least
>> the one I use does..
>> 
>> But, look the usage model. Who queries PCI information from the system? I
>> would argue a) developers, b) power users, and c) users hitting a bug. 
> 
> It is invaluable during installation, when no lspci is installed yet.
> I know that I need e100/eepro100 for 
> 'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not
> have even slightest idea what device 8086:2449 is, whether USB or NIC or
> VGA or some bridge.

Every half-decent installer autodetects all PCI devices. AND had lspci
installed in the install image.

> Next problem is that some drivers want to print "user readable" hardware
> name to user, and although some have its own name database (e100), some
> use name from pcidev...

Ugh :-/ That's a reason to keep it around then.

>> > I do grant you it would make various __init sections and in-memory 
>> > structures smaller if we eliminated the names...   do we want to?  Sure we
>> > have lseisa and lspci and lsusb, et. al.  Does that obviate the need for a
>> > simple summary of attached hardware?
>> 
>> IMO, yes, since those tools provide the summary, and exist almost purely in
>> userspace. I forgot to mention in the orginal email that we could also drop
>> the PCI names database, right? This would save a considerable amount in the
>> kernel image alone..
> 
> If you want, make it user configurable like it was during 2.2.x. But
> I personally prefer descriptive names and system overview I can parse 
> without having mounted /usr to get working lspci.

lspci should be installed in /sbin.

-- 
Erik Hensema (erik@hensema.net)

Re: /proc/pci deprecation?

[Dr. David Alan Gilbert]

* Erik Hensema (usenet@hensema.xs4all.nl) wrote:
> 
> Every half-decent installer autodetects all PCI devices. AND had lspci
> installed in the install image.

Yes, but wait till you find yourself stuck on a weird embedded board
with a small flash and a serial console and you are trying to debug the
PCI device you've built.

Sure in most cases you have lspci (and its friends); but why do people
want to deprecate a perfectly good tool that occasionally comes in
useful? (Make it a compile time option sure, remove it - no).

Dave
 ---------------- Have a happy GNU millennium! ----------------------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: /proc/pci deprecation?

[Arnaldo Carvalho de Melo]

Em Sat, Dec 07, 2002 at 01:15:59PM +0000, Dr. David Alan Gilbert escreveu:
> * Erik Hensema (usenet@hensema.xs4all.nl) wrote:
> > 
> > Every half-decent installer autodetects all PCI devices. AND had lspci
> > installed in the install image.
> 
> Yes, but wait till you find yourself stuck on a weird embedded board
> with a small flash and a serial console and you are trying to debug the
> PCI device you've built.

In this weird embedded board with small flash it'd be lovely to save one
more page (or perhaps more) in the kernel image, no? :-)
 
> Sure in most cases you have lspci (and its friends); but why do people
> want to deprecate a perfectly good tool that occasionally comes in
> useful? (Make it a compile time option sure, remove it - no).

See above. And as you said lspci mostly is available. Remove it or make
it a compile time option, please.

- Arnaldo

Re: /proc/pci deprecation?

[Rogier Wolff]

On Sat, Dec 07, 2002 at 03:46:58PM -0200, Arnaldo Carvalho de Melo wrote:
> Em Sat, Dec 07, 2002 at 01:15:59PM +0000, Dr. David Alan Gilbert escreveu:
> > * Erik Hensema (usenet@hensema.xs4all.nl) wrote:
> > > 
> > > Every half-decent installer autodetects all PCI devices. AND had lspci
> > > installed in the install image.
> > 
> > Yes, but wait till you find yourself stuck on a weird embedded board
> > with a small flash and a serial console and you are trying to debug the
> > PCI device you've built.
> 
> In this weird embedded board with small flash it'd be lovely to save one
> more page (or perhaps more) in the kernel image, no? :-)

Agreed. But -=*if*=- I want to. 

I would personally prefer to spend the page in the (compressed in flash!)
kernel image than the nine pages or so for "lspci" (possibly compressed
as well). 
 
	Roger.

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

Re: /proc/pci deprecation?

[Arnaldo Carvalho de Melo]

Em Mon, Dec 09, 2002 at 08:03:19PM +0100, Rogier Wolff escreveu:
> On Sat, Dec 07, 2002 at 03:46:58PM -0200, Arnaldo Carvalho de Melo wrote:
> > Em Sat, Dec 07, 2002 at 01:15:59PM +0000, Dr. David Alan Gilbert escreveu:
> > > * Erik Hensema (usenet@hensema.xs4all.nl) wrote:
> > > > 
> > > > Every half-decent installer autodetects all PCI devices. AND had lspci
> > > > installed in the install image.
> > > 
> > > Yes, but wait till you find yourself stuck on a weird embedded board
> > > with a small flash and a serial console and you are trying to debug the
> > > PCI device you've built.
> > 
> > In this weird embedded board with small flash it'd be lovely to save one
> > more page (or perhaps more) in the kernel image, no? :-)
> 
> Agreed. But -=*if*=- I want to. 
> 
> I would personally prefer to spend the page in the (compressed in flash!)
> kernel image than the nine pages or so for "lspci" (possibly compressed
> as well). 

wow, is lspci so bloated? 8) And I didn't objected to having it as a user
selectable option :-)

- Arnaldo

Re: /proc/pci deprecation?

[Tomas Szepe]

> > IMO, yes, since those tools provide the summary, and exist almost purely in
> > userspace. I forgot to mention in the orginal email that we could also drop
> > the PCI names database, right? This would save a considerable amount in the
> > kernel image alone..
> 
> If you want, make it user configurable like it was during 2.2.x. But
> I personally prefer descriptive names and system overview I can parse 
> without having mounted /usr to get working lspci.

Actually I'm inclined to insist that lspci belong in /sbin.  Really.  :)

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: /proc/pci deprecation?

[Petr Vandrovec]

On Sat, Dec 07, 2002 at 02:14:24PM +0100, Tomas Szepe wrote:
> > > IMO, yes, since those tools provide the summary, and exist almost purely in
> > > userspace. I forgot to mention in the orginal email that we could also drop
> > > the PCI names database, right? This would save a considerable amount in the
> > > kernel image alone..
> > 
> > If you want, make it user configurable like it was during 2.2.x. But
> > I personally prefer descriptive names and system overview I can parse 
> > without having mounted /usr to get working lspci.
> 
> Actually I'm inclined to insist that lspci belong in /sbin.  Really.  :)

Try it. At least on Debian it is useless without name database, which lives in
/usr/share/misc/pci.ids...  I can read numbers directly from /proc/bus/pci, if
I want numbers.
							Petr Vandrovec
							vandrove@vc.cvut.cz

Re: /proc/pci deprecation?

[Erik Hensema]

Petr Vandrovec (vandrove@vc.cvut.cz) wrote:
> On Sat, Dec 07, 2002 at 02:14:24PM +0100, Tomas Szepe wrote:
>> > > IMO, yes, since those tools provide the summary, and exist almost purely in
>> > > userspace. I forgot to mention in the orginal email that we could also drop
>> > > the PCI names database, right? This would save a considerable amount in the
>> > > kernel image alone..
>> > 
>> > If you want, make it user configurable like it was during 2.2.x. But
>> > I personally prefer descriptive names and system overview I can parse 
>> > without having mounted /usr to get working lspci.
>> 
>> Actually I'm inclined to insist that lspci belong in /sbin.  Really.  :)
> 
> Try it. At least on Debian it is useless without name database, which lives in
> /usr/share/misc/pci.ids...  I can read numbers directly from /proc/bus/pci, if
> I want numbers.

Hmmmm, on SuSE 8.0 too. I consider this a bug. Or at least a misfeature.
Binaries in /bin and /sbin should not need anything from /usr.

-- 
Erik Hensema <erik@hensema.net>

Re: /proc/pci deprecation?

[Geert Uytterhoeven]

On Sun, 8 Dec 2002, Erik Hensema wrote:
> Petr Vandrovec (vandrove@vc.cvut.cz) wrote:
> > On Sat, Dec 07, 2002 at 02:14:24PM +0100, Tomas Szepe wrote:
> >> > > IMO, yes, since those tools provide the summary, and exist almost purely in
> >> > > userspace. I forgot to mention in the orginal email that we could also drop
> >> > > the PCI names database, right? This would save a considerable amount in the
> >> > > kernel image alone..
> >> > 
> >> > If you want, make it user configurable like it was during 2.2.x. But
> >> > I personally prefer descriptive names and system overview I can parse 
> >> > without having mounted /usr to get working lspci.
> >> 
> >> Actually I'm inclined to insist that lspci belong in /sbin.  Really.  :)
> > 
> > Try it. At least on Debian it is useless without name database, which lives in
> > /usr/share/misc/pci.ids...  I can read numbers directly from /proc/bus/pci, if
> > I want numbers.
> 
> Hmmmm, on SuSE 8.0 too. I consider this a bug. Or at least a misfeature.
> Binaries in /bin and /sbin should not need anything from /usr.

Originally pci.ids was in /etc/.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: /proc/pci deprecation?

[Nicolas Mailhot]

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

[Please CC me replies as I'm not on the list ]

Hi

	When I added kt400 agp support recently (just a ID declaration since
generic via routines work fine on my box), I had to declare the KT400
pci id in gart. Which was the only thing really needed (or so I thought
in a sane world).

	Then I did the 2.4 patch. And guess what ? I found I had to declare it
in dri (two times, ie for each versions supported) and in the pci id
database. What kind of madness is it ? How many people do you expect to
update *four* lists with the same info (and btw the last time I checked
2.4 followups were not merged in 2.5) ?

	And all this time lspci knew my chip. In fact, I *used* lspci info to
get the right info to put in the kernel. And to this day since not
everything was merged in 2.5 lspci is more accurate than the kernel.

	So from my very naïve point of view /proc/pci wouldn't be mourned,
quite the contrary.

Regards,

-- 
Nicolas Mailhot

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: /proc/pci deprecation?

[Adam J. Richter]

Linus Torvalds wrote:
> - we should _never_ update the PCI_INTERRUPT_LINE register, because it
>   destroys boot loader information (the same way we need to not overwrite
>   BIOS extended areas and ACPI areas etc in order to be able to reboot
>   cleanly)

	I don't think the kernel presently does this, but if it
were to actually do the chipset-specific programming change the IRQ
routing of a device, it should update PCI_INTERRUPT_LINE precisely
so that the information will be passed on across a soft reboot.

	This comes up for me because I have daone motherobard with a
BIOS that never programs the USB controller's interrupt line, so I
have to do the chipset-specific bit twiddling (which, in this case
happens to be simply writing the desired irq into the device's
PCI_INTERRUPT_LINE register anyhow).  By the way, I also had to change
arch/i386/kernel/pci.c to get it to reread PCI_INTERRUPT_LINE if it
thought the interrupt was not routed, although all that I would really
need is some way for a user level program to persuade the kernel to
believe that a particular PCI device's interrupt line A has changed to
irq n.

	This exception is probably not relevant to what Linus and
Richard are discussing, but I thought should mention it, lest that
"_never_" be interpreted too absolutely.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

/proc/pci deprecation?

[Patrick Mochel]

ISTR /proc/pci being deprecated at one point in the past. It may have only
been discussed, though. In which case, is it possible to deprecate it?
lscpi(8) is considered a superior means to derive the same information.

Elimination of it would eliminate a chunk of code in drivers/pci/proc.c, 
and obviate the use of struct device::name by the PCI layer. This change 
would probably allow us to remove the name field altogether, since PCI is 
the only code that really relies on it (and only for /proc/pci AFAICT).

Is anything in userspace still relying on /proc/pci? 

	-pat

Re: /proc/pci deprecation?

[Jeff Garzik]

Patrick Mochel wrote:
> ISTR /proc/pci being deprecated at one point in the past. It may have only
> been discussed, though. In which case, is it possible to deprecate it?
> lscpi(8) is considered a superior means to derive the same information.
> 
> Elimination of it would eliminate a chunk of code in drivers/pci/proc.c, 
> and obviate the use of struct device::name by the PCI layer. This change 
> would probably allow us to remove the name field altogether, since PCI is 
> the only code that really relies on it (and only for /proc/pci AFAICT).


Historically, this was a Linus call :)

IIRC it was one of (a) deprecated, (b) removed, or (c) almost removed in 
the past, and Linus un-deprecated it.  The logic back then was that it 
provides a quick summary of a lot of useful info, a la /proc/cpuinfo and 
/proc/meminfo.  i.e. you don't need lspci installed, just been /bin/cat.

Personally, I think it would be nice to eliminate /proc/pci -- in favor 
of something that provides similar functionality from sysfs:  "cat 
/sys/all-busses" or somesuch.  I dunno how feasible that is.  The main 
idea is to list as many attached devices as possible in one go, without 
having to cat 40 different files :)  [unfortunately I think this means I 
am disagreeing with you ;)]

I do grant you it would make various __init sections and in-memory 
structures smaller if we eliminated the names...   do we want to?  Sure 
we have lseisa and lspci and lsusb, et. al.  Does that obviate the need 
for a simple summary of attached hardware?

	Jeff

Re: /proc/pci deprecation?

[Patrick Mochel]

On Fri, 6 Dec 2002, Jeff Garzik wrote:

> Patrick Mochel wrote:
> > ISTR /proc/pci being deprecated at one point in the past. It may have only
> > been discussed, though. In which case, is it possible to deprecate it?
> > lscpi(8) is considered a superior means to derive the same information.
> > 
> > Elimination of it would eliminate a chunk of code in drivers/pci/proc.c, 
> > and obviate the use of struct device::name by the PCI layer. This change 
> > would probably allow us to remove the name field altogether, since PCI is 
> > the only code that really relies on it (and only for /proc/pci AFAICT).
> 
> 
> Historically, this was a Linus call :)

Yeah, Randy said that about 30s before I got this. :)

> IIRC it was one of (a) deprecated, (b) removed, or (c) almost removed in 
> the past, and Linus un-deprecated it.  The logic back then was that it 
> provides a quick summary of a lot of useful info, a la /proc/cpuinfo and 
> /proc/meminfo.  i.e. you don't need lspci installed, just been /bin/cat.

Ok, I can see that. But, are there really many systems that do not come 
with lspci(8) pre-installed? I would expect that most distributions do; at 
least the one I use does..

But, look the usage model. Who queries PCI information from the system? I 
would argue a) developers, b) power users, and c) users hitting a bug. 

a) are going to use lspci, since it's much more powerful. b) may use 
either text format, but it's also likely they'll use a graphical tool. 
Looking at my gnome setup, I do not find anything that lists PCI devices 
(besides a file browser in sysfs :).  And, c) are most likely going to use 
lspci becaus a developer asks for it. I do not remember the last time I 
saw someone ask for the output of /proc/pci. :)

> Personally, I think it would be nice to eliminate /proc/pci -- in favor 
> of something that provides similar functionality from sysfs:  "cat 
> /sys/all-busses" or somesuch.  I dunno how feasible that is.  The main 
> idea is to list as many attached devices as possible in one go, without 
> having to cat 40 different files :)  [unfortunately I think this means I 
> am disagreeing with you ;)]

I totally agree with you. But, I don't think the answer is in 
consolidating files; I think it's in writing intelligent and efficient 
tools to grok that data. 

> I do grant you it would make various __init sections and in-memory 
> structures smaller if we eliminated the names...   do we want to?  Sure 
> we have lseisa and lspci and lsusb, et. al.  Does that obviate the need 
> for a simple summary of attached hardware?

IMO, yes, since those tools provide the summary, and exist almost purely 
in userspace. I forgot to mention in the orginal email that we could 
also drop the PCI names database, right? This would save a considerable 
amount in the kernel image alone..

	-pat

Re: /proc/pci deprecation?

[Krzysztof Halasa]

Patrick Mochel <mochel@osdl.org> writes:

> IMO, yes, since those tools provide the summary, and exist almost purely 
> in userspace. I forgot to mention in the orginal email that we could 
> also drop the PCI names database, right? This would save a considerable 
> amount in the kernel image alone..

I think so.

BTW: the /proc/pci doesn't show names of CardBus adapters, even if they're
inserted at boot time - cat /proc/pci | tail:

    VGA compatible controller: Silicon Motion, Inc. SM720 Lynx3DM (rev 177).
      IRQ 10.
      Master Capable.  Latency=64.  
      Non-prefetchable 32 bit memory at 0xf8000000 [0xfbffffff].
  Bus  2, device   0, function  0:
    Ethernet controller: PCI device 1011:0019 (rev 65).
      IRQ 10.
      Master Capable.  Latency=64.  Min Gnt=20.Max Lat=40.
      I/O at 0x4000 [0x407f].
      Non-prefetchable 32 bit memory at 0x10800000 [0x108003ff].
-- 
Krzysztof Halasa
Network Administrator

Re: /proc/pci deprecation?

[Kai Henningsen]

mochel@osdl.org (Patrick Mochel)  wrote on 06.12.02 in <Pine.LNX.4.33.0212061601550.1010-100000@localhost.localdomain>:

> But, look the usage model. Who queries PCI information from the system? I
> would argue a) developers, b) power users, and c) users hitting a bug.
>
> a) are going to use lspci, since it's much more powerful. b) may use
> either text format, but it's also likely they'll use a graphical tool.
> Looking at my gnome setup, I do not find anything that lists PCI devices
> (besides a file browser in sysfs :).  And, c) are most likely going to use
> lspci becaus a developer asks for it. I do not remember the last time I
> saw someone ask for the output of /proc/pci. :)

Hmm. Seems I am in neither group.

I use cat /proc/pci for the same reason I use cat /proc/scsi - when  
configuring a box, or adding new hardware, to figure out what I should  
look for and where it is.

I don't particularly care which part of the file system this omes from,  
but I do care about being able to find it quickly, and about it being easy  
(i.e. not need looking at 7868 separate files) and giving the essential  
info (which is the info that can be found in the relevant docs or be fed  
to google).

> I totally agree with you. But, I don't think the answer is in
> consolidating files; I think it's in writing intelligent and efficient
> tools to grok that data.

I seriously distrust tool-based solutions for this. It is far too likely  
that any new tool will be missing when I most need it, and old tools  
already aren't a particularly convincing solution.

I don't want to grovel through 7868 tools just as I don't want to grovel  
through 7868 files. And the more those are, the less likely I am to even  
have heard of them - from the lsXXX tools, the only one I knew about was  
lspci, and lsusb (which seems to be the other one actually installed)  
seems to be a lot more reluctant to give useful info to the non-USB- 
expert.

MfG Kai

Re: /proc/pci deprecation?

[Krzysztof Halasa]

kaih@khms.westfalen.de (Kai Henningsen) writes:

> I use cat /proc/pci for the same reason I use cat /proc/scsi - when  
> configuring a box, or adding new hardware, to figure out what I should  
> look for and where it is.

Still there is lspci. Much better than just a file in /proc, in fact:
you can have short or long output, and you always have device and
vendor names (with /proc/pci it isn't true).
As long as the database contains the names, of course (the same as with
kernel, with the difference that it doesn't use kernel space).

> I don't particularly care which part of the file system this omes from,  
> but I do care about being able to find it quickly, and about it being easy  
> (i.e. not need looking at 7868 separate files) and giving the essential  
> info (which is the info that can be found in the relevant docs or be fed  
> to google).

Same as "ps xaf". I usually don't look at /proc/*/cmdline etc either.
This doesn't mean I want a file in /proc which contains "ps axf" output.

Anyway, /proc/pci is currently broken (the kernel don't know what
hot-pluggable devices will you use, and doesn't preserve the necessary
names). If we want it in /proc, could it be corrected?


I always thought of /proc/pci as of temporary q&d debug tool.
-- 
Krzysztof Halasa
Network Administrator