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

[Luben Tuikov <luben_tuikov@adaptec.com>]

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.

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

> 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 (http://libsdi.berlios.de).  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.

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

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

> buffers limited to page size, etc.

"You have an attribute larger than 4k?  What is it?"

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.

> 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 */

	Luben
-
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/