Message-Id: <20101006160434M.fujita.tomonori@lab.ntt.co.jp>
Date:	Wed, 6 Oct 2010 16:09:29 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	nab@...ux-iscsi.org
Cc:	fujita.tomonori@....ntt.co.jp, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org, michaelc@...wisc.edu, hch@....de,
	hare@...e.de, James.Bottomley@...e.de, axboe@...nel.dk,
	bharrosh@...asas.com, jeff@...zik.org, tj@...nel.org
Subject: Re: [RFC v2 00/21] TCM Core and TCM_Loop patches for v2.6.37

On Tue, 05 Oct 2010 21:46:45 -0700
"Nicholas A. Bellinger" <nab@...ux-iscsi.org> wrote:

> On Wed, 2010-10-06 at 11:21 +0900, FUJITA Tomonori wrote:
> > On Wed, 22 Sep 2010 15:48:22 -0700
> > "Nicholas A. Bellinger" <nab@...ux-iscsi.org> wrote:
> > 
> > >  drivers/Kconfig                                |    2 +
> > >  drivers/Makefile                               |    1 +
> > >  drivers/target/Kbuild                          |   30 +
> > >  drivers/target/Kconfig                         |   36 +
> > 
> > Why do we need a new place for the target stuff? This could be used
> > for non scsi protocl?
> > 
> 
> Yes, I have envisioned the princaple pieces of TCM/ConfigFS design being
> very much SCSI fabric independent from the start of v3.0 development,
> and I think the v4.0 virtual HBA/DEV abstraction now present in
> target_core_configfs.c and fabric module independent control plane in
> target_core_fabric_configfs.c does demonstrate this design feature.
> 
> Of course doing 'SCSI-less' target mode this would still involve some
> work to target_core_transport.c to add ATA specific
> emulation/passthrough and disable others for the default SPC-3 emulation
> logic currently in place.  However, I do believe the TCM subsystem
> plugin API in target_core_transport.h for pSCSI, iBLOCK, FILEIO, etc is
> already more or less SCSI fabric independent and adding a libata
> subsystem plugin (eg: with it's own set of TCM fabric modules) minus
> current libata-scsi.c glue code would be possible if the libata folks
> would like to entertain that discussion..

I like to hear the opinions of SCSI maintainer and ATA folks.

Even if the target feature is SCSI independent, the SCSI drivers
should go to under driver/scsi. As I explained, at least, it's a
cleaner solution for ibmvscsi target driver.


> > We had the similar discussion when I put stgt to mainline but we
> > concluded that under drivers/scsi is the best place.
> > 
> > I don't like to put ibmvscsi driver under something like
> > drivers/target/tcm_ibmvscsit because ibmvscsi needs to include some
> > files under drivers/scsi/ibmvscsi/. It's more reasonable to put the
> > driver there.
> > 
> > Can we change the name, TCM (Target Core Mod), to something more
> > informative? I think that "Core Mod" is really pointless.
> > 
> > This will be the mainline scsi target feature so why can't we name
> > the files and modules in more appropriate way?
> 
> Honestly, I tend not to care very much about naming and things, but that
> said I would really hate to have to rename actual TCM code at this point
> for .37 (other than say directory location/layout and file names) while
> the drivers/target/lio-target -> iscsi_proto.h conversion is still on
> our TODO list.

I'm not sure this goes for .37 (up to James) but anyway I think that
we need to take care about the module names now. Once we put stuff
into mainline, it's not good to change the module names. File and
directory names and layout can be changed any time.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists