Re: proposed change to getty
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 next time you are using a modem if this causes any issues for you. Take care, Jared
Re: proposed change to getty
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 the device again. So far, so good. So getty have the device open, it can check if it is local, it can wait before doing a new open if it is not local. Which seems like the most natural thing. There - makes sense now? This is not how getty works. You are right. I was trying to remember things and am messed up. However, did I misunderstand your original problem? And finally, the problem is actually simpler in the end. The local attribute information is (or should be) in /etc/ttys and /etc/gettytab, so you do not actually have to open the line to know if it is local or not. And obviously there is no point or need to delay if we're local. But if we're actually remote, there needs to be a delay, and I still think getty is the place where that makes sense to have. There. This time I don't think there is anything else to sort out. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: proposed change to getty
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. Seems like the most natural thing. It sleeps before opening the device to ensure that the last close had enough time to send the hangup signal. It doesn't actually close the device itself, as the tty stays open for exec of the login process. 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 getty have the device open, it can check if it is local, it can wait before doing a new open if it is not local. Which seems like the most natural thing. There - makes sense now? The code is in src/libexec/getty/ if you care to look for yourself. Yes. And I've read it before. In a sense I am wondering what the problem is that you are facing and solving. A delay before a new login prompt when running with a video subsystem or serial console I believe. I agree that there is no need that there should be any delays here. But I do think that the proper answer to that is that these sessions are local, and that should be considered when getty waits or not. Because it is clear that if you truly have a modem hooked up to a serial port, then the delay is necessary, and it seems very reasonable that it would be in getty. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: proposed change to getty
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 getty have the device open, it can check if it is local, it can wait before doing a new open if it is not local. Which seems like the most natural thing. There - makes sense now? This is not how getty works. It's not the same getty process at this point because the last one has done an exec. So you have lost the context and it is always a "new" open. Hence the old code doing a sleep every time -- the _new_ getty process has no context of whether the device it is about to open has clocal set. I've made it pretty clear by now that your suggestion won't work in practice and I won't be spending any more time trying to convince you otherwise. Take care, Jared
Re: proposed change to getty
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 sleeps before opening the device to ensure that the last close had enough time to send the hangup signal. It doesn't actually close the device itself, as the tty stays open for exec of the login process. The code is in src/libexec/getty/ if you care to look for yourself. Take care, Jared
Re: proposed change to getty
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 monitors and keyboards, who run getty should be clocal. 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. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: proposed change to getty
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 be clocal. You need to open the device to check to see if clocal is set.
Re: proposed change to getty
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 the code to one use case, when there are several. The com(4) driver has had a better workaround for this issue for a quarter of a century. Many other serial drivers do too. Like I said in the original email, if this change causes issues for you, let me know which driver to look at and I will help fix it. Take care, Jared
Re: proposed change to getty
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 play with DTR. But it's wrong to just adopt the code to one use case, when there are several. The com(4) driver has had a better workaround for this issue for a quarter of a century. Many other serial drivers do too. 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 be clocal. No need for "workarounds", really. The one thing to argue about is where the delay should be placed. Like I said in the original email, if this change causes issues for you, let me know which driver to look at and I will help fix it. I haven't had any time to check, so I don't know for sure. But I do know there are several serial port drivers on a VAX. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: proposed change to getty
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 problem with the delay in getty in the first place? You misunderstand my original email. getty runs on framebuffer and serial consoles, and the delay is not needed in those cases. 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 the code to one use case, when there are several. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: proposed change to getty
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 signal, and it is disabling that signal that all this is about. (There were other devices that behaved similarly, but they're even less likely to be seen now.) The serial port is the system interface to the modem (that is the interface in question - modems that are implemented on ISA/EISA/PCI/PCIe/... cards are entirely different beasts, though I believe that some of those, probably even most, present a system interface that looks like a serial port, and most likely manipulating the fake DTR on that fake serial port would have similar effects). And yes, I know that these things are not quite as commonly used these days as they were in the 1970's and 80's ... Right. And the point of the DTR is that if it is dropped, then the modem is supposed to hang up the line. But this requires that the signal stays low for some amount of time, as modems or telephone lines weren't that fast to react. And yeah, this might not be a common piece of hardware anymore, but I'm a bit unsure what the purpose/point of the change is. 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 first place? And if the serial driver just don't allow a new open to complete until some defined time after the close, then an additional delay in getty don't really cause any problems at all. Do we have any confidence that all serial drivers actually do enforce this delay at close? I'm thinking of stuff like VAXen here, which actually might have a few serial lines more or less all the time, as opposed to PCs, where I can believe it's not that common anymore. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: proposed change to getty
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 first place? You misunderstand my original email. getty runs on framebuffer and serial consoles, and the delay is not needed in those cases.
Re: proposed change to getty
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 this is about. (There were other devices that behaved similarly, but they're even less likely to be seen now.) The serial port is the system interface to the modem (that is the interface in question - modems that are implemented on ISA/EISA/PCI/PCIe/... cards are entirely different beasts, though I believe that some of those, probably even most, present a system interface that looks like a serial port, and most likely manipulating the fake DTR on that fake serial port would have similar effects). And yes, I know that these things are not quite as commonly used these days as they were in the 1970's and 80's ... kre
Re: proposed change to getty
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 should have no real effect. Thanks for the history -- very interesting! I've committed the change to getty (removed the sleep completely) and will help people resolve any driver issues that come up as a result of this. It's nearly impossible for me to actually test every serial driver in the tree, and I expect the number of people still using a combination of 1) an esoteric serial driver, 2) a modem, 3) getty instead of something like pppd, and 4) a recent NetBSD release will be very close to zero. Take care, Jared
Re: proposed change to 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 been there since before NetBSD > > I don't recall if that was there when this > version of getty was created or not -- probably, > in which case it was probably also in the 7th > edition getty. That all got done about 40 > years ago, far too long to remember. > > 2 secs back then was the smallest sleep that > was guaranteed to be > 0 (the delay for sleep(n) > was between n-1 and n secs). Since that is > no longer true, the smallest change that should > happen is s/2/1/, or use usleep() or nanosleep() > and make the delay even smaller, 200ms should > be enough for any modem. > > 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 should have > no real effect. > > kre Do you mean modem like a telephone modem or modem like a serial port?
Re: proposed change to getty
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 when this version of getty was created or not -- probably, in which case it was probably also in the 7th edition getty. That all got done about 40 years ago, far too long to remember. 2 secs back then was the smallest sleep that was guaranteed to be > 0 (the delay for sleep(n) was between n-1 and n secs). Since that is no longer true, the smallest change that should happen is s/2/1/, or use usleep() or nanosleep() and make the delay even smaller, 200ms should be enough for any modem. 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 should have no real effect. kre
proposed change to getty
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 workaround in their chardev close functions so it should not be necessary in most cases. Question is -- is anybody relying on this behaviour anymore? If so I can help fix your serial driver. getty source: https://nxr.netbsd.org/xref/src/libexec/getty/main.c#232 Take care, Jared
