Sorry for the inconvenience. There are a lot of reasons why I believe
it's properly a display function to wrap long lines, and that an MUA
has no business altering outgoing messages (one on-topic reason being
that patches get screwed up by inserted newlines), but I grant that
there are broken clients out there that can't or won't or don't wrap
at display time.
On the subject of the Subject, Jeff Garzik recently (21 March)
suggested adding geographic information to the ethtool interface,
pci_dev->slot_name in the case of a PCI-based interface. There's
something to be said for having a uniform method of identifying the
location of devices, or at least a uniform parsable format. (A
potential shortcoming of Jeff's scheme, perhaps, is that it needs to
identify the slot_name as a PCI slot_name, though I could be missing
something there.)
Consider, instead of /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3
something like
/dev/bus/pci0d1f0/scsi0t1l2p3
or
/dev/bus/pci0:d1:f0/scsi0:t1:l2:p3
Are there systems with more than one PCI bus numbering domain? I
don't see why not, in principle (not an issue for SCSI, which doesn't
have bus numbering). So perhaps:
/dev/bus/pci0:b0:d1:f0/scsi0:t1:l2:p3
which distinguishes between PCI domains and PCI bus numbers.
At 10:31 PM -0600 2001-04-26, Richard Gooch wrote:
>Sure. I haven't made a decision on the names yet. I was just sketching
>out the idea.
It's a good idea. Just feedback on the initial sketch.
A related idea would be the ability to translate from a logical PCI
slot number, as above, and a physically meaningful description that
the user could use to identify an actual slot. Unfortunately the
proper place for such a translation function is in the
(hardware-specific) BIOS.
-- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/