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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1286351487.5685.145.camel@haakon2.linux-iscsi.org>
Date:	Wed, 06 Oct 2010 00:51:27 -0700
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	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,
	joel.becker@...cle.com,
	Linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC v2 05/21] tcm: Add ConfigFS subsystem backstore
	infrastructure

On Wed, 2010-10-06 at 16:43 +0900, FUJITA Tomonori wrote:
> On Wed, 06 Oct 2010 00:22:10 -0700
> "Nicholas A. Bellinger" <nab@...ux-iscsi.org> 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?
> 
> 

Actually, I already had some code that could simulate mkdir(2) and
rmdir(2) to do exactly what you are talking about here for doing
configfs groups ops from kernel space in 2008 in to assist with the
IOCTL -> configfs v3.0 conversion work.  Joel gave this a big NACK back
then, and I removed the code from target_core_configfs.c shortly
thereafter.  

But really, pushing this logic into userspace and making
python/perl/shell code do these type of things IMHO makes the kernel
level target code cleaner.

Of course I think having something to create configfs groups from
kernelspace is very useful for debugging and ProcFS/SysFS/NetLink/IOCTL
-> ConfigFS conversion purposes, but I will have to defer to Joel for
his reasons of not allowing configfs consumers to do this. (CC'ing
linux-fsdevel)

--nab

--
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/