> I would prefer separate "gadget" and "ethernet". This way it is easier > to distinguish them in possible UI etc.
The service name starts with the network name, so are you suggesting the creation a new network type, CONNMAN_NETWORK_TYPE_GADGET? On Thu, Jan 23, 2014 at 3:43 AM, Jukka Rissanen < [email protected]> wrote: > Hi Glenn, > > On ke, 2014-01-22 at 20:42 -0500, Glenn Schmottlach wrote: > > > PPP links have not really ever been considered and nobody has any > > > current plans to support them either. > > > > I saw what (might) appear to be the start of a PPP plugin in the > > Connman repo in the "scripts" folder under libppp-plugin.c. Do you > > know the intention/purpose of that plug-in? It appears to use the PPPD > > library to implement some features related to PPP. > > > > > The working assumption once upon a time was to use the device running > > > ConnMan as the one tethering its connection to a laptop nearby, thus > the > > > implementation where ConnMan shares its connection to others. > > > > I understand this use case and assume you realize my use-case is the > > polar-opposite. In my scenario the Connman device is in fact tethered > > to another device (via Gadget Ethernet-USB) that provides WAN > > connectivity. Specially, I'm working on an IVI platform attached to a > > telematics module which serves as a brigde to the WAN. I imagine this > > could be an equally compelling use-case for Connman given GENIVI's > > interest in using it as a network manager for the car. > > > > > struct connman_service to everybody else. There were some patches > > > floating around last autumn, but the author of those patches > disappeared > > > soon afterwards. > > > > > > > I discovered this discussion from April 2013 here: > > > > https://lists.connman.net/pipermail/connman/2013-April/013957.html > > > > and patches offered here: > > > > https://lists.connman.net/pipermail/connman/2013-April/013965.html > > > > Can I assume this is the topic you were referring to? I contacted the > > author of the patches and it seems increased workload prevented him > > from properly submit all the necessary patches. > > Yes, these are the relevant patches. Note that I implemented the USB > tethering in v1.17, so some part of the from patches from April need not > to be done. > > > > > With that said, I would like to pick up where he left off and try to > > formulate a series of patches that the Connman maintainers would > > consider merging into the base-line. Unfortunately, I need some > > feedback on several questions regarding such an implementation. I ask > > only to minimize the number of changes necessary to get these changes > > submitted and accepted by you. > > Patches are welcome as usual. > > > > > Here are my questions: > > > > 1) Some of the structure/function names in ethernet.c are a bit > > mis-leading with the introduction of partial Gadget support. As in the > > earlier patch (above) I'm inclined to slightly modify some of these > > private names so the intent is clearer. Would you accept such changes? > > I would say yes, please fix the name to be logical if you wish. > > > > > 2) It appears the functions for the Gadget "device" driver are > > effectively empty. My intention is to substitute the gadget_XXXX > > functions with their ethernet_driver equivalents since that appears to > > be the behavior I want. One approach is to use the ethernet driver > > functions directly in the Gadget device driver structure. Another is > > to call these ethernet driver functions from the Gadget driver > > function implementations. The third is to copy the content of the > > ethernet driver functions into the corresponding Gadget driver > > functions (effectively making copies). Which approach would you prefer > > and likely accept? > > Note that ethernet and usb gadget ethernet work somewhat differently. > When ethernet is plugged in we automatically power if on, for usb gadget > ethernet, we should power the device only when there is a real > connection. I saw this error when trying the patches in last April. > > > > > 3) There is a static "eth_tethering" flag in ethernet.c. This seems to > > imply that all ethernet devices are either supporting tethering or > > not. Is this the intention? It's not clear how this flag would impact > > Gadget devices? Can you elaborate on the intent/purpose of this > > private global variable. It might seem this should be included in the > > ethernet device data (per instance) rather than globally applying to > > all ethernet devices. I'm likely mis-understanding the intent. > > > > 4) I'd argue the service name generated for a Gadget service should in > > fact include "ethernet" rather than "gadget" as was suggested in the > > earlier thread above. Truly, the Gadget device is providing an > > ethernet "service" instead of a "gadget" service which seems more akin > > to a particular bearer (like USB perhaps). Perhaps you could clarify > > your reasoning? I am inclined to maintain the current behavior. > > I would prefer separate "gadget" and "ethernet". This way it is easier > to distinguish them in possible UI etc. > > > > > 5) Do you have any suggestions on the service "weight" that should be > > assigned to a gadget service type? I'm inclined to list it just below > > Ethernet since it is a hard-wired connection. > > Sounds ok to me. > > > > > 6) For the "service2bearer()" function in session.c, would > > CONNMAN_SERVICE_TYPE_GADGET be something like "usb"? Likewise for > > bearer2service()? > > > > 7) There was mention in the above threads about adding a global > > configuration item to main.conf. What is not clear is the > > intent/purpose of that variable. Can you elaborate? > > Probably this is not relevant anymore. > > > > > Sorry for bombarding you with so many questions. I am trying to > > understand the design approach so any patches I produce are easier to > > accept and integrate. Likely, I may have more questions as I begin the > > implementation. > > > > Thanks for your insights and understanding . . . > > Thank you, and we are waiting to see your patches. > > > > > Glenn > > > Cheers, > Jukka > > > > _______________________________________________ > connman mailing list > [email protected] > https://lists.connman.net/mailman/listinfo/connman > _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
