Messages in this thread | | | Date | Tue, 31 Aug 1999 11:16:12 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: PATCH: PCI changes for pre-2.3.16-1 |
| |
On Tue, 31 Aug 1999, Martin Mares wrote: > > For "normal" purposes when we need to report information about > the device itself (as in /proc/ioports), we surely should use the > full name which contains only vendor and device. > > For "special" purposes like error messages printed by PCI > init code or by device probing in drivers, it's more important > to let the user know the bus and the slot, not the real name > of the device.
I agree.
However, the thing I object to is to saving that special string away, when the information exists there as-is. I really don't see the advantage of
printk("%s", dev->name);
over the much clearer
printk("%d:%d:%d", BUS(dev), SLOT(dev), FN(dev))
Sure, the latter is slightly longer, but at least it's obvious what it will actually print out - it's clear that now we're printing out the _position_ of the card rather than it's "name".
> Of course, we could reference the numbers stored in pci_dev > and format the slot name again and again in every message the > way we were doing it for years, but making the slot name available > in the pci_dev structure doesn't waste any considerable amount > of memory and makes life easier.
If you want to make life easier, just do a
char * pci_slot_fmt(struct pci_dev *dev) { static char fmt[10];
sprintf(fmt, "%d:%d:%d", BUS(dev), SLOT(dev), FN(dev)); return fmt; }
if it's the re-typing of the stuff you object to, and you just want to have one place to change when you want to change the way you print out devices. I'd certainly agree with that kind of thing.
And I'd even agree to caching the string if I thought it had some reason for it (performance, clarity, whatever), but as it stands I feel that calling it "name" just confuses the issue completely and brings no real advantage.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |