All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
To: "'Sebastian Andrzej Siewior'" <bigeasy@linutronix.de>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	"'Kyungmin Park'" <kyungmin.park@samsung.com>,
	"'Felipe Balbi'" <balbi@ti.com>,
	"'Greg Kroah-Hartman'" <gregkh@linuxfoundation.org>,
	"'Joel Becker'" <jlbec@evilplan.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	"'Michal Nazarewicz'" <mina86@mina86.com>
Subject: RE: [RFC][PATCH] fs: configfs: programmatically create config groups
Date: Tue, 27 Nov 2012 09:57:05 +0100	[thread overview]
Message-ID: <008101cdcc7d$2d499df0$87dcd9d0$%p@samsung.com> (raw)
In-Reply-To: <50B39921.6090308@linutronix.de>

On Monday, November 26, 2012 5:30 PM Sebastian Andrzej Siewior wrote:
> On 11/26/2012 09:35 AM, Andrzej Pietrasiewicz wrote:
> > In some parts of the kernel (e.g. planned configfs integration into
> > usb
> > gadget) there is a need to programmatically create config groups
> > (directories) but it would be preferable to disallow creating them by
> > the user. This is more or less what default_groups used to be for.
> > But e.g. in the mass storage gadget, after storing the number of luns
> > (logical units) into some configfs attribute, the corresponding lun#
> > directories should be created, their number is not known up front so
> > default_groups are no good for this.
> >

<snip>

> 
> |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?
Are you sure lun# directories will not be created programmatically?
https://lkml.org/lkml/2012/11/26/584

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

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

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

Andrzej



  parent reply	other threads:[~2012-11-27  8:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-26  8:35 [RFC][PATCH] fs: configfs: programmatically create config groups Andrzej Pietrasiewicz
2012-11-26  8:35 ` [RFC][PATCH] fs: configfs: allow other kernel parts to " Andrzej Pietrasiewicz
2012-11-26 13:14 ` [RFC][PATCH] fs: configfs: " Michal Nazarewicz
2012-11-26 16:30 ` Sebastian Andrzej Siewior
2012-11-26 16:56   ` Michal Nazarewicz
2012-11-26 17:06     ` Sebastian Andrzej Siewior
2012-11-26 17:54       ` Michal Nazarewicz
2012-11-27 15:20         ` Sebastian Andrzej Siewior
2012-11-28  7:08           ` Nicholas A. Bellinger
2012-11-27  8:57   ` Andrzej Pietrasiewicz [this message]
2012-11-27 14:32     ` Michal Nazarewicz
2012-11-27 15:59     ` Sebastian Andrzej Siewior
2012-11-27 16:23       ` Michal Nazarewicz
2012-11-28  8:15         ` Sebastian Andrzej Siewior
2012-11-28 13:05           ` Michal Nazarewicz
2012-11-28 13:50             ` Sebastian Andrzej Siewior
2012-11-28 14:24               ` Michal Nazarewicz
2012-11-28 18:52                 ` Sebastian Andrzej Siewior
2012-12-07 23:18               ` Joel Becker
2012-12-10 11:57                 ` Andrzej Pietrasiewicz
2012-12-10 14:17                   ` Andrzej Pietrasiewicz
2012-12-10 14:34                     ` Felipe Balbi
2012-12-10 15:27                       ` Andrzej Pietrasiewicz
2012-12-12  1:10                     ` Joel Becker
2012-12-11 21:27                   ` Joel Becker
2012-12-14 12:18                 ` Sebastian Andrzej Siewior
2012-11-28  8:10       ` Andrzej Pietrasiewicz
2012-11-28  8:38         ` Sebastian Andrzej Siewior
2012-11-28 14:09           ` Andrzej Pietrasiewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='008101cdcc7d$2d499df0$87dcd9d0$%p@samsung.com' \
    --to=andrzej.p@samsung.com \
    --cc=balbi@ti.com \
    --cc=bigeasy@linutronix.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jlbec@evilplan.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mina86@mina86.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.