Re: Serial ports guru help is needed

2016-09-27 Thread Mehmet Erol Sanliturk
On Tue, Sep 27, 2016 at 1:21 PM, Kurt Jaeger  wrote:

> Hi!
>
> > Are there any PROs for the change?
>
> I've re-read the PR and your idea to allow both cua* and tty* being
> used. If that is possible and "does the right thing", it's even better.
>
> --
> p...@opsec.eu+49 171 3101372 4 years to
> go !
> ___
>
>


You are right because if you think "sender" and "receiver" working on the
same computer ,
when assumed FreeBSD is supporting a complex laboratory system ( you
mentioned in previous message such a possible devices list , someone
sending and someone receiving messages ) .


Mehmet Erol Sanliturk
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Serial ports guru help is needed

2016-09-27 Thread Kurt Jaeger
Hi!

> Are there any PROs for the change?

I've re-read the PR and your idea to allow both cua* and tty* being
used. If that is possible and "does the right thing", it's even better.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Serial ports guru help is needed

2016-09-27 Thread Boris Samorodov
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
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Serial ports guru help is needed

2016-09-27 Thread Kurt Jaeger
Hi!

> > So the change from cua* to tty* is, while not really needed, not
> > really critical.
> > 

> Folks might want to (also) consider the use case of a serial console --
> and being able to login to it (e.g., if all other access has failed, for
> an out-of-band communication mechanism with a remote, headless server).

Will those precious serial console ports of headless servers really
be used to access logic analyzers etc ?

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Serial ports guru help is needed

2016-09-27 Thread David Wolfskill
On Tue, Sep 27, 2016 at 07:10:33PM +0200, Kurt Jaeger wrote:
> ...
> 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.
> 

Folks might want to (also) consider the use case of a serial console --
and being able to login to it (e.g., if all other access has failed, for
an out-of-band communication mechanism with a remote, headless server).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature


Re: Serial ports guru help is needed

2016-09-27 Thread 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.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Serial ports guru help is needed

2016-09-27 Thread Torfinn Ingolfsen
Hello,
I'm not a serial guru, but I have used serial extensively over the
past 20 - 40 years.

On Tue, Sep 27, 2016 at 10:59 AM, Boris Samorodov  wrote:
> Hi All!
>
>
> 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).
>
> In brief (as I understand). Currently there is a support for cua* ports
> only (no support for tty* ports). The proposed changes restrict using
> cua* but allow tty* ports, which will act like cua* ports.
>
> As for me I'll add tty* ports without removing cua*.

Sounds like the best way forward, IMHO.
cua and tty ports have existed for a long time, they each fulfil a
role, and they are not the same.
One or the other should not be removed unless a _good_ reason (be it
technical or practical) is explained here, IMNSHO.


Those who do not remember the past are condemned to repeat it.
-- 
Regards,
Torfinn Ingolfsen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Serial ports guru help is needed

2016-09-27 Thread Boris Samorodov
Hi All!


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

In brief (as I understand). Currently there is a support for cua* ports
only (no support for tty* ports). The proposed changes restrict using
cua* but allow tty* ports, which will act like cua* ports.

As for me I'll add tty* ports without removing cua*.


Thank you.
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"