On Thu, Dec 08, 2005 at 02:09:32PM -0600, Mike Christie wrote: > James Bottomley wrote: > >On Thu, 2005-12-08 at 13:10 -0600, Mike Christie wrote: > > > >>cleanup. In the end some of the scsi people liked the idea of throwing > >>the non-read/write command to userspace and to do this we just decided > >>to start over but I have been cutting and pasting your code and cleaning > >>it up as I add more stuff. > > > > > >To be honest, I'd like to see all command processing at user level > >(including read/write ... for block devices, it shouldn't be that > >inefficient, since you're merely going to say remap an area from one > >device to another; as long as no data transformation ever occurs, the > >user never touches the data and it all remains in the kernel page > >cache). > > Ok, Tomo and I briefly talked about this when we saw Jeff's post about > doing block layer drivers in userspace on lkml. I think we were somewhat > prepared for this given some of your other replies. > > So Vlad and other target guys what do you think? Vlad are you going to > continue to maintain scst as kernel only, or is there some place we can > work together on this on - if your feelings are not hurt too much that > is :) ? Oofff....Architecturally I agree with James...do all command processing in one place. On the other hand, the processing involved with a read or write in the normal case (no aborts/resets/ordering/timeouts/etc) is almost zero. Figure out the LBA and length and pass on the I/O. The overhead of passing it up and down across the kernel boundary is likely to be orders of magnitude larger than the actual processing. I would personally rather not fix this decision in concrete until we could do some actual measurements of a SCSI target under heavy load. -- Dave Boutcher - : 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
