Date: Tue, 27 Sep 2016 23:09:52 +0300 From: Boris Samorodov <bsam@passap.ru> To: Kurt Jaeger <lists@opsec.eu> Cc: freebsd-ports@freebsd.org Subject: Re: Serial ports guru help is needed Message-ID: <048ea3e7-5b8f-781b-a070-4a1ef39a33fd@passap.ru> In-Reply-To: <20160927171033.GV85563@home.opsec.eu> References: <617393b9-a860-e9b4-c101-4599bbba594f@passap.ru> <20160927171033.GV85563@home.opsec.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
Kurt, thank you for your really great answer. 27.09.2016 20:10, Kurt Jaeger пишет: > >> A user proposed some changes to deal with serial ports I do not quite >> understand (and tend to not agree with). Can a serial ports guru take >> a look at the PR: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211101 >> and comment here (or at the PR if you wish) on proposed changes (for >> serial ports changes). > > Asking Gert Doering from mgetty, he explained the reason for > two seperate names in the filesystem for the same device. > > In the long-gone past of unix, serial ports were a scarce resource, > so ports were connected to modems and used for both dial-in and > dial-out usage. > > The two names/devices had different behaviour which allowed them > to be used in parallel, for either dial-in or dial-out: > > - getty waits on tty*, as long as the DCD-pin is low (open() blocked) > - dialout applications like kermit or cu(1) use cua* for outgoing calls > During an outgoing call, no incoming call will be received anyway. > - If a call comes in, the modem takes the call, signals DCD > on the serial port and getty's open() call finally suceeds > and getty presents the 'login:'. > - As long as getty has the serial port blocked for incoming use, > open()'ing cua* will return EBUSY > > For a similar explanation see: > > https://en.wikipedia.org/wiki/Data_Carrier_Detect > > So, back to this usecase: Will a software someone is using to > talk to logic analyzers, MSOs, oscilloscopes, multimeters, LCR > meters, sound level meters, thermometers, hygrometers, anemometers, > light meters, DAQs, dataloggers, function generators, spectrum > analyzers, power supplies, GPIB interfaces, and more, really > be used on a serial port that is used to log in (the getty usecase) ? > > In general, I guess: No. > > So the change from cua* to tty* is, while not really needed, not > really critical. In other words, there is almost no gain while little harm. So why do those changes in the first place? However, the change may be treated as a POLA violation and contradicts the FreeBSD Handbook: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html ----- In FreeBSD, each serial port is accessed through an entry in /dev. There are two different kinds of entries: Call-in ports are named /dev/ttyuN where N is the port number, starting from zero. If a terminal is connected to the first serial port (COM1), use /dev/ttyu0 to refer to the terminal. If the terminal is on the second serial port (COM2), use /dev/ttyu1, and so forth. Generally, the call-in port is used for terminals. Call-in ports require that the serial line assert the “Data Carrier Detect” signal to work correctly. Call-out ports are named /dev/cuauN on FreeBSD versions 10.x and higher and /dev/cuadN on FreeBSD versions 9.x and lower. Call-out ports are usually not used for terminals, but are used for modems. The call-out port can be used if the serial cable or the terminal does not support the “Data Carrier Detect” signal. ----- Are there any PROs for the change? Thanks all for help and discussion. -- WBR, bsam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?048ea3e7-5b8f-781b-a070-4a1ef39a33fd>