Hi Paul, Am Donnerstag, den 06.05.2010, 21:26 -0400 schrieb Paul Alfille: > On Thu, May 6, 2010 at 3:49 AM, Marcus Priesch <mar...@priesch.priv.at> wrote: > > so using bus.n sounds feasible, but is this numbering consistent through > > (un)plugging various adapters ?!?! > > > > i would expect following to happen: > > > > + plug in adapter 1 -> bus.0 > > + plug in adapter 2 -> bus.1 > > + remove adapter 1 -> bus.0 disappears > > + plug in adapter 3 -> bus.2 (! - not bus.0 !) > > + plug in adapter 1 -> bus.0 reappears > > > > sorry for the theoretical question, but currently i dont have that much > > adapters at hand to try it out ;) > > Actually, owfs only takes a snapshot of the available usb bus masters > at startup. There is no notification of additional additional usb > devices once under way. (This doesn't apply to the kernel wire module, > but that has it's own problems as I listed earlier.)
yes, i know - my approach is to have one owfs instance talking to only one adapter - as my sensorlib handles the dbus/hal stuff and starts up a new interface everytime a new usb-device gets connected - or drops it, along with all sensors attached to the device when it gets unplugged. > Apparently the correct way to handle new adapters is to use udev > rules. There currently is a gap between the understanding of usb > devices as owfs gets them from libusb and what udev knows about > devices. ack. > My suggestion is: > 1. figure out what information udev can gather about new devices. lshal provides a convenient output format for this kind of things, when i plug in my 2490 i get the following: $ lshal -u /org/freedesktop/Hal/devices/usb_device_4fa_2490_noserial udi = '/org/freedesktop/Hal/devices/usb_device_4fa_2490_noserial' info.linux.driver = 'usb' (string) info.parent = '/org/freedesktop/Hal/devices/usb_device_1d6b_1_0000_00_12_0' (string) info.product = 'DS1490F 2-in-1 Fob, 1-Wire adapter' (string) info.subsystem = 'usb_device' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_4fa_2490_noserial' (string) info.vendor = 'Dallas Semiconductor' (string) linux.device_file = '/dev/bus/usb/003/019' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'usb' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:12.0/usb3/3-2' (string) usb_device.bus_number = 3 (0x3) (int) usb_device.can_wake_up = true (bool) usb_device.configuration_value = 1 (0x1) (int) usb_device.device_class = 255 (0xff) (int) usb_device.device_protocol = 255 (0xff) (int) usb_device.device_revision_bcd = 2 (0x2) (int) usb_device.device_subclass = 255 (0xff) (int) usb_device.is_self_powered = true (bool) usb_device.linux.device_number = 19 (0x13) (int) usb_device.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:12.0/usb3/3-2' (string) usb_device.max_power = 100 (0x64) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 0 (0x0) (int) usb_device.product = 'DS1490F 2-in-1 Fob, 1-Wire adapter' (string) usb_device.product_id = 9360 (0x2490) (int) usb_device.speed = 12.0 (12) (double) usb_device.vendor = 'Dallas Semiconductor' (string) usb_device.vendor_id = 1274 (0x4fa) (int) usb_device.version = 1.0 (1) (double) i tried several usb ports on my laptop - only the "linux.sysfs_path" changes, "usb_device.linux.device_number" gets incremented each time i replug it ... so linux.sysfs_path should be able to pick one respective adapter. 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 ;) > 2. figure out a common way for udev and libusb/owfs to identify the > same usb device. well, i have to take a look at libusb to find out its capabilities ... > 3. decide if you want to start a new instance of owserver for each > device addition, or a single instance of owserver to start new bus.n > entries when a new device is seen. well, this should be a OWFS decision i do not want to decide on my own - the major question here is, do you *want* autodescovery in owfs or not - it could get complicated when you think about serial adapters and usb-serial adapters ... ;) for me it would be even harder to incorporate owfs into my sensorlib when it starts autodiscovering things ... i assume right now ;) therefore i cleary favor a solution where i *can* have one owfs instance for one adapter - but not limiting owfs to this, as i assume "-uall" is nice for the rest of the world ;) > The advantage of new instances is that the 1:n pattern is easier. yep - thats also why i favor this approach - also i think it will be much easier to implement ... :) for me its no problem to have individual instances as in the sensorlib i already have a single "interface" instance for each adapter where 1wire sensors are attached. the sensorlib puts together all sensors (not only 1wire - think of arduino's and other "industrial" measurement equipment) and presents a common api to the user to talk to all sensors in the same manner ... ps: sensorlib will get open source some day - but currently we will not go public ... ;) > The advantage of a single large instance is that locating and talking > to the owserver is easier (only a single port). thumbs down on this for me - as it will take lot of work inside owfs and it will make incorporation into sensorlib harder ;) > > another question would be if the numbering is consistent when restarting > > owfs - although, this would not be a requirement in my case ... > > > > Probably not -- it depends on the OS. ok, so i cant go that way to distinguish the sensors found on one bus or the other by bus.n ... :( > > 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 ?!? > 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 ... > One thing we could add is an interface in pyowfs (or owcapi) to add > new "interfaces". You could then monitor udev or dbus for new usb > adapters in your code, and notify owfs of their existence, getting > back a positive identifier to the correct bus.n entry. 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 ? 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 over all my individual "interfaces" ... and handling will be very complicated i guess ... btw: what happens in an owfs instance talking to multiple devices if one device disappears ?!? regards & thanks for your ideas, marcus. ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
