[lkml]   [2005]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)
    On Mon, 2005-09-12 at 16:17 +1000, Douglas Gilbert wrote:
    > If we look at our (im)famous <h:c:i:l> addressing string,
    > the first 2 elements (i.e. "h:c") are about kernel device
    > addressing (i.e. which (part of a) HBA to be initiator); the
    > contentious "i" is about addressing the target and is
    > transport dependent, and the "l" is for addressing within
    > the target. Only the last element is true SCSI and is
    > defined in SAM (to be 64 bits, not 32). In iSCSI the "i"
    > is actually an adorned IP address.

    About the "i" problem, I've long agreed that we could do with an
    arbitrary string or other method there. There is a description of how
    to do it, it's just rather involved since the idea of "i" being a small
    number threads through a large amount of driver code making backward
    compatibility a bit of a nightmare.

    The "l" issue should be primarily solved with the scsilun_to_int and
    int_to_scsilun functions. OK, horribly named, but they now mean that
    the internal mid-layer representation (a 32 bit int currently) is
    abstracted from the structure the drivers use on the wire so we should
    be free to increase it if necessary. Note: you do actually need either
    an array with more than two levels of nesting actually to need the
    increase and no-one actually seems to have one of these yet.

    > So the kernel "discovers" at the "h:c" level at powerup
    > (and at runtime with hotplug events); leaving the SCSI
    > subsystem to do discovery at the "i" and the "l" level.
    > At this point I would like to make an observation: there
    > is no absolute requirement for the SCSI subsystem to do
    > discovery at either the "i" or the "l" levels. Using SAS

    Right, but we've already moved away from that if you use the correct
    APIs. The fc transports (those that attach to the transport class,
    anyway) no longer use the mid-layer provided sequential scan. They
    simply add targets that the fibre discovers from the log in process.
    Essentially this means that the class/driver co-operate on discover and
    only use the mid-layer for LUN detection once they report the existence
    of a target.

    > as an example, only the SAS (target port) address and
    > a logical unit number (identifier) or name are needed.
    > So an embedded system which includes a SAS initiator (HBA)
    > could connect to an arbitrary device quickly and with
    > minimal impact on a large SAS fabric (i.e. no SAS target
    > discovery phase). As an extreme example, target discovery
    > in iSCSI cannot involve the whole internet (and even though
    > its topology would be interesting, representing it in sysfs
    > is absurd).

    > My major objection to Luben's SAS sysfs representation is
    > that "things" have to be discovered before the user space
    > can talk to them. Why?? An app in the user space might
    > _know_ that the "thing" (e.g. SAS expander or a "well
    > known" logical unit) is out there. Again the obvious comparison
    > is with IP addresses and the way the networking subsystem
    > functions. I would like to make HBA initiators (or their ports)
    > visible as interfaces (like eth0 and friends) through which
    > commands/frames/primitives can be sent and events received.

    This one, I actually agree with. Most users have small domains which
    will be easily amenable to total enumeration. The other issue is that
    if we go with a socket like approach where the user has to connect to
    the devices, then we lose hotplug ... a true network doesn't know or
    care when another PC is plugged into it.

    For things like iscsi, we do have the compromise that discovery doesn't
    begin until the endpoint is known.

    If we go like net and have the whole world as our potential but non-
    discovered domain, we have to begin addressing security issues that
    arise because of the parts of the domain that we don't control ... I'd
    much rather leave these sort of issues to the net people and begin with
    the a priori assumption that a scsi domain, although it might be bridged
    across the hostile network, represents a fundamentally secure and
    discoverable system.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-09-12 17:09    [W:0.039 / U:7.536 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site