Re: [RFC v2 05/21] tcm: Add ConfigFS subsystem backstore infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 06 Oct 2010 00:22:10 -0700
"Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote:

> > > The main issue here is that the user still needs to know the $LPORT_WWPN
> > > before hand (either from looking at a sticker on the card, or via
> > > another method) in order to preform the initial TFO->fabric_make_wwn()
> > > -> $TCM_MOD_make_wwn() operation.  So what we need is a configfs attrib
> > > at the top level TCM fabric group in order to see a list of the
> > > available hardware ports from the specific $TCM_MOD.  What I was
> > > thinking for TCM HW fabric module ports would be to have something like:
> > > 
> > > 	/sys/kernel/config/target/$TCM_MOD/hw_ports
> > > 
> > > that would walk the struct pci_dev looking for fabric module specific HW
> > > target mode capabilities.  I assume this is what you had in mind for
> > > drivers/scsi/ibmvscsi as well, yes..?
> > 
> > Doesn't sound so.
> > 
> > I want the driver to create necessary target directories in
> > /sys/kernel/config/target/ibmvscsit/ automatically.
> > 
> > 
> 
> Hmmmm, well configfs is entirely driven by userspace syscalls, so we

I think that we really want to configure things by kernel space too
because the scsi target stuff need to handle hardware.

Need to load the module and create the module name directory by name?

Need to read the content in sysfs to get the hardware info and create
the directories appropriate for the hardware by hand?

Looks strange and inconvenient interface to me. Why can't the kernel
just create the directory layout that suits to the hardware for users?


> want to try to avoid doing this (jlbec CC'ed).  We want userspace code
> to parse a list of these values from sysfs+configfs and use these
> individual HW WWPN value(s) as the directory/group names for the
> mkdir(2) mentioned above.
> 
> > And 'hw_ports' looks unnecessary because fc drivers already provide
> > such information under /sys/class/, I think.
> > --
> 
> Well, it really depends on what is required for individual target fabric
> modules I think, and perhaps could contain some other useful information
> about target mode HW specific available resources.  For the HW FC +
> libfc case, as long as the LLD continues to register TARGET_MODE capable
> HW ports in /sys/class, I think we should be good to go.
> 
> --nab
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux