On Thu, Aug 19, 2010 at 11:01 AM, Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> wrote: > On Thu, 2010-08-19 at 10:28 +1000, Mark Harvey wrote: >> On Thu, Aug 19, 2010 at 9:47 AM, Nicholas A. Bellinger >> <nab@xxxxxxxxxxxxxxx> wrote: >> > >> > Hmmm strange.. Checking on Fedora 11 (v2.6.30), RHEL6 B1 (v2.6.32), >> > OpenSuse 11.2 (v2.6.31), SLES 11 (v2.6.27), and Debian Lenny VMs >> > (v2.6.35 from lio-core-2.6.git/lio-4.0), and I do see the >> > proper /dev/bsg/H:C:T:L device nodes matching the available struct >> > scsi_device. >> > >> > However, I do recall one seing the BSG H:C:T:L device nodes appear >> > in /dev/ instead of /dev/bsg/ before. I don't recall on which >> > environment this was, but I think it may have been some version of >> > Ubuntu..? >> > >> > Just to double check on your system, a 'cat /proc/kallsyms | grep bsg' >> > produces symbols for the kernel built-in BSG kernel code, yes..? >> > >> > Best, >> > >> > --nab >> >> Many thanks for the pointers.. >> >> Found an SLES-11 VM with bsg.. I'll update the doc now I've got >> something to test. >> Also allow me to put in 'how to identify if your OS has bsg configured' :) >> > > :-) > >> Next Q. if I may. >> Do you / can anybody on this list offer a short (one liner?) summary >> of advantages of bsg over sg ? >> I'll now hit google with the Q too.. >> > > 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 An attempt to use the 'sg' type works fine: # tgtadm --op new --mode logicalunit --tid 1 --lun 1 --bstype=sg --device-type=pt -b /dev/sg2 # # tgtadm --op show --mode target Target 1: iqn.2010-08.com.nbusyd:mhvtl System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 00010000 SCSI SN: beaf10 Size: 0 MB Online: Yes Removable media: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: (null) SCSI ID: IET 00010001 SCSI SN: beaf11 Size: 0 MB Online: Yes Removable media: No Backing store type: sg Backing store path: /dev/sg2 Backing store flags: Account information: ACL information: The sg_inq utility doesn't appear to like the /dev/bsg/ devices either. # rpm -qi sg3_utils Name : sg3_utils Relocations: (not relocatable) Version : 1.27 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 17.7 Build Date: Sat 21 Feb 2009 12:23:21 PM EST Mind you, the sg3_utils homepage has this "From lk 2.6.28 bsg devices can also be used (e.g. /dev/bsg/3:0:0:0 )." Cheers Mark -- 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
