[lkml]   [2005]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    On Fri, 2005-09-30 at 15:21 -0400, Luben Tuikov wrote:
    > On 09/30/05 14:39, Andrew Patterson wrote:
    > >
    > > SDI is supposed to be a cross-platform spec, so mandating sysfs would
    > > not work.
    > True, sysfs is a Linux only thing.
    > But you can write a user space library which uses sysfs or whatever
    > _that_ OS uses to represent an SDI spec-ed out picture.

    Yes you can, which is what I am trying to do. However, is that library
    also available on Solaris and Windows? Is it up to date? These are the
    reasons why the spec authors rejected that approach. I don't agree with
    them BTW, but I do understand why they think that way.

    > So a user space program would call (uniformly across all OSs)
    > a libsdi library which will use whatever OS dependent way there is
    > to get the information (be it sysfs or ioctl).

    See the paragraph below.

    > > I suggested to the author to use a library like HPAAPI (used
    > > by Fibre channel), so you could hide OS implementation details. I am in
    > > fact working on such a beasty ( He thinks
    > > that library solutions tend to not work, because the library version is
    > > never in synch with the standard/LLDD's. Given Linux vendor lead-times,
    > > he does have a valid point.
    > Yes, but it would be the best of all the current ways there are
    > to do it.

    Theoretically yes. Practically, perhaps not. The authors seem to have
    been left with a bad taste in their mouths after their experience with
    HBA API. They agree that IOCTL are bad too do to lack of linux support,
    but do not have a better cross-platform solution as yet. The current
    way around this is to use CSMI and brow-beat various Linux vendors into
    allowing these IOCTL's into their kernels.

    > > Note that a sysfs implementation has problems. Binary attributes are
    > > discouraged/not-allowed.
    > I've never heard that. Is this similar to the argument
    > "The sysfs tree would be too deep?"

    >From Documentation/filesystes/sysfs.txt

    "Attributes should be ASCII text files, preferably with only one value
    per file. It is noted that it may not be efficient to contain only
    value per file, so it is socially acceptable to express an array of
    values of the same type.

    Mixing types, expressing multiple lines of data, and doing fancy
    formatting of data is heavily frowned upon. Doing these things may get
    you publically humiliated and your code rewritten without notice."

    My understanding is that sysfs is meant to be human-readable. I do not
    know if this is a hard and fast rule or just a convention. Configfs is
    probably a better fit at least for writeable attributes, but may not be
    cooked yet.

    > > There is no atomic request/response operations
    > For a reason: let user space do it, there is plenty of ways to
    > do it, some assisted by the kernel.

    User space locking can only guarantee atomic operations in user space.

    > > buffers limited to page size, etc.
    > "You have an attribute larger than 4k? What is it?"

    Not sure at the moment, can I guarantee this for the future?

    > As to SMP response/request is more than 4K/8K? The largest
    > I'm aware of is 64 bytes.
    > > Other alternatives are
    > > configfs, SG_IO, and the above mentioned character device. None are a
    > Again, char devices for controlling are discouraged. There are not enough
    > around and it is old technology.

    There are as many as one would want. We now have 32 bit device numbers.
    Old technology is fine as long as it works, especially if their is no
    new technology to replace it. Note that I don't like the character
    device solution either. What would really be nice is something that will
    allow us to pass an arbitrary request buffer, and get an arbitrary
    response buffer back in a single transaction, SG_IO comes closest, but
    shares request/response buffers and is limited to a 16-byte commands.
    It also requires a device file.

    > > complete replacement for the transactional nature of IOCTL's. A group
    > Here:
    > /* User space lock */
    > fd = open(smp_portal, ...);
    > write(fd, smp_req, smp_req_size);
    > read(fd, smp_resp, smp_resp_size);
    > close(fd);
    > /* User space unlock */

    See above. This stuff works for trivial user-space apps. It will not
    suffice for most storage management apps.


    > Luben

    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-30 22:17    [W:0.026 / U:11.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site