Re: [RFC 0/2] USB gadget - configfs

[Joel Becker]

On Mon, Aug 20, 2012 at 10:53:42AM +0200, Andrzej Pietrasiewicz wrote:
> Hello Joel,
> 
> Thanks for your reply.
> 
> On Monday, August 20, 2012 8:00 AM Joel Becker wrote:
> > 
> > 	I think what you want here is a symlink.  Create a directory
> > high in the tree called 'ready' or 'available', and when you want to
> > lock the device in place, symlink it into that directory.  This will pin
> > the item.  You can also make use of the ->allow_link() and ->drop_link()
> > callbacks to prevent symlinking an item until it is fully configured,
> > and prevent unlinking an item that is in use.
> > 
> >   $ ln -s /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0 \
> >         /cfg/usb-function-gadget/ready/
> > 
> 
> Is using the userspace program "ln" the way you suggest doing it? Or just
> a suggestion about what should be the link target and the link name?

You could use ln, you could use symlink(2), or some other method.  The
symlink itself is the goal.  The names are my best guess at how your
system is laid out; it's not meant to pick a name for you.

> If links are to be created from userspace then some other process can race
> us and rmdir "lun0" before ln is called, can't it?

Yes, but that same process can race the write of '1' to "connect" as well,
right?  I don't see the difference.

> And a question to you as the creator of configfs: is using symlinks to
> prevent config item deletion their intended purpose? How do you like it?

	Yes, it is an intended use.  Another intended use is
simplification of access.  For example, if you have all connected things
in the "ready" subdirectory, you don't have to go scanning all the
"connect" files to find them.

Joel

-- 

"I always thought the hardest questions were those I could not answer.
 Now I know they are the ones I can never ask."
			- Charlie Watkins

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