On Thu, 18 Apr 2013, Andrzej Pietrasiewicz wrote: > On Wednesday, April 17, 2013 6:46 PM Alan Stern wrote: > > On Wed, 17 Apr 2013, Andrzej Pietrasiewicz wrote: > > > > > The procedure of setting a gadget up with configfs is like this: > > > > > > 1) create the gadget directory > > > 2) create functions directories corresponding to functions to be used > > > by the gadget > > > 3) create configurations directories > > > > ... > > > > > 4) create symbolic links in configurations' directories, pointing to > > > appropriate functions' directories > > > 5) In the gadget directory echo <udc_name> > UDC > > > > > > Now, what you suggest is that a net device is registered only at step > > > 5) above. But changing a device address is possible only _after_ the > > > device is registered. Which is in contradiction with the assumptions > > above. > > > > It doesn't have to be. You don't actually have to change the address when > > the attribute is written. In fact, since the network link doesn't exist > > at this point, there _is_ no address to change. > > > > > And in practice you would have a directory structure like this: > > > > > > . > > > . > > > . > > > ./functions > > > ./functions/ncm.usb0 > > > ./functions/ncm.usb0/ifname > > > ./functions/ncm.usb0/qmult > > > ./functions/ncm.usb0/host_addr > > > ./functions/ncm.usb0/dev_addr > > > . > > > . > > > . > > > > > > Where ifname, qmult and host_addr can be written to before the gadget > > > is bound, but writing to dev_addr in such a situation would result in > > > ENODEV. > > > > If you still want to persist with this approach, you can do it in a way > > that doesn't require the network interface to be registered before the > > gadget is bound. > > > > Simply store the strings written to host_addr and dev_addr. Don't try to > > do anything with them -- in particular, don't try to change the addresses > > associated with a nonexistent network interface. Then later on, when the > > gadget is bound and you have registered the network interface, set the > > address values that were saved earlier. (Of course, when you do this > > you'll be racing with udev and NetworkManager, which will try to set their > > own values for the network addresses. That's the price you pay for > > following this peculiar approach.) > > > > By host_addr and dev_addr I meant link layer addresses (MAC addresses), not > IP addresses. Exactly these names have been used for module parameters so > far > and I thought it would be understood. Everything I wrote above still stands, except the part about racing with udev and NetworkManager. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
