linux-kernel - Re: [RFC][PATCH] fs: configfs: programmatically create config groups

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: <50B4E364.8030704@linutronix.de>
Date:	Tue, 27 Nov 2012 16:59:32 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Andrzej Pietrasiewicz <andrzej.p@...sung.com>
CC:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	'Kyungmin Park' <kyungmin.park@...sung.com>,
	'Felipe Balbi' <balbi@...com>,
	'Greg Kroah-Hartman' <gregkh@...uxfoundation.org>,
	'Joel Becker' <jlbec@...lplan.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	'Michal Nazarewicz' <mina86@...a86.com>
Subject: Re: [RFC][PATCH] fs: configfs: programmatically create config groups

On 11/27/2012 09:57 AM, Andrzej Pietrasiewicz wrote:
>> |mkdir -p $FABRIC/naa.6001405c3214b06a/tpgt_1
>> |mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0
>> |mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_1
>>
>> So you setup two luns without this patch. Would that work for you?
>>
> I think we _still_ need a way to programmatically create/remove configfs
> directories. Without it, this: "After name is written it will request
> the module and special configuration related files pop up."
> (http://www.spinics.net/lists/linux-usb/msg75118.html)
>
> is only possible for a static, predefined number of configuration
> subdirectories. Can you guarantee there will be only such a need?

No I can't but until now I don't such a need.

> Are you sure lun# directories will not be created programmatically?
> https://lkml.org/lkml/2012/11/26/584

they are not by target and they are not complaining. We need it if we
use the num_luns file which I don't think is useful.

> And there are problems to be addressed right now, not possibly in
> the future: take the intrefaceXX (read-only) directory, which
> contains information about altsetting, interface class,
> interface number, endpoints etc. It can be created only after
> the gadget has actually been bound. But before the gadget is
> bound it is being configured and the configfs directories
> must already be there, so any default_groups are already created.

Here I understand it. This is to some point a limitation of the gadget
framework. We do know the number of interface that will be available
before we bind. We simply don't know the endpoint number. There are two 
exceptions to what I just wrote:
- g_zero drops the ISO endpoints if the UDC has no UDC support for it.
   This should not happen on-the-fly.
- UAC2 may want to make the number interfaces (and therefore configure
   able) and function (play / record) configurable.

> So the interfaceXX directory cannot be implemented as a default
> group, but must be created programmatically.
>
> Also, there is an idea to unbind the gadget with just doing
> rmdir /cfg/...../gadgetX:
> http://www.spinics.net/lists/linux-usb/msg74893.html

Since we link the gadget to the function, we should unlink it.

> This implies doing a recursive rmdir first on its
> subdirectories - a programmatic rmdir.

Hmm. On target I have to rmdir manually

|unlink naa.6001405c3214b06a/tpgt_1/lun/lun_2/virtual_scsi_port
|unlink naa.6001405c3214b06a/tpgt_1/lun/lun_3/virtual_scsi_port
|rmdir naa.6001405c3214b06a/tpgt_1/lun/lun_2
|rmdir naa.6001405c3214b06a/tpgt_1/lun/lun_3
|rmdir naa.6001405c3214b06a/tpgt_1/
|rmdir naa.6001405c3214b06a/
|cd ..
|rmdir usb_gadget

to make it all go away. Couldn't we have a tool to manage all this?
target has such a thing, you have just select a few things via a CLI
tool and the tool creates the directories for you _and_ removes them
later on.
I don't want to push python on anyone but the removal magic is simply
straight forward: unlink the disk ports, rmdir luns, tpgt,…

> Taken all this into account, I would like to have a way
> to programmatically create and remove configfs directories.
> Right now creating them is like scratching the left ear
> with the hand under the right knee. And it leads to
> comments like: "Looking at this: full_name_hash(),
> d_alloc(), d_add(), d_drop(), dput(). Do you write a
> filesystem?"
> http://www.spinics.net/lists/linux-usb/msg74841.html

That was wrong. Pushing it into configs is better but I am not sure we
need it. I understand the need for things that pop later like
interfaceXX but couldn't the user manually create them if he needs them?

>
> Andrzej

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