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 - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
