Hi, thanks for your feedback! On 9/30/14 20:08 , Der Tiger wrote: > 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! Yes, this is exactly what I have been saying since the start of this thread. Auto-probing an unknown serial port is a big no-no. > > 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. This is how it works today, and I have no intention to change that behavoir.
Actually, there is a slight chance that the above would talk with unintended devices, for example if owfs is configured to use ttyUSB0, ttyUSB1, and suddenly a non-1wire-device happens to land on ttyUSB0. The only way to prevent that, is to rely on devd-rules, or by explicitly address a pre-configured USB-chip via serial. > > 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. The only auto-probing which exists today is using the explicit -uall parameter to scan for all known USB devices. Nothing would change here. > >> * 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 background, in case it got lost in this long thread: Using a FTDI serial dongle via OS serial layer works, but does not permit control of the timing parameters of the FTDI chip. ~x3 bus speedup can be obtained if this can be adjusted. Please see this thread, and my earlier LinkUSB thread (link below), for details. > > 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. Yeah, I'm skeptical to bus:device as well, but it exists in OWFS today, for the pure-usb devices. vid:pid approach is also unreliable. However, explicit USB serial *should* be safe (?). Basically, what my minimal goal is to be able to use something like this: --ds9097U <tty> -- this would use standard tty layer identifyed by <tty> --ds9097U <usb:serial> -- this would use the FTDI adapter identified by the usb serial. --link <tty> --link <usb:serial> The last version of that (more or less) is supported by my wip branch: https://sourceforge.net/u/stromnet/owfs/ci/ftdi-linkusb/ This has been running for a few months with sub-second 24/7 traffic. Ref: http://owfs-developers.1086194.n5.nabble.com/Support-for-LinkUSB-via-libftdi-td10667.html What has come up for discussion in this thread, is the idea to automatically try to translate <tty> into <usb:serial> (sortof) via OS-specific calls. This would possibly allow owfs to use a better underlying layer, if the USB serial device type is known. I'm not really sure it's worth the extra complexity; why not just let the user enter the serial instead? Johan > > 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 ------------------------------------------------------------------------------ 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
