On Tue, Jul 12, 2016 at 01:15:05AM +0000, Mike Meyer wrote: > > Ah, in that case, my first impulse - to use the same check that linux > does, and just look for /dev- was the correct one. I backed it out because > I wasn't sure how it would interact with the USB device checking.
The problem with just looking at everything in /dev/ is that each port will turn up more than once in the list. I'd like the enumeration to handle the fact that /dev/ttyX, /dev/cuaX, and the corresponding .lock and .init nodes are all actually the same port. Obviously that means we need to pick some convention about which name we return in the list, but from what you say below it sounds like /dev/ttyX may be a less astonishing choice for FreeBSD users than the current use of /dev/cuaX. It's only for sp_list_ports() that we actually need to make a choice, however. If a program already has a port name (e.g. one supplied by a user on the command line) then it will call sp_get_port_by_name(), and that ought to work regardless of which device node is given. The current snag there is that sp_get_port_by_name() calls the get_port_details() implementation in freebsd.c, which rejects the port name if it does not match the /dev/cuaX pattern. That's a bug that needs to be fixed, independent of the enumeration. It should accept any valid name for the port in that call. Your current patch makes it reject anything not matching /dev/ttyX, which is equally broken. > They cua & tty devices use the same device driver. In fact, they are the > same device, with code in the kernel to insure you don't open them both at > once. The ioctl doesn't distinguish between the two - anything you can > change on one, you can change on the other. Fine. So we're free to choose which one we use in the enumeration. > Can't say exactly, because each driver (i.e. usarts, the usb serial > driver, etc.) gets it's own set of initial termios flags for both > directions. The one thing that's hardwired is that cua devices (and the > console) get the CLOCAL flag set, which causes modem status lines to be > ignored, including skipping the initial wait on DCD. OK. It doesn't really matter though as long as we're free to change all the settings after open(). I was doing some googling though about the /dev/tty vs /dev/cua distinction and found this explanation widely quoted: "The idea is to supplement software in sharing a line between incoming and outgoing calls. The callin device (typically /dev/tty*) is used for incoming traffic. Any process trying to open it blocks within the open() call as long as DCD is not asserted by hardware (i.e. as long as the modem doesn't have a carrier). During this, the callout device (typically /dev/cu* -- cu stands for "calling unit") can be freely used. Opening /dev/cu* doesn't require DCD to be asserted and succeeds immediately. Once succeeded, the blocked open() on the callin device will be suspended, and cannot even complete when DCD is raised, until the cu device is closed again. That way, you can have a getty listening on /dev/tty*, and can still use /dev/cu* without restrictions." This suggests that the open() itself will block on /dev/tty* until DCD is asserted. If so, obviously that would prevent us being able to just open the device and then change the CLOCAL setting. Is that true on FreeBSD, in either current or older versions? > > - Is there a convention within the FreeBSD user community over which > > name to use when identifying a physical port? > > YES!!!!! They use /dev/tty for pretty much anything that can't dial the > phone. And even for things that can. That's the violation of POLA. OK. I'm fine with changing the enumeration to list /dev/ttyX if that's the case. > Well, if you've got an honest-to-goddess call unit dialing for the serial > device, then you really need to be waiting for DCD, as there isn't > anything on the other end to talk to before it goes on. If libserialport > can't do that, then the API isn't up to dealing with call units You can handle that with libserialport just fine, but you have to do it explicitly; you open the port, and then monitor the DCD status, waiting for it to be asserted before you do anything else with the port. Again, this is just the result of needing to provide a consistent API across platforms. We can't offer an option to e.g. "make open block until DCD is asserted", because that behaviour can't be reproduced on all platforms. Instead, we provide the low level capabilities and allow everything else to be built up on top in a platform independent way. Regards, Martin ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
