Re: "stty sane" in kunit.py
On Sat, 9 Nov 2024 at 08:18, David Gow wrote: > On Fri, 8 Nov 2024 at 18:49, Brendan Jackman wrote: > If I remember correctly, this was due to UML sometimes messing up the > terminal (not QEMU, though QEMU definitely does the same thing > sometimes), possibly just when it terminated uncleanly. It may also > have been, as Daniel notes, something to do with the --alltests > option, which used allyesconfig, so could enable some strange > settings. Oh yes I totally forgot about the UML support! UML could definitely be doing terminal ioctls. In a funny coincidence, a totally separate codebase that I'm working on on weekends recently started doing freaky terminal stuff, and now that hangs when run as the child of something like watchexec. So, I guess I'll get back to this kunit.py question once I've debugged that other thing, I bet I'll learn something useful. I guess it's also not worth trying to fix this if we can't be sure the replacement still fixes the problem that `stty sane` was intended to fix, unless the hang turns out to be a problem for CI tooling.
Re: "stty sane" in kunit.py
On Fri, 8 Nov 2024 at 18:49, Brendan Jackman wrote: > > Hi all, > > Does anyone know what the 'stty sane' invocation in kunit.py is about? > > The other day I ran into an issue when running it via watchexec[1]. At > the time I believed that it was there to clean up after the firmware > that QEMU runs potentially messed up the terminal. > > However, I just realised I'm not sure if that makes sense - stty is > about setting terminal settings via ioctl. I don't think QEMU or its > guests are messing up the terminal with ioctls, they're just writing > funny control characters. > > What's going on here? I guess one of: > > 1. Terminal is messed up with ctrl chars but ioctls are the > easiest/only way to reliably clean it up. > > 2. Nobody thought about this unimportant detail so hard before and > there's no particular rationale in place here. > > 3. I made bad assumptions about why the `stty sane` is there. > > If it's 1 or 2 I wonder if there's an alternative way to clean up > without getting the SIGTTOU issue. > > Or, maybe it doesn't matter and the fact that this was ever a problem > is just a bug in watchexec (maybe you can tell I haven't actually > taken the time to research the SIGTTOU thing properly). But thought > I'd raise it in case this points to issues people might have using > kunit.py in CI. > > [1] https://github.com/watchexec/watchexec/issues/874 > [2] https://gist.github.com/bjackman/27fd9980d87c5556c20e67a6ed891500 If I remember correctly, this was due to UML sometimes messing up the terminal (not QEMU, though QEMU definitely does the same thing sometimes), possibly just when it terminated uncleanly. It may also have been, as Daniel notes, something to do with the --alltests option, which used allyesconfig, so could enable some strange settings. We definitely didn't look into things closely enough to determine if it was just control codes, or actual IOCTLs. I suspect it's just control codes, but UML does have some strange TTY options (though I think those don't affect us, as we usually pipe the results though.) 'stty sane' was probably used because it worked, and 'reset' would clear the screen, leaving us without the results visible. If there's another way which doesn't break anything, I'd be happy to change it. Maybe outputting '\033c' would do it? -- David smime.p7s Description: S/MIME Cryptographic Signature
Re: "stty sane" in kunit.py
(resend, gmail decided to switch to html email :\)
David would know best.
As you probably saw, this was added in 021ed9f551da ("kunit: Run all
KUnit tests through allyesconfig").
This was specifically for running on UML, _not_ QEMU.
I vaguely remember it being along the lines of #1, but not what the
details were.
On Fri, Nov 8, 2024 at 2:49 AM Brendan Jackman wrote:
>
> Hi all,
>
> Does anyone know what the 'stty sane' invocation in kunit.py is about?
>
> The other day I ran into an issue when running it via watchexec[1]. At
> the time I believed that it was there to clean up after the firmware
> that QEMU runs potentially messed up the terminal.
>
> However, I just realised I'm not sure if that makes sense - stty is
> about setting terminal settings via ioctl. I don't think QEMU or its
> guests are messing up the terminal with ioctls, they're just writing
> funny control characters.
>
> What's going on here? I guess one of:
>
> 1. Terminal is messed up with ctrl chars but ioctls are the
> easiest/only way to reliably clean it up.
>
> 2. Nobody thought about this unimportant detail so hard before and
> there's no particular rationale in place here.
>
> 3. I made bad assumptions about why the `stty sane` is there.
>
> If it's 1 or 2 I wonder if there's an alternative way to clean up
> without getting the SIGTTOU issue.
>
> Or, maybe it doesn't matter and the fact that this was ever a problem
> is just a bug in watchexec (maybe you can tell I haven't actually
> taken the time to research the SIGTTOU thing properly). But thought
> I'd raise it in case this points to issues people might have using
> kunit.py in CI.
>
> [1] https://github.com/watchexec/watchexec/issues/874
> [2] https://gist.github.com/bjackman/27fd9980d87c5556c20e67a6ed891500
"stty sane" in kunit.py
Hi all, Does anyone know what the 'stty sane' invocation in kunit.py is about? The other day I ran into an issue when running it via watchexec[1]. At the time I believed that it was there to clean up after the firmware that QEMU runs potentially messed up the terminal. However, I just realised I'm not sure if that makes sense - stty is about setting terminal settings via ioctl. I don't think QEMU or its guests are messing up the terminal with ioctls, they're just writing funny control characters. What's going on here? I guess one of: 1. Terminal is messed up with ctrl chars but ioctls are the easiest/only way to reliably clean it up. 2. Nobody thought about this unimportant detail so hard before and there's no particular rationale in place here. 3. I made bad assumptions about why the `stty sane` is there. If it's 1 or 2 I wonder if there's an alternative way to clean up without getting the SIGTTOU issue. Or, maybe it doesn't matter and the fact that this was ever a problem is just a bug in watchexec (maybe you can tell I haven't actually taken the time to research the SIGTTOU thing properly). But thought I'd raise it in case this points to issues people might have using kunit.py in CI. [1] https://github.com/watchexec/watchexec/issues/874 [2] https://gist.github.com/bjackman/27fd9980d87c5556c20e67a6ed891500
