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

[Sebastian Andrzej Siewior]

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 goal is that it is *usable*
from a bash prompt.  So it must be that you can
create/destroy/configure objects via mkdir/rmkdir/cat/echo, but you
might have a lot of those mkdir/echo combos to configure something.
When it comes to the "user" interface, a wrapper script or library
should be converting a user intention into all that boilerplate.


It is good that you say such things so people that want this things know 
the reasons why it is not done.



I think the question is of information flow direction.  If user gives
some information to the kernel, she should be the one creating any
necessary directories.  But if the information comes from kernel to the
user, the kernel should create the structure.


This last paragraph actually describes the distinction between
configfs and sysfs.  More specifically, if userspace wants to create an
object in the kernel, it should use configfs.  If the kernel has created
an object on its own, it exposes it via sysfs.  It is a deliberate
non-goal for configfs to replicate sysfs behavior.


So you are saying that I should expose my UDC hardware device via sysfs
after the hardware is available because the kernel created it.
How should I get then into configfs? mkdir a directory which is named
like the HW? This would be painful to do manually but as you said, we
should have a tool.


[What About the Patch?]

In general, attribute setting that turns into created configfs
objects is against the theory of configfs.  In practice, it's a
nightmare locking change.  Coming into this discussion, I though you
were doing dymanic things at ->make_group() time, but that is already
supported.
But I want to hear your thoughts.  I've dumped a bunch of
alternate approaches here.  Do any seem to fit?  What other challenges
do you see?


I'm mostly fine with this. Part of the problem was/is that the user
could create lun1 without lun0. Now, after looking at target they don't
have this limitation so I don't think we should have it either. As nab
explained, lun0 is always handled implicit for certain requests and not
exposed as a lun if the user did not create it. So I think we can live
with this. After all we can still return with -EINVAL if the user
creates lun1 before lun0.

Now one little question remains: We plan to expose interface numbers
and endpoints. The current idea is to have one directory for each
endpoint something like endpointXX where XX is the endpoint number.
We create the gadget upfront and assign it later to the UDC via a
symlink. We learn the interface number after the gadget has been
assigned. I think you suggest that we create the directory via the tool
once we exposed its details via sysfs or so. This might be okay since we 
want it probably only for debugging. On the hand if we drop the

endpooint number we don't have this. Got to keep thinking about this.

Anyway, thank you for time and arguments pro / contra self-created
directories.



Joel



Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sebastian Andrzej Siewior]

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 goal is that it is *usable*
from a bash prompt.  So it must be that you can
create/destroy/configure objects via mkdir/rmkdir/cat/echo, but you
might have a lot of those mkdir/echo combos to configure something.
When it comes to the user interface, a wrapper script or library
should be converting a user intention into all that boilerplate.


It is good that you say such things so people that want this things know 
the reasons why it is not done.



I think the question is of information flow direction.  If user gives
some information to the kernel, she should be the one creating any
necessary directories.  But if the information comes from kernel to the
user, the kernel should create the structure.


This last paragraph actually describes the distinction between
configfs and sysfs.  More specifically, if userspace wants to create an
object in the kernel, it should use configfs.  If the kernel has created
an object on its own, it exposes it via sysfs.  It is a deliberate
non-goal for configfs to replicate sysfs behavior.


So you are saying that I should expose my UDC hardware device via sysfs
after the hardware is available because the kernel created it.
How should I get then into configfs? mkdir a directory which is named
like the HW? This would be painful to do manually but as you said, we
should have a tool.


[What About the Patch?]

In general, attribute setting that turns into created configfs
objects is against the theory of configfs.  In practice, it's a
nightmare locking change.  Coming into this discussion, I though you
were doing dymanic things at -make_group() time, but that is already
supported.
But I want to hear your thoughts.  I've dumped a bunch of
alternate approaches here.  Do any seem to fit?  What other challenges
do you see?


I'm mostly fine with this. Part of the problem was/is that the user
could create lun1 without lun0. Now, after looking at target they don't
have this limitation so I don't think we should have it either. As nab
explained, lun0 is always handled implicit for certain requests and not
exposed as a lun if the user did not create it. So I think we can live
with this. After all we can still return with -EINVAL if the user
creates lun1 before lun0.

Now one little question remains: We plan to expose interface numbers
and endpoints. The current idea is to have one directory for each
endpoint something like endpointXX where XX is the endpoint number.
We create the gadget upfront and assign it later to the UDC via a
symlink. We learn the interface number after the gadget has been
assigned. I think you suggest that we create the directory via the tool
once we exposed its details via sysfs or so. This might be okay since we 
want it probably only for debugging. On the hand if we drop the

endpooint number we don't have this. Got to keep thinking about this.

Anyway, thank you for time and arguments pro / contra self-created
directories.



Joel



Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Joel Becker]

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 mkdir, e.g. in:
> 
> $ mkdir ../udcs/s3c-hsotg

Again, discoverability.  Userspace should not need to guess.  So
some part of the system (configfs, sysfs, procfs, $dontcare) needs to
know what the available choices are.

> the poor user needs to know that the udc is actually called s3c-hsotg.
> And after the udc goes away from the system, the s3c-hsotg directory
> remains in the filesystem until the user deletes it (as nobody else
> but the user can do it). Again, an attribute like available_udcs in
> the udcs directory can help. But still, there will be times when
> its contents will not be consistent with the directories actually
> present.

How does the system know there is an s3c-hsotg?  Is this from
scanning?

> @Joel: Any thoughts about it? Commitable items? E.g. the user creates
> whatever they want, so the "uncommitted" directory contains "garbage",
> that is directories which do not have to correspond to anything
> actually present in the system, but on commiting the gadget's item
> (group in fact) everything is verified and only "correct" gadgets
> are actually bound? Then, in the "uncommitted" directory the user
> can still do whatever they want, but this is not effective until
> uncommitting the old gadget and committing it again? There is just
> a tiny issue with committable items: Are they implemented? :O

Committable items are not implemented, because everyone uses the
'enable' pattern:

  $ mkdir foo
  $ echo 1024 >foo/attr1
  $ echo 2048 >foo/attr2
  $ echo 1 >foo/enable

In o2hb, we don't have an explicit "enable" attribute.  Instead, we
enable when the block device's file descriptor is stored.  If the other
attributes aren't set yet, we fail the store.

Joel

-- 

Life's Little Instruction Book #451

"Don't be afraid to say, 'I'm sorry.'"

http://www.jlbec.org/
jl...@evilplan.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Joel Becker]

On Mon, Dec 10, 2012 at 12:57:02PM +0100, Andrzej Pietrasiewicz wrote:
> Hello Joel,
> 
> So you are alive, I'm glad to hear from you ;) Thank you for your response.

Yeah, sorry for missing the thread for so long.

> 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 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 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 mechanism, then
> > > >>>it's a bad user interface.
> > 
> > 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 goal is that it is *usable*
> > from a bash prompt.  So it must be that you can create/destroy/configure
> > objects via mkdir/rmkdir/cat/echo, but you might have a lot of those
> > mkdir/echo combos to configure something.
> > When it comes to the "user" interface, a wrapper script or library should
> > be converting a user intention into all that boilerplate.
> > 
> 
> If you say so there is little we can do, is there? :O

I don't want to make your life harder.  I'm describing the
motivations so that we can come to a consensus.  But configfs isn't an
end-user interface.  Consider the RAID ioctls
(/usr/include/linux/md/md_u.h).  Do you really expect that users will
manage their MD devices by writing programs that do "ioctl(/dev/md0,
GET_ARRAY_INFO)"?  No, you don't.  You expect that mdadm will exist.
But ioctls are a pain.  Want to do something in a script or code
that mdadm doesn't handle?  Get ready to write ioctls.  In configfs, you
can do it in a shell script.  What about debugging?  Sometimes hackers
like us and sysadmins debugging problems like "mdadm doesn't work" need
to poke around.  If mdadm isn't working, they have to strace the ioctl
calls, then unpack the arguments and see what is happening.  With
configfs, instead, you have a filesystem tree to poke at.
That's why I wrote it.  sysfs is the same way.  You and I can
poke about sysfs to get info, but most people just want udev to convert
sysfs info into a working system.
Now, none of this means we shouldn't come up with the simplest
configfs interface for your gadgets.  But if we want to add features to
configfs (rather than to your use of it), I want to understand how this
helps us as userspace<->kernelspace API designers, not how it helps a
sysadmin type fewer commands.

