> The difference between these two is the type, which then leads to > differently named services. Quickly looking at the code seems to > indicate that struct ethernet_data could be used for both regular > ethernet and gadget as the internal data should be very much the same. > Start e.g. by initially copying the functions, then see what the > difference is and factor out the common parts before sending the > implementation to the list?
Based on your comments, I'm considering breaking out the Gadget related code into a *separate* file and plugin. This should help keep the code logically separate and allow it to diverge from the base ethernet plugin implementation as necessary (although initially I would not expect it to be too different). > > The eth_tethering flag is just data needed internally. When tethering is > enabled, it's enabled per technology, i.e. all devices belonging to the > technology are then tethering. Since Gadget is a distinct technology from "ethernet" should I assume that I need to create a separate gadget_tethering flag that behaves similarly for the one for ethernet technology? > > Another thing that seems to be different is the "auto-enabling" regular > ethernet has. With regular ethernet when plugging in a cable, a carrier > is detected and that's enough to enable the Wired technology at once. > With USB gadget this behavior seems to be opposite, merely loading the > gadget side kernel support indicates that a connection is present, this > even without a cable attached. Thus we can not do the same kind of > auto-enabling that ethernet has. There is a known issue in the USB kernel code whereby the kernel does not generate any events (e.g. ones captured by udev) for USB Gadget devices when a cable is inserted/removed. I'm not sure about the events we can rely on for Gadget interfaces. I'll try to understand and capture it's current behavior but there may be some limitations that are not easy to work-around. I'm not looking to introduce additional changes here that impact the existing behavior unless there is a compelling reason to do so and it's feasible without a large tear-up. Glenn _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
