Re: I request inclusion of SAS Transport Layer and AIC-94xx intothe kernel

[Luben Tuikov]

On 09/30/05 16:14, Andrew Patterson wrote:
> 
> 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

Is the kernel the latest one? Is it up to date?

See?  Same argument.

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

I see this talk _only_ about non-binary attributes.

Plus you have to admit: the SAS sysfs "smp_portal" binary
attribute is very versatile: you completely control the
expander from user space _if_ you can see it:  It is 
almost like "point and click".

I imagine there would be GUIs built on top of it, which would
actually implement that "point, click, control".

> My understanding is that sysfs is meant to be human-readable.  I do not

But `cat /sysfs/.../smp_portal` _is_ human readable.  See?  Its size is
0 bytes and when you read it you get 0 data read.

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

And user space is the whole audience of this interface.

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

How far in the future? 1, 3, 6 months?  1, 3, 6 years?
Plus if you need an attribute larger than 4K, you've got
other problems to worry about.

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

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.  

Sorry but I completely fail to see this argument.

How will it "fail for most storage managament apps"?

	Luben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/