> > > Anyway, for this to work we have to go through Joel.
> > >
> > > > rmdir udcs/*# unload all UDCs
> > >
> > > No, for this you still have to rmmod :)
> > >
> > >
> > > >>>I think the question is of information flow direction.  If user
> > > >>>gives some information to the kernel, she should be the one
> > > >>>creating any necessary directories.  But if the information comes
> > > >>>from kernel to the user, the kernel should create the structure.
> > 
> > This last paragraph actually describes the distinction between
> > configfs and sysfs.  More specifically, if userspace wants to create an
> > object in the kernel, it should use configfs.  If the kernel has created
> > an object on its own, it exposes it via sysfs.  It is a deliberate non-
> > goal for configfs to replicate sysfs behavior.
> 
> So if the lifetime of some object is controlled by the user, it belongs
> to configfs. If, on the other hand, the lifetime is controlled by the
> kernel, it belongs to sysfs. I think that the trouble with e.g. luns
> is that they might want to behave like both (at least in the "more
> automated"
> approach where they are programmatically created): they are created
> by the kernel (=> sysfs) but their lifetime is controlled by the user
> (=>configfs).

I think your point is correct, but not quite aligned.  The
gadget endpoint is created by the user (configfs).  It, in turn, ca

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

[Joel Becker]

On Mon, Dec 10, 2012 at 12:57:02PM +0100, Andrzej Pietrasiewicz wrote:
 Hello Joel,
 
 So you are alive, I'm glad to hear from you ;) Thank you for your response.

Yeah, sorry for missing the thread for so long.

 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 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 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 mechanism, then
   it's a bad user interface.
  
  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 goal is that it is *usable*
  from a bash prompt.  So it must be that you can create/destroy/configure
  objects via mkdir/rmkdir/cat/echo, but you might have a lot of those
  mkdir/echo combos to configure something.
  When it comes to the user interface, a wrapper script or library should
  be converting a user intention into all that boilerplate.
  
 
 If you say so there is little we can do, is there? :O

I don't want to make your life harder.  I'm describing the
motivations so that we can come to a consensus.  But configfs isn't an
end-user interface.  Consider the RAID ioctls
(/usr/include/linux/md/md_u.h).  Do you really expect that users will
manage their MD devices by writing programs that do ioctl(/dev/md0,
GET_ARRAY_INFO)?  No, you don't.  You expect that mdadm will exist.
But ioctls are a pain.  Want to do something in a script or code
that mdadm doesn't handle?  Get ready to write ioctls.  In configfs, you
can do it in a shell script.  What about debugging?  Sometimes hackers
like us and sysadmins debugging problems like mdadm doesn't work need
to poke around.  If mdadm isn't working, they have to strace the ioctl
calls, then unpack the arguments and see what is happening.  With
configfs, instead, you have a filesystem tree to poke at.
That's why I wrote it.  sysfs is the same way.  You and I can
poke about sysfs to get info, but most people just want udev to convert
sysfs info into a working system.
Now, none of this means we shouldn't come up with the simplest
configfs interface for your gadgets.  But if we want to add features to
configfs (rather than to your use of it), I want to understand how this
helps us as userspace-kernelspace API designers, not how it helps a
sysadmin type fewer commands.

   Anyway, for this to work we have to go through Joel.
  
rmdir udcs/*# unload all UDCs
  
   No, for this you still have to rmmod :)
  
  
   I think the question is of information flow direction.  If user
   gives some information to the kernel, she should be the one
   creating any necessary directories.  But if the information comes
   from kernel to the user, the kernel should create the structure.
  
  This last paragraph actually describes the distinction between
  configfs and sysfs.  More specifically, if userspace wants to create an
  object in the kernel, it should use configfs.  If the kernel has created
  an object on its own, it exposes it via sysfs.  It is a deliberate non-
  goal for configfs to replicate sysfs behavior.
 
 So if the lifetime of some object is controlled by the user, it belongs
 to configfs. If, on the other hand, the lifetime is controlled by the
 kernel, it belongs to sysfs. I think that the trouble with e.g. luns
 is that they might want to behave like both (at least in the more
 automated
 approach where they are programmatically created): they are created
 by the kernel (= sysfs) but their lifetime is controlled by the user
 (=configfs).

I think your point is correct, but not quite aligned.  The
gadget endpoint is created by the user (configfs).  It, in turn, causes
the kernel to detect and create LUNs (sysfs).  I don't think this is a
conflict.
Is your concern that I can then remove the gadget endpoint,
which should trigger the LUNs to disappear, but they are in use?  This
is why the depend_item() interface exists.  When the LUN is opened, the
LUN should mark depend_item() on the gadget endpoint.  Now rmdir() will
fail.

  But this doesn't alleviate Andrzej's primary concern, nor does it
  answer Michal's concerns about corner cases.  Let's see if we can solve
  those.
  First, what about preventing extraneous LUNs?  There are two
  approaches: the prevent approach, and the ignore approach.  In the Target

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

[Joel Becker]

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 mkdir, e.g. in:
 
 $ mkdir ../udcs/s3c-hsotg

Again, discoverability.  Userspace should not need to guess.  So
some part of the system (configfs, sysfs, procfs, $dontcare) needs to
know what the available choices are.

 the poor user needs to know that the udc is actually called s3c-hsotg.
 And after the udc goes away from the system, the s3c-hsotg directory
 remains in the filesystem until the user deletes it (as nobody else
 but the user can do it). Again, an attribute like available_udcs in
 the udcs directory can help. But still, there will be times when
 its contents will not be consistent with the directories actually
 present.

How does the system know there is an s3c-hsotg?  Is this from
scanning?

 @Joel: Any thoughts about it? Commitable items? E.g. the user creates
 whatever they want, so the uncommitted directory contains garbage,
 that is directories which do not have to correspond to anything
 actually present in the system, but on commiting the gadget's item
 (group in fact) everything is verified and only correct gadgets
 are actually bound? Then, in the uncommitted directory the user
 can still do whatever they want, but this is not effective until
 uncommitting the old gadget and committing it again? There is just
 a tiny issue with committable items: Are they implemented? :O

Committable items are not implemented, because everyone uses the
'enable' pattern:

  $ mkdir foo
  $ echo 1024 foo/attr1
  $ echo 2048 foo/attr2
  $ echo 1 foo/enable

In o2hb, we don't have an explicit enable attribute.  Instead, we
enable when the block device's file descriptor is stored.  If the other
attributes aren't set yet, we fail the store.

Joel

-- 

Life's Little Instruction Book #451

Don't be afraid to say, 'I'm sorry.'

http://www.jlbec.org/
jl...@evilplan.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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, 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, 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 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 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 mechanism, then it's a bad user interface.
> > > >
> > > > 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 goal is that it
> > > > is *usable* from a bash prompt.  So it must be that you can
> > > > create/destroy/configure objects via mkdir/rmkdir/cat/echo, but
> > > > you might have a lot of those mkdir/echo combos to configure
> something.
> > > > When it comes to the "user" interface, a wrapper script or library
> > > should
> > > > be converting a user intention into all that boilerplate.
> > > >
> > >
> > > If you say so there is little we can do, is there? :O
> > >
> > > 
> > >
> > > >
> > > > Yeah, user tools are expected (and should be).
> > > >
> > >
> > > ditto
> > >
> > > > > Anyway, for this to work we have to go through Joel.
> > > > >
> > > > > > rmdir udcs/*# unload all UDCs
> > > > >
> > > > > No, for this you still have to rmmod :)
> > > > >
> > > > >
> > > > > >>>I think the question is of information flow direction.  If
> > > > > >>>user gives some information to the kernel, she should be the
> > > > > >>>one creating any necessary directories.  But if the
> > > > > >>>information comes from kernel to the user, the kernel should
> create the structure.
> > > >
> > > > This last paragraph actually describes the distinction
between
> > > > configfs and sysfs.  More specifically, if userspace wants to
> > > > create an object in the kernel, it should use configfs.  If the
> > > > kernel has created an object on its own, it exposes it via sysfs.
> > > > It is a deliberate non- goal for configfs to replicate sysfs
> behavior.
> > >
> > > So if the lifetime of some object is controlled by the user, it
> > > belongs to configfs. If, on the other hand, the lifetime is
> > > controlled by the kernel, it belongs to sysfs. I think that the
> > > trouble with e.g. luns is that they might want to behave like both
> > > (at least in the "more automated"
> > > approach where they are programmatically created): they are created
> > > by the kernel (=> sysfs) but their lifetime is controlled by the
> > > user (=>configfs).
> > >
> > > >
> > > > [General Thoughts]
> > > >
> > > > First let me restate your problem to see if I understand it.
> > > > You want to expose e.g. five LUNs.  They shou

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

[Felipe Balbi]

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 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 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 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 mechanism, then
> > > > >>>it's a bad user interface.
> > >
> > >   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 goal is that it is *usable*
> > > from a bash prompt.  So it must be that you can create/destroy/configure
> > > objects via mkdir/rmkdir/cat/echo, but you might have a lot of those
> > > mkdir/echo combos to configure something.
> > > When it comes to the "user" interface, a wrapper script or library
> > should
> > > be converting a user intention into all that boilerplate.
> > >
> > 
> > If you say so there is little we can do, is there? :O
> > 
> > 
> > 
> > >
> > >   Yeah, user tools are expected (and should be).
> > >
> > 
> > ditto
> > 
> > > > Anyway, for this to work we have to go through Joel.
> > > >
> > > > >   rmdir udcs/*# unload all UDCs
> > > >
> > > > No, for this you still have to rmmod :)
> > > >
> > > >
> > > > >>>I think the question is of information flow direction.  If user
> > > > >>>gives some information to the kernel, she should be the one
> > > > >>>creating any necessary directories.  But if the information comes
> > > > >>>from kernel to the user, the kernel should create the structure.
> > >
> > >   This last paragraph actually describes the distinction between
> > > configfs and sysfs.  More specifically, if userspace wants to create an
> > > object in the kernel, it should use configfs.  If the kernel has created
> > > an object on its own, it exposes it via sysfs.  It is a deliberate non-
> > > goal for configfs to replicate sysfs behavior.
> > 
> > So if the lifetime of some object is controlled by the user, it belongs
> > to configfs. If, on the other hand, the lifetime is controlled by the
> > kernel, it belongs to sysfs. I think that the trouble with e.g. luns
> > is that they might want to behave like both (at least in the "more
> > automated"
> > approach where they are programmatically created): they are created
> > by the kernel (=> sysfs) but their lifetime is controlled by the user
> > (=>configfs).
> > 
> > >
> > > [General Thoughts]
> > >
> > >   First let me restate your problem to see if I understand it.
> > >   You want to expose e.g. five LUNs.  They should eventually appear in
> > > configfs as five items to configure (.../{lun0,lun1,...lun4}/.  The
> > > current configfs way to do this is to have your setup script do:
> > >
> > >   cd /cfg/.../mass_storage
> > >   mkdir lun0
> > >   echo blah >lun0/attr1
> > >   echo blahh >lun0/attr2
> > >   mkdir lun1
> > >   echo blag >lun1/attr1
> > >   echo blagg >lun1/attr1
> > >   ...
> > >
> > > I think the primary concern expressed by Andrzej is that a random user
> > > could come along and say "mkdir lun8"

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

@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, 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 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 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 mechanism, then
> > > >>>it's a bad user interface.
> >
> > 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 goal is that it is *usable*
> > from a bash prompt.  So it must be that you can create/destroy/configure
> > objects via mkdir/rmkdir/cat/echo, but you might have a lot of those
> > mkdir/echo combos to configure something.
> > When it comes to the "user" interface, a wrapper script or library
> should
> > be converting a user intention into all that boilerplate.
> >
> 
> If you say so there is little we can do, is there? :O
> 
> 
> 
> >
> > Yeah, user tools are expected (and should be).
> >
> 
> ditto
> 
> > > Anyway, for this to work we have to go through Joel.
> > >
> > > > rmdir udcs/*# unload all UDCs
> > >
> > > No, for this you still have to rmmod :)
> > >
> > >
> > > >>>I think the question is of information flow direction.  If user
> > > >>>gives some information to the kernel, she should be the one
> > > >>>creating any necessary directories.  But if the information comes
> > > >>>from kernel to the user, the kernel should create the structure.
> >
> > This last paragraph actually describes the distinction between
> > configfs and sysfs.  More specifically, if userspace wants to create an
> > object in the kernel, it should use configfs.  If the kernel has created
> > an object on its own, it exposes it via sysfs.  It is a deliberate non-
> > goal for configfs to replicate sysfs behavior.
> 
> So if the lifetime of some object is controlled by the user, it belongs
> to configfs. If, on the other hand, the lifetime is controlled by the
> kernel, it belongs to sysfs. I think that the trouble with e.g. luns
> is that they might want to behave like both (at least in the "more
> automated"
> approach where they are programmatically created): they are created
> by the kernel (=> sysfs) but their lifetime is controlled by the user
> (=>configfs).
> 
> >
> > [General Thoughts]
> >
> > First let me restate your problem to see if I understand it.
> > You want to expose e.g. five LUNs.  They should eventually appear in
> > configfs as five items to configure (.../{lun0,lun1,...lun4}/.  The
> > current configfs way to do this is to have your setup script do:
> >
> > cd /cfg/.../mass_storage
> > mkdir lun0
> > echo blah >lun0/attr1
> > echo blahh >lun0/attr2
> > mkdir lun1
> > echo blag >lun1/attr1
> > echo blagg >lun1/attr1
> > ...
> >
> > I think the primary concern expressed by Andrzej is that a random user
> > could come along and say "mkdir lun8", even though the gadget cannot
> > support it.  A secondary concern from Michal is that userspace has to
> run
> > all of those mkdirs.  The thread has described varying solutions.
> > If these original directories were default_groups, you could
> > disallow any child creation and not require the setup script to create
> > directories.  Here I will point out that you *can* create default_groups
> > programmatically.  The default_groups pointer on each configfs_group can
> > 

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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 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 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 mechanism, then
> > >>>it's a bad user interface.
> 
>   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 goal is that it is *usable*
> from a bash prompt.  So it must be that you can create/destroy/configure
> objects via mkdir/rmkdir/cat/echo, but you might have a lot of those
> mkdir/echo combos to configure something.
> When it comes to the "user" interface, a wrapper script or library should
> be converting a user intention into all that boilerplate.
> 

If you say so there is little we can do, is there? :O



> 
>   Yeah, user tools are expected (and should be).
> 

ditto

> > Anyway, for this to work we have to go through Joel.
> >
> > >   rmdir udcs/*# unload all UDCs
> >
> > No, for this you still have to rmmod :)
> >
> >
> > >>>I think the question is of information flow direction.  If user
> > >>>gives some information to the kernel, she should be the one
> > >>>creating any necessary directories.  But if the information comes
> > >>>from kernel to the user, the kernel should create the structure.
> 
>   This last paragraph actually describes the distinction between
> configfs and sysfs.  More specifically, if userspace wants to create an
> object in the kernel, it should use configfs.  If the kernel has created
> an object on its own, it exposes it via sysfs.  It is a deliberate non-
> goal for configfs to replicate sysfs behavior.

So if the lifetime of some object is controlled by the user, it belongs
to configfs. If, on the other hand, the lifetime is controlled by the
kernel, it belongs to sysfs. I think that the trouble with e.g. luns
is that they might want to behave like both (at least in the "more
automated"
approach where they are programmatically created): they are created
by the kernel (=> sysfs) but their lifetime is controlled by the user
(=>configfs).

> 
> [General Thoughts]
> 
>   First let me restate your problem to see if I understand it.
>   You want to expose e.g. five LUNs.  They should eventually appear in
> configfs as five items to configure (.../{lun0,lun1,...lun4}/.  The
> current configfs way to do this is to have your setup script do:
> 
>   cd /cfg/.../mass_storage
>   mkdir lun0
>   echo blah >lun0/attr1
>   echo blahh >lun0/attr2
>   mkdir lun1
>   echo blag >lun1/attr1
>   echo blagg >lun1/attr1
>   ...
> 
> I think the primary concern expressed by Andrzej is that a random user
> could come along and say "mkdir lun8", even though the gadget cannot
> support it.  A secondary concern from Michal is that userspace has to run
> all of those mkdirs.  The thread has described varying solutions.
>   If these original directories were default_groups, you could
> disallow any child creation and not require the setup script to create
> directories.  Here I will point out that you *can* create default_groups
> programmatically.  The default_groups pointer on each configfs_group can
> be different.  ->make_group() can attach whatever groups it wants.
> If this would work, it would fit both of your concerns, but you do not
> have a priori knowledge of the LUN count.
>   Your original email proposed that the max lun be set like so:
> 
>   cd /cfg/.../mass_storage
>   echo 5 >luns_allowed
> 
> There are then a couple of proposed ways to enforce the limit.  Your
> ->create_group() idea wants luns_allowed to be able to create subdirs in
> the ->store() function.  No ->mkdir() is provided, so a lunN cannot be
> created by hand.
>   The ->create_group

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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 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 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 mechanism, then
  it's a bad user interface.
 
   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 goal is that it is *usable*
 from a bash prompt.  So it must be that you can create/destroy/configure
 objects via mkdir/rmkdir/cat/echo, but you might have a lot of those
 mkdir/echo combos to configure something.
 When it comes to the user interface, a wrapper script or library should
 be converting a user intention into all that boilerplate.
 

If you say so there is little we can do, is there? :O

snip

 
   Yeah, user tools are expected (and should be).
 

ditto

  Anyway, for this to work we have to go through Joel.
 
 rmdir udcs/*# unload all UDCs
 
  No, for this you still have to rmmod :)
 
 
  I think the question is of information flow direction.  If user
  gives some information to the kernel, she should be the one
  creating any necessary directories.  But if the information comes
  from kernel to the user, the kernel should create the structure.
 
   This last paragraph actually describes the distinction between
 configfs and sysfs.  More specifically, if userspace wants to create an
 object in the kernel, it should use configfs.  If the kernel has created
 an object on its own, it exposes it via sysfs.  It is a deliberate non-
 goal for configfs to replicate sysfs behavior.

So if the lifetime of some object is controlled by the user, it belongs
to configfs. If, on the other hand, the lifetime is controlled by the
kernel, it belongs to sysfs. I think that the trouble with e.g. luns
is that they might want to behave like both (at least in the more
automated
approach where they are programmatically created): they are created
by the kernel (= sysfs) but their lifetime is controlled by the user
(=configfs).

 
 [General Thoughts]
 
   First let me restate your problem to see if I understand it.
   You want to expose e.g. five LUNs.  They should eventually appear in
 configfs as five items to configure (.../{lun0,lun1,...lun4}/.  The
 current configfs way to do this is to have your setup script do:
 
   cd /cfg/.../mass_storage
   mkdir lun0
   echo blah lun0/attr1
   echo blahh lun0/attr2
   mkdir lun1
   echo blag lun1/attr1
   echo blagg lun1/attr1
   ...
 
 I think the primary concern expressed by Andrzej is that a random user
 could come along and say mkdir lun8, even though the gadget cannot
 support it.  A secondary concern from Michal is that userspace has to run
 all of those mkdirs.  The thread has described varying solutions.
   If these original directories were default_groups, you could
 disallow any child creation and not require the setup script to create
 directories.  Here I will point out that you *can* create default_groups
 programmatically.  The default_groups pointer on each configfs_group can
 be different.  -make_group() can attach whatever groups it wants.
 If this would work, it would fit both of your concerns, but you do not
 have a priori knowledge of the LUN count.
   Your original email proposed that the max lun be set like so:
 
   cd /cfg/.../mass_storage
   echo 5 luns_allowed
 
 There are then a couple of proposed ways to enforce the limit.  Your
 -create_group() idea wants luns_allowed to be able to create subdirs in
 the -store() function.  No -mkdir() is provided, so a lunN cannot be
 created by hand.
   The -create_group() idea has three challenges.  First, it creates
 default groups *after* the object is created.  This makes no sense if
 they are attributes of the toplevel object.  Second, it volates the
 configfs mantra that user-generated objects are explicitly created.
 The kicker, however, is the technical problem.  configfs explicitly
 forbids tree changes inside attribute operations for deadlock reasons.
 Trying to create new tree parts in luns_allowed-store() is exactly that.
   Another suggestion (I think I read this in the thread) would be to
 have -mkdir() function parse the name and check that it is lunN, where N
 is less than

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

@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, 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 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 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 mechanism, then
   it's a bad user interface.
 
  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 goal is that it is *usable*
  from a bash prompt.  So it must be that you can create/destroy/configure
  objects via mkdir/rmkdir/cat/echo, but you might have a lot of those
  mkdir/echo combos to configure something.
  When it comes to the user interface, a wrapper script or library
 should
  be converting a user intention into all that boilerplate.
 
 
 If you say so there is little we can do, is there? :O
 
 snip
 
 
  Yeah, user tools are expected (and should be).
 
 
 ditto
 
   Anyway, for this to work we have to go through Joel.
  
rmdir udcs/*# unload all UDCs
  
   No, for this you still have to rmmod :)
  
  
   I think the question is of information flow direction.  If user
   gives some information to the kernel, she should be the one
   creating any necessary directories.  But if the information comes
   from kernel to the user, the kernel should create the structure.
 
  This last paragraph actually describes the distinction between
  configfs and sysfs.  More specifically, if userspace wants to create an
  object in the kernel, it should use configfs.  If the kernel has created
  an object on its own, it exposes it via sysfs.  It is a deliberate non-
  goal for configfs to replicate sysfs behavior.
 
 So if the lifetime of some object is controlled by the user, it belongs
 to configfs. If, on the other hand, the lifetime is controlled by the
 kernel, it belongs to sysfs. I think that the trouble with e.g. luns
 is that they might want to behave like both (at least in the more
 automated
 approach where they are programmatically created): they are created
 by the kernel (= sysfs) but their lifetime is controlled by the user
 (=configfs).
 
 
  [General Thoughts]
 
  First let me restate your problem to see if I understand it.
  You want to expose e.g. five LUNs.  They should eventually appear in
  configfs as five items to configure (.../{lun0,lun1,...lun4}/.  The
  current configfs way to do this is to have your setup script do:
 
  cd /cfg/.../mass_storage
  mkdir lun0
  echo blah lun0/attr1
  echo blahh lun0/attr2
  mkdir lun1
  echo blag lun1/attr1
  echo blagg lun1/attr1
  ...
 
  I think the primary concern expressed by Andrzej is that a random user
  could come along and say mkdir lun8, even though the gadget cannot
  support it.  A secondary concern from Michal is that userspace has to
 run
  all of those mkdirs.  The thread has described varying solutions.
  If these original directories were default_groups, you could
  disallow any child creation and not require the setup script to create
  directories.  Here I will point out that you *can* create default_groups
  programmatically.  The default_groups pointer on each configfs_group can
  be different.  -make_group() can attach whatever groups it wants.
  If this would work, it would fit both of your concerns, but you do not
  have a priori knowledge of the LUN count.
  Your original email proposed that the max lun be set like so:
 
  cd /cfg/.../mass_storage
  echo 5 luns_allowed
 
  There are then a couple of proposed ways to enforce the limit.  Your
  -create_group() idea wants luns_allowed to be able to create subdirs in
  the -store() function.  No -mkdir() is provided, so a lunN cannot be
  created by hand.
  The -create_group() idea has three challenges.  First, it creates
  default groups *after* the object is created.  This makes no sense if
  they are attributes of the toplevel object.  Second, it volates the
  configfs mantra that user-generated objects are explicitly created.
  The kicker, however, is the technical problem.  configfs explicitly
  forbids tree changes inside attribute operations

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

[Felipe Balbi]

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 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 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 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 mechanism, then
it's a bad user interface.
  
 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 goal is that it is *usable*
   from a bash prompt.  So it must be that you can create/destroy/configure
   objects via mkdir/rmkdir/cat/echo, but you might have a lot of those
   mkdir/echo combos to configure something.
   When it comes to the user interface, a wrapper script or library
  should
   be converting a user intention into all that boilerplate.
  
  
  If you say so there is little we can do, is there? :O
  
  snip
  
  
 Yeah, user tools are expected (and should be).
  
  
  ditto
  
Anyway, for this to work we have to go through Joel.
   
   rmdir udcs/*# unload all UDCs
   
No, for this you still have to rmmod :)
   
   
I think the question is of information flow direction.  If user
gives some information to the kernel, she should be the one
creating any necessary directories.  But if the information comes
from kernel to the user, the kernel should create the structure.
  
 This last paragraph actually describes the distinction between
   configfs and sysfs.  More specifically, if userspace wants to create an
   object in the kernel, it should use configfs.  If the kernel has created
   an object on its own, it exposes it via sysfs.  It is a deliberate non-
   goal for configfs to replicate sysfs behavior.
  
  So if the lifetime of some object is controlled by the user, it belongs
  to configfs. If, on the other hand, the lifetime is controlled by the
  kernel, it belongs to sysfs. I think that the trouble with e.g. luns
  is that they might want to behave like both (at least in the more
  automated
  approach where they are programmatically created): they are created
  by the kernel (= sysfs) but their lifetime is controlled by the user
  (=configfs).
  
  
   [General Thoughts]
  
 First let me restate your problem to see if I understand it.
 You want to expose e.g. five LUNs.  They should eventually appear in
   configfs as five items to configure (.../{lun0,lun1,...lun4}/.  The
   current configfs way to do this is to have your setup script do:
  
 cd /cfg/.../mass_storage
 mkdir lun0
 echo blah lun0/attr1
 echo blahh lun0/attr2
 mkdir lun1
 echo blag lun1/attr1
 echo blagg lun1/attr1
 ...
  
   I think the primary concern expressed by Andrzej is that a random user
   could come along and say mkdir lun8, even though the gadget cannot
   support it.  A secondary concern from Michal is that userspace has to
  run
   all of those mkdirs.  The thread has described varying solutions.
 If these original directories were default_groups, you could
   disallow any child creation and not require the setup script to create
   directories.  Here I will point out that you *can* create default_groups
   programmatically.  The default_groups pointer on each configfs_group can
   be different.  -make_group() can attach whatever groups it wants.
   If this would work, it would fit both of your concerns, but you do not
   have a priori knowledge of the LUN count.
 Your original email proposed that the max lun be set like so:
  
 cd /cfg/.../mass_storage
 echo 5 luns_allowed
  
   There are then a couple of proposed ways to enforce the limit.  Your
   -create_group() idea wants luns_allowed to be able to create subdirs in
   the -store() function.  No -mkdir() is provided, so a lunN cannot be
   created by hand.
 The -create_group() idea has three challenges.  First, it creates
   default groups *after* the object is created.  This makes no sense if
   they are attributes of the toplevel object.  Second, it volates the
   configfs mantra that user

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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, 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, 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 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 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 mechanism, then it's a bad user interface.
   
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 goal is that it
is *usable* from a bash prompt.  So it must be that you can
create/destroy/configure objects via mkdir/rmkdir/cat/echo, but
you might have a lot of those mkdir/echo combos to configure
 something.
When it comes to the user interface, a wrapper script or library
   should
be converting a user intention into all that boilerplate.
   
  
   If you say so there is little we can do, is there? :O
  
   snip
  
   
Yeah, user tools are expected (and should be).
   
  
   ditto
  
 Anyway, for this to work we have to go through Joel.

  rmdir udcs/*# unload all UDCs

 No, for this you still have to rmmod :)


 I think the question is of information flow direction.  If
 user gives some information to the kernel, she should be the
 one creating any necessary directories.  But if the
 information comes from kernel to the user, the kernel should
 create the structure.
   
This last paragraph actually describes the distinction
between
configfs and sysfs.  More specifically, if userspace wants to
create an object in the kernel, it should use configfs.  If the
kernel has created an object on its own, it exposes it via sysfs.
It is a deliberate non- goal for configfs to replicate sysfs
 behavior.
  
   So if the lifetime of some object is controlled by the user, it
   belongs to configfs. If, on the other hand, the lifetime is
   controlled by the kernel, it belongs to sysfs. I think that the
   trouble with e.g. luns is that they might want to behave like both
   (at least in the more automated
   approach where they are programmatically created): they are created
   by the kernel (= sysfs) but their lifetime is controlled by the
   user (=configfs).
  
   
[General Thoughts]
   
First let me restate your problem to see if I understand it.
You want to expose e.g. five LUNs.  They should eventually
 appear
in configfs as five items to configure (.../{lun0,lun1,...lun4}/.
The current configfs way to do this is to have your setup script do:
   
cd /cfg/.../mass_storage
mkdir lun0
echo blah lun0/attr1
echo blahh lun0/attr2
mkdir lun1
echo blag lun1/attr1
echo blagg lun1/attr1
...
   
I think the primary concern expressed by Andrzej is that a random
user could come along and say mkdir lun8, even though the gadget
cannot support it.  A secondary concern from Michal is that
userspace has to
   run
all of those mkdirs.  The thread has described varying solutions.
If these original directories were default_groups, you could
disallow any child creation and not require the setup script to
create directories.  Here I will point out that you *can* create
default_groups programmatically.  The default_groups pointer on
each configfs_group can be different.  -make_group() can attach
 whatever groups it wants.
If this would work, it would fit both of your concerns, but you do
not have a priori knowledge of the LUN count.
Your original email proposed that the max lun be set like
so:
   
cd /cfg/.../mass_storage
echo 5 luns_allowed
   
There are then a couple of proposed ways to enforce the limit.
Your
-create_group() idea wants luns_allowed to be able

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

[Joel Becker]

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 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 mechanism, then it's a bad user
> >>>interface.

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 goal is that it is *usable*
from a bash prompt.  So it must be that you can
create/destroy/configure objects via mkdir/rmkdir/cat/echo, but you
might have a lot of those mkdir/echo combos to configure something.
When it comes to the "user" interface, a wrapper script or library
should be converting a user intention into all that boilerplate.

> >
> >On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
> >>Well. You need only to remove the directories you created.
> >
> >My point is that there should be a way to write a script that is unaware
> >of the way function is configured, ie. which directories were created
> >and which were not.

As I stated above, I expect that tools will know which is which.
But having said that, a major goal of configfs is that it is discoverable and
transparent.  So you have to be able to distinguish between default
groups and created directories.  When you rmdir a configfs directory,
EACCESS means you don't have permission, ENOTEMPTY means there are children,
EBUSY means there is a depend or a link, and EPERM means it is a default
group.

> I get this. If you recursively rmdir each directory then you clean it
> up.
> 
> >Besides, if you rmdir lun0, is the function still supposed to work with
> >all LUNs present?  In my opinion, while gadget is bound, it should not
> >be possible to modify such things.
> 
> That is correct. The configuration should remain frozen as long as the
> gadget is active because in most cases you can't propagate the change.
> 
> >>An unbind would be  simply an unlink of the gadget  which is linked to
> >>the udc.   All configurations  remain so  you can link  it at  a later
> >>point without touching the configuration because it is as it was.
> >
> >Yes, but that's not my concern.  My concern is that I should be able to
> >put a relatively simple code in my shutdown script (or whatever) which
> >unbinds all gadgets, without knowing what kind of functions are used.
> >
> >And I'm proposing that this could be done by allowing user to just do:
> >
> > cd /cfs/...
> > rmdir gadgets/* # unbind and remove all gadgets
> > rmdir functions/*/* # unbind and remove all function instances
> > rmdir functions/*   # unload all functions
> 
> Yes, you push for simple rmdir API. That would avoid the need for an
> user land tool at some point and you end up in shell scripts.
> I'm not against it but others do have user tools to handle such things.

Yeah, user tools are expected (and should be).

> Anyway, for this to work we have to go through Joel.
> 
> > rmdir udcs/*# unload all UDCs
> 
> No, for this you still have to rmmod :)
> 
> 
> >>>I think the question is of information flow direction.  If user gives
> >>>some information to the kernel, she should be the one creating any
> >>>necessary directories.  But if the information comes from kernel to the
> >>>user, the kernel should create the structure.

This last paragraph actually describes the distinction between
configfs and sysfs.  More specifically, if userspace wants to create an
object in the kernel, it should use configfs.  If the kernel has created
an object on its own, it exposes it via sysfs.  It is a deliberate
non-goal for configfs to replicate sysfs behavior.

[General Thoughts]

First let me restate your problem to see if I understand it.
You want to expose e.g. five LUNs.  They should eventually appear
in configfs as five items to configure (.../{lun0,lun1,...lun4}/.  The
current configfs way to do this is to have your setup script do:

cd /cfg/.../mass_storage
mkdir lun0
echo blah >lun0/attr1
echo blahh >lun0/attr2
mkdir lun1
echo blag >lun1/attr1
echo blagg >lun1/attr1
...

I think the primary concern expressed by Andrzej is that a random user
could come along and say "mkdir lun8", even though the gadget cannot
support it.  A secondary concern from Michal is that userspace has to
run all of those mkdirs.  The thread has described varying solutions.
If these original directories were default_groups, you could
disallow 

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

[Joel Becker]

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 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 mechanism, then it's a bad user
 interface.

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 goal is that it is *usable*
from a bash prompt.  So it must be that you can
create/destroy/configure objects via mkdir/rmkdir/cat/echo, but you
might have a lot of those mkdir/echo combos to configure something.
When it comes to the user interface, a wrapper script or library
should be converting a user intention into all that boilerplate.

 
 On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
 Well. You need only to remove the directories you created.
 
 My point is that there should be a way to write a script that is unaware
 of the way function is configured, ie. which directories were created
 and which were not.

As I stated above, I expect that tools will know which is which.
But having said that, a major goal of configfs is that it is discoverable and
transparent.  So you have to be able to distinguish between default
groups and created directories.  When you rmdir a configfs directory,
EACCESS means you don't have permission, ENOTEMPTY means there are children,
EBUSY means there is a depend or a link, and EPERM means it is a default
group.

 I get this. If you recursively rmdir each directory then you clean it
 up.
 
 Besides, if you rmdir lun0, is the function still supposed to work with
 all LUNs present?  In my opinion, while gadget is bound, it should not
 be possible to modify such things.
 
 That is correct. The configuration should remain frozen as long as the
 gadget is active because in most cases you can't propagate the change.
 
 An unbind would be  simply an unlink of the gadget  which is linked to
 the udc.   All configurations  remain so  you can link  it at  a later
 point without touching the configuration because it is as it was.
 
 Yes, but that's not my concern.  My concern is that I should be able to
 put a relatively simple code in my shutdown script (or whatever) which
 unbinds all gadgets, without knowing what kind of functions are used.
 
 And I'm proposing that this could be done by allowing user to just do:
 
  cd /cfs/...
  rmdir gadgets/* # unbind and remove all gadgets
  rmdir functions/*/* # unbind and remove all function instances
  rmdir functions/*   # unload all functions
 
 Yes, you push for simple rmdir API. That would avoid the need for an
 user land tool at some point and you end up in shell scripts.
 I'm not against it but others do have user tools to handle such things.

Yeah, user tools are expected (and should be).

 Anyway, for this to work we have to go through Joel.
 
  rmdir udcs/*# unload all UDCs
 
 No, for this you still have to rmmod :)
 
 
 I think the question is of information flow direction.  If user gives
 some information to the kernel, she should be the one creating any
 necessary directories.  But if the information comes from kernel to the
 user, the kernel should create the structure.

This last paragraph actually describes the distinction between
configfs and sysfs.  More specifically, if userspace wants to create an
object in the kernel, it should use configfs.  If the kernel has created
an object on its own, it exposes it via sysfs.  It is a deliberate
non-goal for configfs to replicate sysfs behavior.

[General Thoughts]

First let me restate your problem to see if I understand it.
You want to expose e.g. five LUNs.  They should eventually appear
in configfs as five items to configure (.../{lun0,lun1,...lun4}/.  The
current configfs way to do this is to have your setup script do:

cd /cfg/.../mass_storage
mkdir lun0
echo blah lun0/attr1
echo blahh lun0/attr2
mkdir lun1
echo blag lun1/attr1
echo blagg lun1/attr1
...

I think the primary concern expressed by Andrzej is that a random user
could come along and say mkdir lun8, even though the gadget cannot
support it.  A secondary concern from Michal is that userspace has to
run all of those mkdirs.  The thread has described varying solutions.
If these original directories were default_groups, you could
disallow any child creation and not require the setup script to create
directories.  Here I will point out that you *can* create 

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

[Sebastian Andrzej Siewior]

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.e. acm). My point is to keep "name" in the directory name
instead having an extra attribute.


Right.  But as I've suggested:

mkdir functions/
mkdir functions//

which IMO is easier to handle in kernel (no parsing) and looks nicer in
user space.


Just posted an example. Please tell me what you think.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

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 the directory name
> instead having an extra attribute.

Right.  But as I've suggested:

mkdir functions/
mkdir functions//

which IMO is easier to handle in kernel (no parsing) and looks nicer in
user space.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpF2kwL3u0F9.pgp
Description: PGP signature

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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, aren't we just creating them?
> >
> > Please also see Michał's point about user interface.
> 
> Yeah I did. Now I'm okay with creating new directories but we should keep
> this to a minimum and encode as much information possible in directory's
> name.
> 

I think I've identified one more case where programmatic creation/removal
of configfs directories is required. There is a general agreement that
binding/unbinding the gadgets will be achieved with using symlinks between
configfs representations of udcs and gadgets. So we need to represent
udcs in configfs. Suppose that the udc driver for user's platform
is modular, e.g. s3c-hsotg.ko. Now, after:

$ modprobe s3c-hsotg

I would _very_ much like the s3c-hsotg or something similar to appear
_automatically_ under $CONFIGFS_ROOT/udcs, e.g.:

$ ls $CONFIGFS_ROOT/udcs

s3c-hsotg

If there can be more instances than 1, then probably I would want

s3c-hsotg.0 s3c-hsotg.1 

or something like that.

It would be _very_ frustrating for the user to have to guess
what name to use _if_ the relevant directory were to be
created manually with mkdir. Conversely, what would

$ rmdir s3c-hsotg

mean? Should it cause the s3c-hsotg.ko to unload?

All the above problems are elegantly solved with programmatic
creation and removal of configfs directories: in the udcs
config_group there is no make_item nor make_group, so mkdir
is not allowed, but instead the directories appear and
disappear as udcs come and go.

Andrzej


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sebastian Andrzej Siewior]

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 knowledge of the
functions.  If there is no such mechanism, then it's a bad user
interface.


On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:

Well. You need only to remove the directories you created.


My point is that there should be a way to write a script that is unaware
of the way function is configured, ie. which directories were created
and which were not.


I get this. If you recursively rmdir each directory then you clean it
up.


Besides, if you rmdir lun0, is the function still supposed to work with
all LUNs present?  In my opinion, while gadget is bound, it should not
be possible to modify such things.


That is correct. The configuration should remain frozen as long as the
gadget is active because in most cases you can't propagate the change.


An unbind would be  simply an unlink of the gadget  which is linked to
the udc.   All configurations  remain so  you can link  it at  a later
point without touching the configuration because it is as it was.


Yes, but that's not my concern.  My concern is that I should be able to
put a relatively simple code in my shutdown script (or whatever) which
unbinds all gadgets, without knowing what kind of functions are used.

And I'm proposing that this could be done by allowing user to just do:

cd /cfs/...
rmdir gadgets/* # unbind and remove all gadgets
rmdir functions/*/* # unbind and remove all function instances
rmdir functions/*   # unload all functions


Yes, you push for simple rmdir API. That would avoid the need for an
user land tool at some point and you end up in shell scripts.
I'm not against it but others do have user tools to handle such things.
Anyway, for this to work we have to go through Joel.


rmdir udcs/*# unload all UDCs


No, for this you still have to rmmod :)



I think the question is of information flow direction.  If user gives
some information to the kernel, she should be the one creating any
necessary directories.  But if the information comes from kernel to the
user, the kernel should create the structure.



Yes that is a point. But the "name" can go away if we use it in the
directory name. That is what other configfs user do. The same is true
for luns for instance. I just want to avoid adding features because we
do something different compared to every other configfs user.


You've lost me here.  What are we talking about again?  What “name” are
you referring to?


   -
/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 the directory name
instead having an extra attribute.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

> 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 mechanism, then it's a bad user
>> interface.

On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
> Well. You need only to remove the directories you created.

My point is that there should be a way to write a script that is unaware
of the way function is configured, ie. which directories were created
and which were not.

Besides, if you rmdir lun0, is the function still supposed to work with
all LUNs present?  In my opinion, while gadget is bound, it should not
be possible to modify such things.

> An unbind would be  simply an unlink of the gadget  which is linked to
> the udc.   All configurations  remain so  you can link  it at  a later
> point without touching the configuration because it is as it was.

Yes, but that's not my concern.  My concern is that I should be able to
put a relatively simple code in my shutdown script (or whatever) which
unbinds all gadgets, without knowing what kind of functions are used.

And I'm proposing that this could be done by allowing user to just do:

cd /cfs/...
rmdir gadgets/* # unbind and remove all gadgets
rmdir functions/*/* # unbind and remove all function instances
rmdir functions/*   # unload all functions
rmdir udcs/*# unload all UDCs

>> I think the question is of information flow direction.  If user gives
>> some information to the kernel, she should be the one creating any
>> necessary directories.  But if the information comes from kernel to the
>> user, the kernel should create the structure.

> Yes that is a point. But the "name" can go away if we use it in the
> directory name. That is what other configfs user do. The same is true
> for luns for instance. I just want to avoid adding features because we
> do something different compared to every other configfs user.

You've lost me here.  What are we talking about again?  What “name” are
you referring to?

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpd4Yhe2VOdP.pgp
Description: PGP signature

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

[Sebastian Andrzej Siewior]

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:
- 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 do we know everything before bind or we don't?


After some sleep I think we do.


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?



What name shall the user use? How to know which user-created directory
should correspond to which actual interface? If there are, say,
3 interfaces, what would:

$ mkdir interface873246

mean?

And in general, what would

$ mkdir rykcq1234

mean?

Let's go one directory deeper in the hierarchy and suppose there is
no programmatic directories creation. So we

$ cd interface

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 we just creating them?

Please also see Michał's point about user interface.


Yeah I did. Now I'm okay with creating new directories but we should
keep this to a minimum and encode as much information possible in
directory's name.



Andrzej


Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sebastian Andrzej Siewior]

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 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 mechanism, then it's a bad user
interface.


Well. You need only to remove the directories you created. An unbind
would be simply an unlink of the gadget which is linked to the udc.
All configurations remain so you can link it at a later point without
touching the configuration because it is as it was.


I understand the need for things that pop later like interfaceXX but
couldn't the user manually create them if he needs them?


I think the question is of information flow direction.  If user gives
some information to the kernel, she should be the one creating any
necessary directories.  But if the information comes from kernel to the
user, the kernel should create the structure.


Yes that is a point. But the "name" can go away if we use it in the
directory name. That is what other configfs user do. The same is true
for luns for instance. I just want to avoid adding features because we
do something different compared to every other configfs user.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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 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 do we know everything before bind or we don't?

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

What name shall the user use? How to know which user-created directory
should correspond to which actual interface? If there are, say,
3 interfaces, what would:

$ mkdir interface873246

mean?

And in general, what would

$ mkdir rykcq1234

mean?

Let's go one directory deeper in the hierarchy and suppose there is
no programmatic directories creation. So we

$ cd interface

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 we just creating them?

Please also see Michał's point about user interface.

Andrzej


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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 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 do we know everything before bind or we don't?

  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?
 

What name shall the user use? How to know which user-created directory
should correspond to which actual interface? If there are, say,
3 interfaces, what would:

$ mkdir interface873246

mean?

And in general, what would

$ mkdir rykcq1234

mean?

Let's go one directory deeper in the hierarchy and suppose there is
no programmatic directories creation. So we

$ cd interfacesomething

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 we just creating them?

Please also see Michał's point about user interface.

Andrzej


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sebastian Andrzej Siewior]

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 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 mechanism, then it's a bad user
interface.


Well. You need only to remove the directories you created. An unbind
would be simply an unlink of the gadget which is linked to the udc.
All configurations remain so you can link it at a later point without
touching the configuration because it is as it was.


I understand the need for things that pop later like interfaceXX but
couldn't the user manually create them if he needs them?


I think the question is of information flow direction.  If user gives
some information to the kernel, she should be the one creating any
necessary directories.  But if the information comes from kernel to the
user, the kernel should create the structure.


Yes that is a point. But the name can go away if we use it in the
directory name. That is what other configfs user do. The same is true
for luns for instance. I just want to avoid adding features because we
do something different compared to every other configfs user.

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sebastian Andrzej Siewior]

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:
- 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 do we know everything before bind or we don't?


After some sleep I think we do.


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?



What name shall the user use? How to know which user-created directory
should correspond to which actual interface? If there are, say,
3 interfaces, what would:

$ mkdir interface873246

mean?

And in general, what would

$ mkdir rykcq1234

mean?

Let's go one directory deeper in the hierarchy and suppose there is
no programmatic directories creation. So we

$ cd interfacesomething

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 we just creating them?

Please also see Michał's point about user interface.


Yeah I did. Now I'm okay with creating new directories but we should
keep this to a minimum and encode as much information possible in
directory's name.



Andrzej


Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

 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 mechanism, then it's a bad user
 interface.

On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
 Well. You need only to remove the directories you created.

My point is that there should be a way to write a script that is unaware
of the way function is configured, ie. which directories were created
and which were not.

Besides, if you rmdir lun0, is the function still supposed to work with
all LUNs present?  In my opinion, while gadget is bound, it should not
be possible to modify such things.

 An unbind would be  simply an unlink of the gadget  which is linked to
 the udc.   All configurations  remain so  you can link  it at  a later
 point without touching the configuration because it is as it was.

Yes, but that's not my concern.  My concern is that I should be able to
put a relatively simple code in my shutdown script (or whatever) which
unbinds all gadgets, without knowing what kind of functions are used.

And I'm proposing that this could be done by allowing user to just do:

cd /cfs/...
rmdir gadgets/* # unbind and remove all gadgets
rmdir functions/*/* # unbind and remove all function instances
rmdir functions/*   # unload all functions
rmdir udcs/*# unload all UDCs

 I think the question is of information flow direction.  If user gives
 some information to the kernel, she should be the one creating any
 necessary directories.  But if the information comes from kernel to the
 user, the kernel should create the structure.

 Yes that is a point. But the name can go away if we use it in the
 directory name. That is what other configfs user do. The same is true
 for luns for instance. I just want to avoid adding features because we
 do something different compared to every other configfs user.

You've lost me here.  What are we talking about again?  What “name” are
you referring to?

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--

pgpd4Yhe2VOdP.pgp
Description: PGP signature

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

[Sebastian Andrzej Siewior]

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 knowledge of the
functions.  If there is no such mechanism, then it's a bad user
interface.


On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:

Well. You need only to remove the directories you created.


My point is that there should be a way to write a script that is unaware
of the way function is configured, ie. which directories were created
and which were not.


I get this. If you recursively rmdir each directory then you clean it
up.


Besides, if you rmdir lun0, is the function still supposed to work with
all LUNs present?  In my opinion, while gadget is bound, it should not
be possible to modify such things.


That is correct. The configuration should remain frozen as long as the
gadget is active because in most cases you can't propagate the change.


An unbind would be  simply an unlink of the gadget  which is linked to
the udc.   All configurations  remain so  you can link  it at  a later
point without touching the configuration because it is as it was.


Yes, but that's not my concern.  My concern is that I should be able to
put a relatively simple code in my shutdown script (or whatever) which
unbinds all gadgets, without knowing what kind of functions are used.

And I'm proposing that this could be done by allowing user to just do:

cd /cfs/...
rmdir gadgets/* # unbind and remove all gadgets
rmdir functions/*/* # unbind and remove all function instances
rmdir functions/*   # unload all functions


Yes, you push for simple rmdir API. That would avoid the need for an
user land tool at some point and you end up in shell scripts.
I'm not against it but others do have user tools to handle such things.
Anyway, for this to work we have to go through Joel.


rmdir udcs/*# unload all UDCs


No, for this you still have to rmmod :)



I think the question is of information flow direction.  If user gives
some information to the kernel, she should be the one creating any
necessary directories.  But if the information comes from kernel to the
user, the kernel should create the structure.



Yes that is a point. But the name can go away if we use it in the
directory name. That is what other configfs user do. The same is true
for luns for instance. I just want to avoid adding features because we
do something different compared to every other configfs user.


You've lost me here.  What are we talking about again?  What “name” are
you referring to?


   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 point is to keep name in the directory name
instead having an extra attribute.

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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 we just creating them?
 
  Please also see Michał's point about user interface.
 
 Yeah I did. Now I'm okay with creating new directories but we should keep
 this to a minimum and encode as much information possible in directory's
 name.
 

I think I've identified one more case where programmatic creation/removal
of configfs directories is required. There is a general agreement that
binding/unbinding the gadgets will be achieved with using symlinks between
configfs representations of udcs and gadgets. So we need to represent
udcs in configfs. Suppose that the udc driver for user's platform
is modular, e.g. s3c-hsotg.ko. Now, after:

$ modprobe s3c-hsotg

I would _very_ much like the s3c-hsotg or something similar to appear
_automatically_ under $CONFIGFS_ROOT/udcs, e.g.:

$ ls $CONFIGFS_ROOT/udcs

s3c-hsotg

If there can be more instances than 1, then probably I would want

s3c-hsotg.0 s3c-hsotg.1 

or something like that.

It would be _very_ frustrating for the user to have to guess
what name to use _if_ the relevant directory were to be
created manually with mkdir. Conversely, what would

$ rmdir s3c-hsotg

mean? Should it cause the s3c-hsotg.ko to unload?

All the above problems are elegantly solved with programmatic
creation and removal of configfs directories: in the udcs
config_group there is no make_item nor make_group, so mkdir
is not allowed, but instead the directories appear and
disappear as udcs come and go.

Andrzej


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

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 point is to keep name in the directory name
 instead having an extra attribute.

Right.  But as I've suggested:

mkdir functions/function-name
mkdir functions/function-name/common-name

which IMO is easier to handle in kernel (no parsing) and looks nicer in
user space.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--

pgpF2kwL3u0F9.pgp
Description: PGP signature

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

[Sebastian Andrzej Siewior]

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 contains the name of the
function (i.e. acm). My point is to keep name in the directory name
instead having an extra attribute.


Right.  But as I've suggested:

mkdir functions/function-name
mkdir functions/function-name/common-name

which IMO is easier to handle in kernel (no parsing) and looks nicer in
user space.


Just posted an example. Please tell me what you think.

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Nicholas A. Bellinger]

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 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 (from
> > ):
> >
> > LUN 0: There is one LUN which is required to exist in every
> > target: zero. The logical unit with LUN zero is special in that
> > it must implement a few specific commands, most notably Report
> > LUNs, which is how an initiator can find out all the other LUNs
> > in the target. But LUN zero need not provide any other services,
> > such as a storage volume.
> >
> > That's why I proposed solution where one needs to have continuous
> > numbering of LUNs.  I'm not an expert on SCSI though.
> 
> Let me quote "4.6.4 Minimum LUN addressing requirements" of SAM4:
> 
> | All SCSI target devices shall support LUN 0 (i.e., 
> | h) or the REPORT LUNS well-known logical unit. For SCSI
> | target devices that support the hierarchical addressing model the LUN
> | 0 or the REPORT LUNS well-known logical unit shall be the logical
> | unit that an application client addresses to determine
> | information about the SCSI target device and the logical units
> | contained within the SCSI target device.
> 
> Nab, I think not having LUN0 configured as long as REPORT LUNS says
> which luns are available is fine. Target seems to work on linux without
> it and SAM4 does no claim otherwise unless I miss interpret it. Any
> opinion on this from your side?
> 

So we use a special RAMDISK-MCP @ target_core_device.c:g_lun0_dev along
with a se_lun (located @ se_portal_group->tpg_virt_lun0) to always
service REPORT_LUNS to LUN=0, regardless of LUN=0 configfs fabric
endpoint layout.

Note this happens within target_core_device.c:transport_lookup_cmd_lun()
once no active se_node_acl->device_list[unpacked_lun] entry can be
located.

> >
> >> With the tcm gadget I get:
> >>
> >> |scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0
> >> ANSI: 5
> >> |scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0
> >> ANSI: 5
> >>
> >> You notice :2 and :3 instead :0 and :1. While should be there something
> >> wrong with this?
> >
> > It may be that it works on Linux but fails on some other systems (or
> > even older Linux kernels).  Like I've said, I'm not SCSI expert, so my
> > knowledge of it is (embarrassingly) minimal.
> 
> Sure but still. You limit the user to create lunX folders where X can
> be 0..255 for instance. If the user chooses not create lun0, why force
> him?
> 

It's certainly easier for the user if REPORT_LUNS always 'just works' to
LUN=0.

--nab


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

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 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 mechanism, then it's a bad user
interface.

> I understand the need for things that pop later like interfaceXX but
> couldn't the user manually create them if he needs them?

I think the question is of information flow direction.  If user gives
some information to the kernel, she should be the one creating any
necessary directories.  But if the information comes from kernel to the
user, the kernel should create the structure.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpDHfGOEwJxW.pgp
Description: PGP signature

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

[Sebastian Andrzej Siewior]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sebastian Andrzej Siewior]

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


That's not what Wikipedia claims though (from
):

LUN 0: There is one LUN which is required to exist in every
target: zero. The logical unit with LUN zero is special in that
it must implement a few specific commands, most notably Report
LUNs, which is how an initiator can find out all the other LUNs
in the target. But LUN zero need not provide any other services,
such as a storage volume.

That's why I proposed solution where one needs to have continuous
numbering of LUNs.  I'm not an expert on SCSI though.


Let me quote "4.6.4 Minimum LUN addressing requirements" of SAM4:

| All SCSI target devices shall support LUN 0 (i.e., 
| h) or the REPORT LUNS well-known logical unit. For SCSI
| target devices that support the hierarchical addressing model the LUN
| 0 or the REPORT LUNS well-known logical unit shall be the logical
| unit that an application client addresses to determine
| information about the SCSI target device and the logical units
| contained within the SCSI target device.

Nab, I think not having LUN0 configured as long as REPORT LUNS says
which luns are available is fine. Target seems to work on linux without
it and SAM4 does no claim otherwise unless I miss interpret it. Any
opinion on this from your side?




With the tcm gadget I get:

|scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0
ANSI: 5
|scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0
ANSI: 5

You notice :2 and :3 instead :0 and :1. While should be there something
wrong with this?


It may be that it works on Linux but fails on some other systems (or
even older Linux kernels).  Like I've said, I'm not SCSI expert, so my
knowledge of it is (embarrassingly) minimal.


Sure but still. You limit the user to create lunX folders where X can
be 0..255 for instance. If the user chooses not create lun0, why force
him?

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Michal Nazarewicz]

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-usb/msg75118.html)

I agree, and this is orthogonal to exact API used by configfs gadget.

I may be missing something about configfs, but the way I see it, lack of
such functions is a mistake in the configfs API.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpi644TjVx56.pgp
Description: PGP signature

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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



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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC][PATCH] fs: configfs: programmatically create config groups

[Michal Nazarewicz]

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.
 (http://www.spinics.net/lists/linux-usb/msg75118.html)

I agree, and this is orthogonal to exact API used by configfs gadget.

I may be missing something about configfs, but the way I see it, lack of
such functions is a mistake in the configfs API.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--

pgpi644TjVx56.pgp
Description: PGP signature

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

[Sebastian Andrzej Siewior]

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


That's not what Wikipedia claims though (from
http://en.wikipedia.org/wiki/Logical_Unit_Number):

LUN 0: There is one LUN which is required to exist in every
target: zero. The logical unit with LUN zero is special in that
it must implement a few specific commands, most notably Report
LUNs, which is how an initiator can find out all the other LUNs
in the target. But LUN zero need not provide any other services,
such as a storage volume.

That's why I proposed solution where one needs to have continuous
numbering of LUNs.  I'm not an expert on SCSI though.


Let me quote 4.6.4 Minimum LUN addressing requirements of SAM4:

| All SCSI target devices shall support LUN 0 (i.e., 
| h) or the REPORT LUNS well-known logical unit. For SCSI
| target devices that support the hierarchical addressing model the LUN
| 0 or the REPORT LUNS well-known logical unit shall be the logical
| unit that an application client addresses to determine
| information about the SCSI target device and the logical units
| contained within the SCSI target device.

Nab, I think not having LUN0 configured as long as REPORT LUNS says
which luns are available is fine. Target seems to work on linux without
it and SAM4 does no claim otherwise unless I miss interpret it. Any
opinion on this from your side?




With the tcm gadget I get:

|scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0
ANSI: 5
|scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0
ANSI: 5

You notice :2 and :3 instead :0 and :1. While should be there something
wrong with this?


It may be that it works on Linux but fails on some other systems (or
even older Linux kernels).  Like I've said, I'm not SCSI expert, so my
knowledge of it is (embarrassingly) minimal.


Sure but still. You limit the user to create lunX folders where X can
be 0..255 for instance. If the user chooses not create lun0, why force
him?

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sebastian Andrzej Siewior]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

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 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 mechanism, then it's a bad user
interface.

 I understand the need for things that pop later like interfaceXX but
 couldn't the user manually create them if he needs them?

I think the question is of information flow direction.  If user gives
some information to the kernel, she should be the one creating any
necessary directories.  But if the information comes from kernel to the
user, the kernel should create the structure.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--

pgpDHfGOEwJxW.pgp
Description: PGP signature

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

[Nicholas A. Bellinger]

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 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 (from
  http://en.wikipedia.org/wiki/Logical_Unit_Number):
 
  LUN 0: There is one LUN which is required to exist in every
  target: zero. The logical unit with LUN zero is special in that
  it must implement a few specific commands, most notably Report
  LUNs, which is how an initiator can find out all the other LUNs
  in the target. But LUN zero need not provide any other services,
  such as a storage volume.
 
  That's why I proposed solution where one needs to have continuous
  numbering of LUNs.  I'm not an expert on SCSI though.
 
 Let me quote 4.6.4 Minimum LUN addressing requirements of SAM4:
 
 | All SCSI target devices shall support LUN 0 (i.e., 
 | h) or the REPORT LUNS well-known logical unit. For SCSI
 | target devices that support the hierarchical addressing model the LUN
 | 0 or the REPORT LUNS well-known logical unit shall be the logical
 | unit that an application client addresses to determine
 | information about the SCSI target device and the logical units
 | contained within the SCSI target device.
 
 Nab, I think not having LUN0 configured as long as REPORT LUNS says
 which luns are available is fine. Target seems to work on linux without
 it and SAM4 does no claim otherwise unless I miss interpret it. Any
 opinion on this from your side?
 

So we use a special RAMDISK-MCP @ target_core_device.c:g_lun0_dev along
with a se_lun (located @ se_portal_group-tpg_virt_lun0) to always
service REPORT_LUNS to LUN=0, regardless of LUN=0 configfs fabric
endpoint layout.

Note this happens within target_core_device.c:transport_lookup_cmd_lun()
once no active se_node_acl-device_list[unpacked_lun] entry can be
located.

 
  With the tcm gadget I get:
 
  |scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0
  ANSI: 5
  |scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0
  ANSI: 5
 
  You notice :2 and :3 instead :0 and :1. While should be there something
  wrong with this?
 
  It may be that it works on Linux but fails on some other systems (or
  even older Linux kernels).  Like I've said, I'm not SCSI expert, so my
  knowledge of it is (embarrassingly) minimal.
 
 Sure but still. You limit the user to create lunX folders where X can
 be 0..255 for instance. If the user chooses not create lun0, why force
 him?
 

It's certainly easier for the user if REPORT_LUNS always 'just works' to
LUN=0.

--nab


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sebastian Andrzej Siewior]

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

Example:

$ echo 3>   /cfg//mass_storage/luns

causes

/cfg/../mass_storage/lun0
/cfg/../mass_storage/lun1
/cfg/../mass_storage/lun2


On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:

I though we did not want the luns file but instead use

mkdir /cfg/../mass_storage/lun0
mkdir /cfg/../mass_storage/lun1

directly.


I think that's suboptimal, and we can do better.  There are too many
corner cases (ie. what if user does “mkdir lun7” without the previous
luns?), it adds complexity to the kernel (ie. parsing of the name), and
the thing is overly complicated for user (“echo 5>  nluns” is much nicer
than having to create 5 directories).


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.
With the tcm gadget I get:

|scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0 
ANSI: 5
|scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0 
ANSI: 5


You notice :2 and :3 instead :0 and :1. While should be there something
wrong with this?

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

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 (from
):

LUN 0: There is one LUN which is required to exist in every
target: zero. The logical unit with LUN zero is special in that
it must implement a few specific commands, most notably Report
LUNs, which is how an initiator can find out all the other LUNs
in the target. But LUN zero need not provide any other services,
such as a storage volume.

That's why I proposed solution where one needs to have continuous
numbering of LUNs.  I'm not an expert on SCSI though.

> With the tcm gadget I get:
>
> |scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0 
> ANSI: 5
> |scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0 
> ANSI: 5
>
> You notice :2 and :3 instead :0 and :1. While should be there something
> wrong with this?

It may be that it works on Linux but fails on some other systems (or
even older Linux kernels).  Like I've said, I'm not SCSI expert, so my
knowledge of it is (embarrassingly) minimal.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpGFqOFT9Awy.pgp
Description: PGP signature

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

[Michal Nazarewicz]

> 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.
>>
>> Example:
>>
>> $ echo 3>  /cfg//mass_storage/luns
>>
>> causes
>>
>> /cfg/../mass_storage/lun0
>> /cfg/../mass_storage/lun1
>> /cfg/../mass_storage/lun2

On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
> I though we did not want the luns file but instead use
>
> mkdir /cfg/../mass_storage/lun0
> mkdir /cfg/../mass_storage/lun1
>
> directly.

I think that's suboptimal, and we can do better.  There are too many
corner cases (ie. what if user does “mkdir lun7” without the previous
luns?), it adds complexity to the kernel (ie. parsing of the name), and
the thing is overly complicated for user (“echo 5 > nluns” is much nicer
than having to create 5 directories).

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpbwO2ESPE55.pgp
Description: PGP signature

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

[Sebastian Andrzej Siewior]

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.

Example:

$ echo 3>  /cfg//mass_storage/luns

causes

/cfg/../mass_storage/lun0
/cfg/../mass_storage/lun1
/cfg/../mass_storage/lun2


I though we did not want the luns file but instead use

mkdir /cfg/../mass_storage/lun0
mkdir /cfg/../mass_storage/lun1

directly.


to be created. Yet

$ mkdir /cfg//mass_storage/

should not be allowed.

With create_group exported it is very easily achieved: make_group and make_item
are set to NULL in mass_storage's config_group, yet the kernel can
create_groups at will.

I kindly ask for comments. In particular, I would like to discuss
if this is the right approach. A counterpart to remove config groups
is also required. It is not implemented in this patch, though. What are
your opinions?


Could you please at the tcm gadget? This is a mass storage gadget using
target as backend and target is using configfs. Here is a snippet how
you setup it:

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

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

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 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.
>
> Example:
>
> $ echo 3 > /cfg//mass_storage/luns
>
> causes
>
> /cfg/../mass_storage/lun0
> /cfg/../mass_storage/lun1
> /cfg/../mass_storage/lun2
>
> to be created. Yet
>
> $ mkdir /cfg//mass_storage/
>
> should not be allowed.
>
> With create_group exported it is very easily achieved: make_group and 
> make_item
> are set to NULL in mass_storage's config_group, yet the kernel can
> create_groups at will.

I think the above description should be part of the commit message. :)

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpAM5Vcctf6D.pgp
Description: PGP signature

[RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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.

Example:

$ echo 3 > /cfg//mass_storage/luns

causes

/cfg/../mass_storage/lun0
/cfg/../mass_storage/lun1
/cfg/../mass_storage/lun2

to be created. Yet

$ mkdir /cfg//mass_storage/

should not be allowed.

With create_group exported it is very easily achieved: make_group and make_item
are set to NULL in mass_storage's config_group, yet the kernel can
create_groups at will.

I kindly ask for comments. In particular, I would like to discuss
if this is the right approach. A counterpart to remove config groups
is also required. It is not implemented in this patch, though. What are
your opinions?

Andrzej Pietrasiewicz (1):
  fs: configfs: allow other kernel parts to programmatically create
config groups

 fs/configfs/dir.c|5 +++--
 include/linux/configfs.h |2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

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.

Example:

$ echo 3  /cfg//mass_storage/luns

causes

/cfg/../mass_storage/lun0
/cfg/../mass_storage/lun1
/cfg/../mass_storage/lun2

to be created. Yet

$ mkdir /cfg//mass_storage/any name

should not be allowed.

With create_group exported it is very easily achieved: make_group and make_item
are set to NULL in mass_storage's config_group, yet the kernel can
create_groups at will.

I kindly ask for comments. In particular, I would like to discuss
if this is the right approach. A counterpart to remove config groups
is also required. It is not implemented in this patch, though. What are
your opinions?

Andrzej Pietrasiewicz (1):
  fs: configfs: allow other kernel parts to programmatically create
config groups

 fs/configfs/dir.c|5 +++--
 include/linux/configfs.h |2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

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

 Example:

 $ echo 3  /cfg//mass_storage/luns

 causes

 /cfg/../mass_storage/lun0
 /cfg/../mass_storage/lun1
 /cfg/../mass_storage/lun2

 to be created. Yet

 $ mkdir /cfg//mass_storage/any name

 should not be allowed.

 With create_group exported it is very easily achieved: make_group and 
 make_item
 are set to NULL in mass_storage's config_group, yet the kernel can
 create_groups at will.

I think the above description should be part of the commit message. :)

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--

pgpAM5Vcctf6D.pgp
Description: PGP signature

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

[Sebastian Andrzej Siewior]

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.

Example:

$ echo 3  /cfg//mass_storage/luns

causes

/cfg/../mass_storage/lun0
/cfg/../mass_storage/lun1
/cfg/../mass_storage/lun2


I though we did not want the luns file but instead use

mkdir /cfg/../mass_storage/lun0
mkdir /cfg/../mass_storage/lun1

directly.


to be created. Yet

$ mkdir /cfg//mass_storage/any name

should not be allowed.

With create_group exported it is very easily achieved: make_group and make_item
are set to NULL in mass_storage's config_group, yet the kernel can
create_groups at will.

I kindly ask for comments. In particular, I would like to discuss
if this is the right approach. A counterpart to remove config groups
is also required. It is not implemented in this patch, though. What are
your opinions?


Could you please at the tcm gadget? This is a mass storage gadget using
target as backend and target is using configfs. Here is a snippet how
you setup it:

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

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Nazarewicz]

 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.

 Example:

 $ echo 3  /cfg//mass_storage/luns

 causes

 /cfg/../mass_storage/lun0
 /cfg/../mass_storage/lun1
 /cfg/../mass_storage/lun2

On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
 I though we did not want the luns file but instead use

 mkdir /cfg/../mass_storage/lun0
 mkdir /cfg/../mass_storage/lun1

 directly.

I think that's suboptimal, and we can do better.  There are too many
corner cases (ie. what if user does “mkdir lun7” without the previous
luns?), it adds complexity to the kernel (ie. parsing of the name), and
the thing is overly complicated for user (“echo 5  nluns” is much nicer
than having to create 5 directories).

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--

pgpbwO2ESPE55.pgp
Description: PGP signature

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

[Michal Nazarewicz]

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 (from
http://en.wikipedia.org/wiki/Logical_Unit_Number):

LUN 0: There is one LUN which is required to exist in every
target: zero. The logical unit with LUN zero is special in that
it must implement a few specific commands, most notably Report
LUNs, which is how an initiator can find out all the other LUNs
in the target. But LUN zero need not provide any other services,
such as a storage volume.

That's why I proposed solution where one needs to have continuous
numbering of LUNs.  I'm not an expert on SCSI though.

 With the tcm gadget I get:

 |scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0 
 ANSI: 5
 |scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0 
 ANSI: 5

 You notice :2 and :3 instead :0 and :1. While should be there something
 wrong with this?

It may be that it works on Linux but fails on some other systems (or
even older Linux kernels).  Like I've said, I'm not SCSI expert, so my
knowledge of it is (embarrassingly) minimal.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--

pgpGFqOFT9Awy.pgp
Description: PGP signature

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

[Sebastian Andrzej Siewior]

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

Example:

$ echo 3   /cfg//mass_storage/luns

causes

/cfg/../mass_storage/lun0
/cfg/../mass_storage/lun1
/cfg/../mass_storage/lun2


On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:

I though we did not want the luns file but instead use

mkdir /cfg/../mass_storage/lun0
mkdir /cfg/../mass_storage/lun1

directly.


I think that's suboptimal, and we can do better.  There are too many
corner cases (ie. what if user does “mkdir lun7” without the previous
luns?), it adds complexity to the kernel (ie. parsing of the name), and
the thing is overly complicated for user (“echo 5  nluns” is much nicer
than having to create 5 directories).


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.
With the tcm gadget I get:

|scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0 
ANSI: 5
|scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0 
ANSI: 5


You notice :2 and :3 instead :0 and :1. While should be there something
wrong with this?

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/