On 10/20/05 20:46, Jeff Garzik wrote: > Consider what an ioctl is, overall: a domain-specific "do this > operation" interface. Which, further, is nothing but a wrapping of a > "send message" + "receive response" interface. There are several ways > to do this in Linux: > > * block driver. a block driver is nothing but a message queue. This is Not quite. This maybe the way it operates, but it is called "block" for a reason. > why James has suggested implementing SMP as a block driver. People get > stuck into thinking "block driver == block device", which is wrong. The > Linux block layer is nothing but a message queueing interface. Now, just because James suggested implementing the SMP service as a block device you think this is the right thing to do? How about this: Why not as a char device? At least MS isn't suffering from the "no to specs" syndrome which the Linux community seems to be suffering... SMP as a Block device???? You need to see the history of SMP and its intended use. > * netlink. You connect to <an object> and send/receive messages. Not > strictly limited to networking, as this is used in some areas of the > kernel now for generic event delivery. This is very similar to the binary attr file "smp_portal" in drivers/scsi/sas/sas_expander.c, bottom of file. > * char driver. Poor man's netlink. Unless its done right, it suffers > from the same binary problems as ioctls. I don't recommend this path. > > * sysfs. This has no inherent message/queue properties by itself, and > is less structured than blockdrvr or netlink, so dealing with more than > one outstanding operation at a time requires some coding. Exactly! SMP. (binary attr file) Luben -- http://linux.adaptec.com/sas/ http://www.adaptec.com/sas/ - : 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
