Serial ports guru help is needed

[Kurt Jaeger]

Hi!

> 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.

-- 
pi at opsec.eu            +49 171 3101372                         4 years to go !