Hey, Nice to know that someone else is also interested in usage of libusbg library:) > -----Original Message----- > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb- > owner@xxxxxxxxxxxxxxx] On Behalf Of Matt Porter > Sent: Thursday, April 10, 2014 11:14 PM > To: Philippe De Swert > Cc: linux-usb@xxxxxxxxxxxxxxx > Subject: Re: libusbg and vbus detection for UDC driver > > On Thu, Apr 10, 2014 at 11:24:49PM +0300, Philippe De Swert wrote: > > Hi all, > > > > On first sight it seems that the two things in the subject have > > nothing to do with each other, so I will quickly explain why they > do > > (at least for me). So for some time already I have been working > on > > usb_moded, which is a small daemon which handles setting up > gadget > > drivers, so that a device can offer several different levels of > > functionality (for this it is also capable of setting up network > and > > start/stop services over dbus/systemd/upstart when needed) > > > > Now I would like to add support for the new gadgetfs. And there I > > run into two issues. I looked into code of usb_moded (just looked, didn't read the whole code). I found it really interesting, a lot of work has been done. Good to know that someone is also working with userspace usb gadget:) We are also working on such daemon and we found libusbg suitable for it. Usb_moded does quite a lot of things I see. We also considered such approach but we found out that this will not be suitable for us because things like setting network interfaces or other should be done by specialized daemons (like connman). We try to make a demon which will be as much generic as possible. We have chosen a design in which gadgetd (our daemon, will be open-sourced shortly;) ) does only required things connected directly with usb. So it should be a simple daemon which will only get messages via dbus or other IPC's and execute (with some policy like pollkit or sth) demands from user apps (for example settings). Things like setting network interface or ssh we would like to export from our daemon because they are not directly connected with usb. When I'm talking about demands I think about some gadget settings or loading created before gadget. Our goal is to provide support for functionFS, so applications will only select which function to use and if some instance of ffs has been chosen the daemon will take care of all required things before enabling gadget (mount ffs etc.). Maybe it would be beneficial to get into cooperation? What do you think about such approach? How your daemon integrate with whole system environment and policy? > > > > 1. It seems that libusbg from Matt Porter seems the library to > use. > > Is that correct? I saw patches on the mailing list, but they did > not > > seem to have made it to: https://github.com/libusbg/libusbg > > I think it's the right choice. :) As of last week, all but the > latest > two series that have been posted have been merged to master as I > work > through some backlog in my copious spare time. @Matt Not all changes has been merged. Remove gadget functionality which I have fixed according to your remarks last week is still waiting for merge both on the list and in pull request on github. -- BR's Krzysztof Opasiak -- 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
