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