[Stgt-devel] Adding Virtial Tape & Changer targets

FUJITA Tomonori fujita.tomonori
Wed Mar 21 04:19:20 CET 2007


From: "Mark Harvey" <markh794 at gmail.com>
Subject: [Stgt-devel] Adding Virtial Tape & Changer targets
Date: Wed, 21 Mar 2007 12:39:04 +1100

> A quick introduction.
> 
> I am planning on adding support to the stgt for both SSC and SMC
> devices with the aim of full Virtual Tape Library support.

Great!


> I have a working VTL based around the scsi_debug kernel module +
> char-device 'back-end' to pass SCSI commands thru to user-space
> daemons (which poll the char device looking for work to do). These
> daemons act as the SSC or SMC devices.
> 
> This VTL I have had working for over 12mths.
> 
> However there are some limitations (like a kernel module required for
> each OS port).
> 
> I want to move this code base across to an iSCSI frame-work and have
> finally given up on the Intel iSCSI Reference code base.
> 
> There are some aspects of the stgt code that I would like to modify to
> make this 'port' a little easier.
> 
> There is a lack of a 'generic' pointer for any data structures used
> for each target.
> i.e. I would like to malloc() required storage space to keep MODE/LOG
> SENSE data per target.
> ===================================================================
> --- tgtd.h      (revision 849)
> +++ tgtd.h      (working copy)
> @@ -47,6 +47,9 @@
> 
>         /* TODO: needs a structure for lots of device parameters */
>         uint8_t d_sense;
> +
> +       /* For each device's private use */
> +       void    * priv_p;
>  };
> 
>   struct scsi_cmd {
> 
> ===================================================================

Yeah, we need something like that.


> I suppose what I am asking is:
> 1. Is this list interested in the SSC & SMC code base as/when I get it working ?

Surely. I'm happy to merge them.


> 2. Should I submit all code in a couple of big chunks - e.g. smc.c,
> ssc.c etc once I have got something worthy to submit ?
> Or submit small incremental bits as they are added ? e.g. SCSI command
> at a time.

You can send smc.c and ssc.c as a single big patch
respectively. Probabaly you need some small patches to change stgt for
smc.c and ssc.c.


> So far, while testing of this code base, I have modified the Makefile
> to include the following conditional compile time options. The SBC
> code is still included.
> e.g.
> make KERNELSRC=/usr/src/linux-2.6.20.1 ISCSI=1 SSC=1 SMC=1
>
> Would this be the 'right' way to go, or should it just be compiled
> anyway - like the sbc code?

If SSC and SMC need patched header files like IBMVIO and XEN driver
and passthrough with bsg, you need compile time options. If not, you
don't need them.


> I would also like to see "int (*device_init)()" return a status code
> instead of being a "void (*device_init)()", and a corresponding "int
> (*device_shutdown)()" defined in the device_type_template.

No problem. device_init() is used only for OSD and a workaround. They
are expected to be changed to support other device types like SSC and
SMC.



More information about the stgt mailing list