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 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 mkd
rote:
> > 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 a
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 i
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 for
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
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 (i.
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" in
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, a
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 kn
> 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
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 wrote:
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 neede
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
> >>
>
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 sam
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 m
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_ nee
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 u
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."
> (http://www.spinics.net/lists/linux-u
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 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 crea
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 thoug
> 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
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 d
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 wh
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 stor
28 matches
Mail list logo
