lkml.org 
[lkml]   [2001]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] adding PCI bus information to SCSI layer
    Jonathan Lundell writes:
    > 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

    Nope. Linus hates the idea of "compressed" names. He wants them to be
    obvious at first glance. My original devfs patch (before it went into
    the kernel) had compressed names, and he made me change them (there
    were other changes as well). I know it's a bit much to type in, but
    he's probably right. If people need it, I can add compressed names to
    devfsd, just like I did to preserve the names in the original devfs
    patch.

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

    Nope. It's cleaner to do this in a vendor-specific "fixup" layer. Alan
    asked me a similar question privately, so I've included my reponse to
    his email (quoting bits of his email for context) below. In his reply,
    Alan said "it makes sense". I take that as a good omen.
    =========
    > How do you intend to handle pci busses that are below other busses - eg gsc
    > /dev/bus/gsc/bus/pci0/ .. ?
    > Im just thinking it gets very cumbersome.

    It could. And if you play with the upcoming SGI IA-64 boxes, where
    they have a deep /dev/hw, it would appear even more so. However, I
    came up with a scheme while I was visiting them after the workshop,
    which I believe will handle an arbitrarily complex vendor tree. I'm
    actually quite proud of this idea :-)

    The basic idea is that /dev/bus contains a *logical* enumeration of
    all busses in the system. This contains the generic Linux view of
    busses. We already have this enumeration within struct pci_dev and
    friends.

    Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0
    into symlinks to something like /dev/hw/PBrick/00AA3415/bus1/pci3 (or
    similar, I forget just how deep SGI's tree went).

    This scheme is really just an extension of the approach Linus took in
    the Great Name Change he forced upon me a year and a half ago. Back
    then, he wanted /dev/discs to answer the question "what discs do I
    have", and "/dev/scsi" to answer "what SCSI devices do I have, and
    what's the layout". So now, I'm adding "/dev/bus" for "what logical
    busses do I have" and "/dev/hw" for "what is the exact hardware
    topology".

    Where we have "generic" hardware (i.e. a vendor doesn't provide their
    own PCI fixups), and there is a need to show the bus topology, we can
    write generic fixups that parse the struct pci_dev and friends. For
    example, most x86 machines would fall in this "generic" category.

    Regards,

    Richard....
    Permanent: rgooch@atnf.csiro.au
    Current: rgooch@ras.ucalgary.ca
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 12:52    [W:0.023 / U:30.576 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site