On 12/08/2012 12:18 AM, Joel Becker wrote:
Hey Guys,
Hi Joel,
you took quite some time to write this down.
Please remember that configfs is not a user interface, it's a
userspace-kernelspace interface. Like sysfs, it's not required to be
convenient for someone at a bash prompt. My
On Mon, Dec 10, 2012 at 03:17:34PM +0100, Andrzej Pietrasiewicz wrote:
@Joel in particular: please see my comment in the bottom.
snip
I forgot to mention, representing udcs (USB Device Controllers) in
configfs is similar to interfaces/endpoints: the user needs to guess
what name to use in
Hello Joel,
So you are alive, I'm glad to hear from you ;) Thank you for your response.
On Saturday, December 08, 2012 12:18 AM Joel Becker wrote:
Subject: Re: [RFC][PATCH] fs: configfs: programmatically create config
groups
Hey Guys,
Sorry I missed this for a while. I'll make
@Joel in particular: please see my comment in the bottom.
On Monday, December 10, 2012 12:57 PM I wrote:
Subject: RE: [RFC][PATCH] fs: configfs: programmatically create config
groups
Hello Joel,
So you are alive, I'm glad to hear from you ;) Thank you for your
response.
On Saturday
Hi,
On Mon, Dec 10, 2012 at 03:17:34PM +0100, Andrzej Pietrasiewicz wrote:
@Joel in particular: please see my comment in the bottom.
On Monday, December 10, 2012 12:57 PM I wrote:
Subject: RE: [RFC][PATCH] fs: configfs: programmatically create config
groups
Hello Joel,
So you
On Monday, December 10, 2012 3:34 PM Felipe Balbi wrote:
Subject: Re: [RFC][PATCH] fs: configfs: programmatically create config
groups
Hi,
On Mon, Dec 10, 2012 at 03:17:34PM +0100, Andrzej Pietrasiewicz wrote:
@Joel in particular: please see my comment in the bottom.
On Monday
Hey Guys,
Sorry I missed this for a while. I'll make a couple of inline
comments, and then I'll summarize my (incomplete) thoughts at the
bottom.
On Wed, Nov 28, 2012 at 02:50:13PM +0100, Sebastian Andrzej Siewior wrote:
On 11/28/2012 02:05 PM, Michal Nazarewicz wrote:
On 11/27/2012
On Tuesday, November 27, 2012 5:00 PM Sebastian Andrzej Siewior wrote:
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
On 11/27/2012 05:23 PM, Michal Nazarewicz wrote:
On Tue, Nov 27 2012, Sebastian Andrzej Siewior wrote:
I don't want to push python on anyone but the removal magic is simply
straight forward: unlink the disk ports, rmdir luns, tpgt,…
How should a generic tool know what kind of actions are
On 11/28/2012 09:10 AM, Andrzej Pietrasiewicz wrote:
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
On 11/27/2012 05:23 PM, Michal Nazarewicz wrote:
How should a generic tool know what kind of actions are needed for given
function to be removed? If you ask me, there should be a way to unbind
gadget and unload all modules without any specific knowledge of the
functions. If there is no such
On 11/28/2012 02:05 PM, Michal Nazarewicz wrote:
On 11/27/2012 05:23 PM, Michal Nazarewicz wrote:
How should a generic tool know what kind of actions are needed for given
function to be removed? If you ask me, there should be a way to unbind
gadget and unload all modules without any specific
On Wednesday, November 28, 2012 9:39 AM Sebastian Andrzej Siewior wrote:
snip
so that we can create the endpoint directories.
And now what? What names shall the user use for the endpoint
directories? Oh, that's simple: just see what the endpoint
directories' names are. But wait, aren't
On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
function_name-common_name
/functions/acm-function/
instead of
common_name
/functions/function1/
+name
with attribute file named name which contains the name of the
function (i.e. acm). My
On 11/28/2012 03:24 PM, Michal Nazarewicz wrote:
On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
function_name-common_name
/functions/acm-function/
instead of
common_name
/functions/function1/
+name
with attribute file named name which
On Tue, Nov 27 2012, Andrzej Pietrasiewicz andrze...@samsung.com wrote:
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.
On 11/26/2012 06:54 PM, Michal Nazarewicz wrote:
On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
Wouldn't say that. It may adds complexity on another level. The target
subsystem has the same problem with adding luns and there seems nothing
wrong with having lun3 and 4 and leaving 0 and 1
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_
Hi Sebastian Co,
On Tue, 2012-11-27 at 16:20 +0100, Sebastian Andrzej Siewior wrote:
On 11/26/2012 06:54 PM, Michal Nazarewicz wrote:
On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
Wouldn't say that. It may adds complexity on another level. The target
subsystem has the same problem
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
On Mon, Nov 26 2012, Andrzej Pietrasiewicz andrze...@samsung.com 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
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
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
On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
Wouldn't say that. It may adds complexity on another level. The target
subsystem has the same problem with adding luns and there seems nothing
wrong with having lun3 and 4 and leaving 0 and 1 unsued.
That's not what Wikipedia claims though
On 11/26/2012 05:56 PM, Michal Nazarewicz 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
25 matches
Mail list logo
