On Thu, 14 Oct 2021, Johnny Billquist wrote:
remote, there needs to be a delay, and I still think getty is the place where
that makes sense to have.
Thanks for the feedback Johnny. We will have to agree to disagree on this
point. I've committed the change to getty so please let me know the
On 2021-10-14 10:08, Jared McNeill wrote:
On Thu, 14 Oct 2021, Johnny Billquist wrote:
Right. Maybe I should have been clearer.
Is that a problem? getty opens the device, and does the initial
prompting. It then exec login, and when the child eventually exits, it
waits a while before opening
On 2021-10-13 23:18, Jared McNeill wrote:
On Wed, 13 Oct 2021, Johnny Billquist wrote:
You need to open the device to check to see if clocal is set.
Yes. Is that a problem?
With getty, it has to open the device anyway. And then it's just a
question of doing a delay at close if it is not.
On Thu, 14 Oct 2021, Johnny Billquist wrote:
Right. Maybe I should have been clearer.
Is that a problem? getty opens the device, and does the initial prompting. It
then exec login, and when the child eventually exits, it waits a while before
opening the device again.
So far, so good. So
On Wed, 13 Oct 2021, Johnny Billquist wrote:
You need to open the device to check to see if clocal is set.
Yes. Is that a problem?
With getty, it has to open the device anyway. And then it's just a question
of doing a delay at close if it is not. Seems like the most natural thing.
It
On 2021-10-13 22:03, Jared McNeill wrote:
On Wed, 13 Oct 2021, Johnny Billquist wrote:
Really? Because I would really think that clocal would be the absolute
correct thing to check for, and if it is, then don't have a delay. And
if it's not, then a delay is in order. And all kind of local
On Wed, 13 Oct 2021, Johnny Billquist wrote:
Really? Because I would really think that clocal would be the absolute
correct thing to check for, and if it is, then don't have a delay. And if
it's not, then a delay is in order. And all kind of local monitors and
keyboards, who run getty should
On Wed, 13 Oct 2021, Johnny Billquist wrote:
Ah! Definitely agree there. getty should only really have a delay if it is a
remote terminal, in fact.
If you don't have modem control to start with, it has always been pointless
to even have a delay, or play with DTR.
But it's wrong to just adopt
On 2021-10-13 21:56, Jared McNeill wrote:
On Wed, 13 Oct 2021, Johnny Billquist wrote:
Ah! Definitely agree there. getty should only really have a delay if
it is a remote terminal, in fact.
If you don't have modem control to start with, it has always been
pointless to even have a delay, or
On 2021-10-13 18:25, Jared McNeill wrote:
On Wed, 13 Oct 2021, Johnny Billquist wrote:
Sure, if all serial port drivers were to implement this at close, then
getty certainly could skip it. But the OP at the same time also
question if people are using getty at all, in which case, what is the
On 2021-10-13 16:00, Robert Elz wrote:
Date:Tue, 12 Oct 2021 09:42:55 -0400
From:matthew sporleder
Message-ID:
| Do you mean modem like a telephone modem or modem like a serial port?
I meant telephone modems - they're what most uses DTR as a functional
On Wed, 13 Oct 2021, Johnny Billquist wrote:
Sure, if all serial port drivers were to implement this at close, then getty
certainly could skip it. But the OP at the same time also question if people
are using getty at all, in which case, what is the problem with the delay in
getty in the
Date:Tue, 12 Oct 2021 09:42:55 -0400
From:matthew sporleder
Message-ID:
| Do you mean modem like a telephone modem or modem like a serial port?
I meant telephone modems - they're what most uses DTR as a functional
signal, and it is disabling that signal that all
On Tue, 12 Oct 2021, Robert Elz wrote:
Doing it in the driver is OK as well, but
probably needs to remain in getty until we are
sure that all drivers do this correctly.
Since you are handling this by blocking open
until long enough after the close had passed,
also delaying the open in getty
On Tue, Oct 12, 2021 at 4:33 AM Robert Elz wrote:
>
> Date:Mon, 11 Oct 2021 18:09:23 -0300 (ADT)
> From:Jared McNeill
> Message-ID: <5ab793c9-8cab-2e79-e6ba-8017d924b...@invisible.ca>
>
> | There's a 2 second sleep in getty before opening the tty
> | that has
Date:Mon, 11 Oct 2021 18:09:23 -0300 (ADT)
From:Jared McNeill
Message-ID: <5ab793c9-8cab-2e79-e6ba-8017d924b...@invisible.ca>
| There's a 2 second sleep in getty before opening the tty
| that has been there since before NetBSD
I don't recall if that was there
There's a 2 second sleep in getty before opening the tty that has been
there since before NetBSD and I am planning to get rid of it. The comment
above it says:
* Delay the open so DTR stays down long enough
* to be detected.
A bunch of our uart drivers already have a similar
17 matches
Mail list logo
