lkml.org 
[lkml]   [2005]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2.6.13 2/14] sas-class: README
    On 09/12/05 05:00, Douglas Gilbert wrote:
    > Luben Tuikov wrote:
    >
    > <snip>
    >
    >>+
    >>+DISCOVERY
    >>+---------
    >>+
    >>+The sysfs tree has the following purposes:
    >>+ a) It shows you the physical layout of the SAS domain at
    >>+ the current time, i.e. how the domain looks in the
    >>+ physical world right now.
    >>+ b) Shows some device parameters _at_discovery_time_.
    >>+
    >>+This is a link to the tree(1) program, very useful in
    >>+viewing the SAS domain:
    >>+ftp://mama.indstate.edu/linux/tree/
    >>+I expect user space applications to actually create a
    >>+graphical interface of this.
    >>+
    >>+That is, the sysfs domain tree doesn't show or keep state if
    >>+you e.g., change the meaning of the READY LED MEANING
    >>+setting, but it does show you the current connection status
    >>+of the domain device.
    >
    >
    > So in that case, user applications should ignore READY
    > LED MEANING in sysfs and ask the device directly.
    > For example:
    > sdparm --get RLM --transport sas /dev/sda

    Yes, correct. You and I have discussed this already.

    Excerpt from that same "README" file (just above the code
    you cut and pasted):

    The sysfs tree has the following purposes:
    a) It shows you the physical layout of the SAS domain at
    the current time, i.e. how the domain looks in the
    physical world right now.
    b) Shows some device parameters _at_discovery_time_.

    > ... and what about multiple initiators sitting on different
    > machines? Should they be responsible for:
    > 1) finding out about one another
    > 2) and keeping the sysfs tree in the other machine
    > in sync when one changes READY LED MEANING
    > (or anything else)?

    And how is this a problem of the Discover code?

    There is a way to handle more than one initiator on the domain
    doing discovery, but I didn't code it since _at_this_time_
    I doubt people would start doing this: they don't even
    have SAS hardware, a lot less two initiators on the same
    domain.

    > Putting distributed state information in sysfs and then
    > passing off the responsibility for maintaining its state
    > (because it is a difficult problem) brings into question
    > the wisdom of the strategy.

    No Doug, not true at all.

    Sorry that "sg" isn't going to be used to communicate with
    expanders, but this is just part of evolution.

    If I removed "ready_led_meaning" and a couple of other
    such entries: you would have NO argument.

    If I left only the directory entries representing the
    object and the "smp_portal" you argument falls apart.

    Instead, you should've been saying how easy and
    _elegant_ it is communicating with expanders on the
    domain:
    * open(2) the "smp_portal" in the expander
    directory you want to talk to,
    * write(2) the SMP frame you want to send,
    * read(2) the amount of information you
    expect to get,
    * close(2).

    Done! No addressing to figure out, no memory problems, etc.
    The easiest interface: read(2)/write(2), _and_ the simplest
    format to use: pure SMP frames, easy and straightforward.

    GUI programs would be able to use all this to give
    a GUI of the whole domain and then you can just point and
    click on an expander and get information using this simple
    and elegant interface.

    Sorry again "sg" wouldn't fit in here. It's just evolution.

    Luben
    P.S. I _did_ mention to you in private email that this is going
    to happen and you didn't reply at all.



    -
    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-09-12 20:42    [W:0.026 / U:29.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site