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.
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.
> 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
> > Subject: Re: [RFC][PATCH] fs: configfs: programmatically create config
> > groups
> >
> > 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.
&
: [RFC][PATCH] fs: configfs: programmatically create config
groups
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
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
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
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
> > group
@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
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 wh
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
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 11/28/2012 03:24 PM, Michal Nazarewicz wrote:
On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
-
/functions/acm-function/
instead of
/functions/function1/
+name
with attribute file named "name" which contains the name of the
function
On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
> -
> /functions/acm-function/
>
> instead of
>
> /functions/function1/
> +name
> with attribute file named "name" which contains the name of the
> function (i.e. acm). My point is to keep "name"
On Wednesday, November 28, 2012 9:39 AM Sebastian Andrzej Siewior wrote:
> >
> > 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,
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 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
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:
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 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
> >>
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
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
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 needed for given
function to be removed? If you ask
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_
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 Tue, Nov 27 2012, Andrzej Pietrasiewicz 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 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
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
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_
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 needed for given
function to be removed? If you ask
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
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
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
> 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
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 Mon, Nov 26 2012, 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
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
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
56 matches
Mail list logo