On Fri, May 7, 2010 at 3:25 AM, Marcus Priesch <mar...@priesch.priv.at> wrote: > lshal provides a convenient output format for this kind of things, when > i plug in my 2490 i get the following: > > > as the "udi" is unique among hal and it is only composed of "static" > information provided by the 2490, i wonder what will happen if i plug in > anotherone - sad enough, currently i only have one ... :( > > if any information needed to selecting one device could be specified at > startup for libusb i would be fine off ;)
For libusb 0.1X (currently used): http://libusb.sourceforge.net/doc/ For libusb 1.X: http://libusb.sourceforge.net/api-1.0/ >From the 0.1X source, it's easy to select on any on the information from struct usb_device (see http://libusb.cvs.sourceforge.net/viewvc/libusb/usb.h.in?revision=1.20&view=markup This includes Vendor and Product (what we currently use) Nothing really matches the udev information. > >> > ok, so all commandline switches regarding the connection can be passed >> > as init string also ? >> >> Yes. (Though not all make sense, like mountpoint and port) > > ok, and how do i pass them ... whitespace seperated ?!? Yes, just like the command line. (We actually use the same code as the configuration file parsing.) We then stuff it into argv[] type string array and use the standard getopts functions. > >> Would it help to have a owserver-like program that talks to dbus? Is >> that what you are trying to create? > > hmmm ... i am not sure what you mean by "owserver-like" - but currently > sensorlib's manager talks to dbus and starts/stops interfaces which are > registered for a given dbus-specification ... I meant that rather than owserver which communicates with it's own tcp protocol, ir owfs that has a filesystem interface, you could make a "owserver-dbus" that communicates via dbus protocol. I Gather you are wrapping pyowfs with a dbus-aware program, which is another valid approach. > > if i get you right this would mean that i have *one* instance of owfs > which talks to all adapters, and i could query it for a specific adapter > (lets say by udi) and it tells me what bus.n to use for this adapter ? Sure. The udi would be part of the /bus.n/interface information and so easily queried. > > i think i defintely like the idea to have *one* owfs instance talking to > *one* adapter ... otherwise i would have one owfs instance spread out Ok individual instances should work fine. You can even aggregate them with another full owserver if you need that for a different use. > > btw: what happens in an owfs instance talking to multiple devices if one > device disappears ?!? It is handled gracefully. ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
