On Sat, Mar 15, 2008 at 06:48:03PM -0400, Jeff Garzik wrote:
> You arrived at the proper conclusion -- it doesn't happen in practice
> for a variety of reasons, the main one being that it's largely in the
> realm of something the superuser must do intentionally, the way kernel
> and userland code is written today.
I think it could easily happen accidentally. In any case, it's worth
fxing.
> Thus, the code intentionally avoids the silly complexity for a case that
> never truly happens outside of synthetic superuser experiments.
>
> Remember, this and all the other code originated in the days of "if
> (use_sg)", when scatterlists were not used often for !(read|write) commands.
I have no desire to increase the complexity of libata, but I think it's
possible to fix this in a couple of different ways without adding extra
complexity.
One possible way would be for simulate to allocate a page and pass that
into the actor functions to fill in. Then simulate could copy that page
into the sg lists. This doesn't fix my problem where I need to
part-simulate, part-translate, but it's a possible solution for all the
various inquiries.
Another would be for the actor functions to set up their own buffers and
call something similar to the copy_buffer() function I had as part of
the scsi_ram driver I wrote. I happened to write it for the use of
INQUIRY too ;-)
+static void copy_buffer(struct scsi_cmnd *cmnd, char *buf, int len)
+{
+ char *p;
+ struct scatterlist *sg;
+ int i;
+
+ scsi_for_each_sg(cmnd, sg, scsi_sg_count(cmnd), i) {
+ int tocopy = sg->length;
+ if (tocopy > len)
+ tocopy = len;
+
+ p = kmap_atomic(sg_page(sg), KM_USER0);
+ memcpy(p + sg->offset, buf, tocopy);
+ kunmap_atomic(p, KM_USER0);
+
+ len -= tocopy;
+ if (!len)
+ break;
+ buf += tocopy;
+ }
+
+ scsi_set_resid(cmnd, len);
+}
> P.S. I encourage others to investigate making the libata SCSI simulator
> an optional kernel module.
>
> Long term, a preferred solution would be to use SCSI layer for ATAPI
> devices, and a kernel block device for ATA devices.
I think that's the right method to take, though we probably still want
to emulate the scsi ioctls.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
