ReHi Johan, On 30/09/14 08:32, Johan Ström wrote: > * auto-detection can only be relied on for certain pure USB devices > * auto-detection can not be relied on when "standard" serial bridge > chips are used While plug&play detecting USB devices (including serial interface converters) is integral part of the USB, serial interfaces like RS-232 and V.24 don't support auto-detection of any sort. It is a very, very bad idea to probe serial devices in a challenge/response type of way or even by toggling RTS/CTS or DSR/DTR, because this can unpredictably cause various serial devices to malfunction. Writing from experience, I strictly advice against auto-detecting any serial devices, no matter if they are hooked up directly or utilizing an interface converter!
OWFS et alii should strictly rely on the configuration file (e.g /etc/ow.conf) and probe only interfaces stated in the configuration or as command line parameter. In case the serial converter /dev/ttyUSB0 is disconnected and newly enumerated as /dev/ttyUSB1 after re-connection, the configuration in /etc/ow.conf should allow for several interfaces to be used by OWFS (ttyUSB0 and ttyUSB1, in this example), but OWFS should not under any circumstances connect to any interfaces not stated in the configuration or on the command line. Re-reading the configuration and connecting to the one-wire networks could be initiated by sending a SIGHUP or SIGUSR1, if restarting the daemon is to be avoided. Consider, the user may want to use other software than OWFS in parallel with OWFS on the same machine to access different one-wire networks. If OWFS automatically connects to all networks it detects, the user is prohibited from using OWFS for one network, while using a different software for another network connected to the same machine. OWFS is very powerful, but not reliably enough for real-time applications, because it frequently resets the one-wire bus or re-sends messages it didn't get a positive reply to, which both occasionally jams the bus. > * if we can resolve /dev/ttyUSB0 to a particular USB device, we can > potentially select a smarter (i.e. improved FTDI) code path instead of > regular read/write from the tty device. > * /dev/ttyUSB0 is not stable, unless explicit devd setup is done. On most Linux and BSD systems udevd can be configured to always associate a certain USB devices with a special file name (e.g. /dev/ttyUSB0). This includes several identical USB devices, like two or more DS9490R adapters, which are differentiated by their unique USB devices identifiers. Front-end developers should exclusively use DS2401 ID chips to differentiate one-wire networks, no matter which interface they are connected to. > * this makes alterantive OWFS device addressing interesting, by > specifying USB serial. this would avoid devd all together. What would be the purpose of implementing a udevd type of device detection into OWFS, if udevd works reliably? Any device detection done by OWFS makes the configuration of OWFS more complicated and can cause conflicts with other software accessing those devices. udevd is the established standard for detecting devices in a centralized manner. The set-up of rules for udevd can be described step-by-step in the OWFS wiki including examples. The external network connection set-up should be seen independent of any automated device identification done inside OWFS to access special devices features and activate optimizations. > This allows previous setups to work without changes, but still giving > them improved speed if a FTDI device happens to be in use. > For new/updated setups, it allows the administrator to specify an > explicit USB device without having to involve devd. As you suggested, allowing to specify the interface or USB device being used would be a very welcome enhancement to OWFS. Though, the bus:device syntax has its drawbacks, if the USB device is (accidentally) connected to a different USB port or if the system hardware is replaced. The vendor-id:product-id approach, on the other hand, fails if there is more than one device of the same type attached to the machine. Any other solution requires udevd/devd, which isn't always installed. Regards, Tiger ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
