On 08/21/2012 10:19 AM, Andrzej Pietrasiewicz wrote:
@Joel: However, I am wondering if it would make sense to get rid of the "connect" (or "ready", if you will) attribute altogether and instead use symlinks: when a user wants to make the gadget ready, they do an ln -s, when they want to unbind the gadget they remove the link. What do you think?
I started the "ready" attribue and this symlink sounds reasonable.
There is one more thing to it, I believe; it is how to associate udc's with gadgets. Perhaps the most convenient way is not needing to do it explicitly at all: either some udc is found and the gadget is bound to it,
I would prefer explicit binding. Right now first one wins which not good.
or not. However, I am wondering if something in the spirit of "1984" can happen: all udcs are equal but some udcs are more equal than others? So sometimes the user might be interested in binding their gadget to a particular udc, or at least to a particular kind of udc (no matter which one if there are more than one of its kind).
Do you have a use case for this? I have a simple one: A phone with two plugs. You select on the gui storage and network on plug #1 and serial on plug #2. If you want to obey the selection you have to always know which UDC ends up on plug #1 and which on #2. That means the user _always_ wants to bind it to a particular UDC.
And the question is, whether we want only explicit association with udc, only implicit association with udc, or both?
/usb-gadget/gadgets/g1 /usb-gadget/udcs/udc1 /usb-gadget/udcs/udc2 and now symlink g1 into udc1 and or udc2 g1 is created by the user and can be named however he wants it to be. udc1 can be the device name which is unique as well and always the same thing. It can have a property which distinguish it from udc2 like memory address or something.
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/