Re: PATCH: PCI changes for pre-2.3.16-1

Linus Torvalds (torvalds@transmeta.com)
Tue, 31 Aug 1999 11:16:12 -0700 (PDT)


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/