On Thu, 2010-08-19 at 16:23 +1000, Mark Harvey wrote: > On Thu, Aug 19, 2010 at 11:01 AM, Nicholas A. Bellinger > > So the main difference from the perspective of a userspace space app is > > going from using include/scsi/sg.h:struct sg_io_hdr to using > > include/linux/bsg.h:struct sg_io_v4. On modern kernel code, under the > > hood in the kernel both drivers/scsi/sg.c and block/bsg.c use struct > > request based I/O via blk_get_request() to obtain a struct request, and > > blk_execute_rq_nowait() to asychronously queue the I/O to the underlying > > backstore. > > > > BSG exposes more raw functionality (but certaily not all) of the modern > > Linux Block layer code. This includes the ability to do BIDI commands > > and support for legacy SG_IO ioctls in block/bsg.c:bsg_ioctl(). > > > > Note that not all of the the structure members in struct sg_io_v4 can > > safely be used with current mainline code. For example, having a 32-bit > > userspace passing up 32-bit pointers currently need a patch to require > > proper conversion to 64-bit struct scatterlist memory. The first half > > of this patch is here: > > > > http://groups.google.com/group/linux-iscsi-target-dev/browse_thread/thread/6b9f8a08f78067dc/6330a5897203854a?lnk=gst&q=BSG#6330a5897203854a > > > > This issue came up again between Tomo-san and myself last week, and we > > agreed that the patch to make 32-bit user + 64-bit kernel work with BSG > > scatterlists would not be pretty, but that it does need to be fixed in > > order to properly support the QEMU-KVM SCSI-BSG MegaSAS SGL passthrough. > > This is the code that has been being going in parallel with the recent > > multi-fabric TCM_Loop Virtual SCSI LLD develpments for STGT, which can > > be found here to give more of an idea how BSG functions. > > > > http://git.kernel.org/?p=virt/kvm/nab/qemu-kvm.git;a=blob;f=hw/scsi-bsg.c;hb=refs/heads/scsi-bsg > > > > Best, > > > > --nab > > OK, I'm having some problems with 1.0.7 build attempting to configure > a bsg device. > OS is SLES 11 x86_64 > Linux mhvtl5 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 > x86_64 x86_64 x86_64 GNU/Linux > > # lsscsi -g > [3:0:1:0] tape IBM ULT3580-TD5 550V /dev/st0 /dev/sg2 > > # ls -l /dev/bsg/ > total 0 > crw-rw---- 1 root root 253, 0 2010-08-15 13:15 0:0:0:0 > crw-rw---- 1 root root 253, 1 2010-08-15 13:15 2:0:0:0 > crw-rw---- 1 root root 253, 10 2010-08-17 12:02 3:0:0:0 > crw-rw---- 1 root root 253, 2 2010-08-17 12:02 3:0:1:0 > crw-rw---- 1 root root 253, 7 2010-08-17 12:02 3:0:10:0 > crw-rw---- 1 root root 253, 8 2010-08-17 12:02 3:0:11:0 > crw-rw---- 1 root root 253, 9 2010-08-17 12:02 3:0:12:0 > crw-rw---- 1 root root 253, 3 2010-08-17 12:02 3:0:2:0 > crw-rw---- 1 root root 253, 4 2010-08-17 12:02 3:0:3:0 > crw-rw---- 1 root root 253, 5 2010-08-17 12:02 3:0:4:0 > crw-rw---- 1 root root 253, 11 2010-08-17 12:02 3:0:8:0 > crw-rw---- 1 root root 253, 6 2010-08-17 12:02 3:0:9:0 > > # tgtadm --op new --mode target --tid 1 -T iqn.2010-08.com.nbusyd:mh > # tgtadm --op new --mode logicalunit --tid 1 --lun 1 --bstype=bsg > --device-type=pt -b /dev/bsg/3:0:1:0 > tgtadm: invalid request > > All the syslog shows is: > tgtd: bs_sg_open(361) Not recognized /dev/bsg/3:0:1:0 as an SG device > Hmmmmm, so it appears that usr/bs_sg.c:chk_sg_device() is failing to pick up the BSG device nodes here: /* Check for SG_IO major first.. */ if (major(st.st_rdev) == SCSI_GENERIC_MAJOR) return 0; /* This is not yet defined in include/linux/major.h.. */ if (major(st.st_rdev) == 254) return 1; return -1; } So it looks like the failure is attributed to my hardcoding of major 254 in the original STGT/BSG patch (note the comment above the conditional check). Here is a quick fix: diff --git a/usr/bs_sg.c b/usr/bs_sg.c index cda5cd2..a369570 100644 --- a/usr/bs_sg.c +++ b/usr/bs_sg.c @@ -289,7 +289,7 @@ static int chk_sg_device(char *path) return 0; /* This is not yet defined in include/linux/major.h.. */ - if (major(st.st_rdev) == 254) + if ((major(st.st_rdev) == 254) || (major(st.st_rdev) == 253)) return 1; return -1; Best, --nab -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
