Mike Christie wrote: >> Second: transport level i/o could be done like you suggest, and we've >> prototyped some of this as well. However, there's something very wrong >> about putting "block device" wrappers and settings around something that >> is not a block device. In general, it's a heck of a lot of overhead and >> still doesn't solve the real issue - how to portably pass that user >> buffer > > > I am not talking about putting block device wrappers. This the magic > part and the message passing comes in. A while back I made the requuest > queue a class (only sent the patch to Jens and did not follow up). The > original reason was for the io sched swap and some multipath stuff, but > since with then the request queue would need a block device to be > exposed to userspace through sysfs and would not need a block device to > send messages throgh. You just need a way to commniutate between > userspace and the kernel but it does not have to be through a block > device. I think this path has other benefits in that you could do > userspace level scanning as well since you do not need the block device > and ULD like we do today. > Again for a bad example look at the target code. The original idea was to use the request_queue for messages because it did not work so well for them to take target requests (we do not need the io scheduler for example) to send request from the target interrupt handler to the netink code. It was over kill becuase all we really want is a per cpu list, but we used the request queue becuase it had the queue limits that we needed. It was mean as temporary and I think tomo is working on replacing that with a per process list and softirq. But the point is that you can use the request queue to pass around requests and still use netlink for the interface between the kernel and userspace. - : 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
