> I'll be testing more with real hardware.
I've now tried:
5.2/amd64 with
com0 at acpi0 (UAR1, PNP0501-0): io 0x3f8-0x3ff irq 4
com0: ns16550a, working fifo
1.4T/sparc with
zs0 at obio0 slot 0 offset 0x10 level 12 softpri 6
zstty1 at zs0 channel 1
In each case, I get EIO with nothing outp
> I think I have a USB serial port somewhere. I should try that under
> 5.2 to see what happens.
When pointed at /dev/ttyU0, ctty-test prints
ctty-test: test write failed: Input/output error
but, curiously, one CRLF does get emitted to /dev/ttyU0. It also
leaves it in a peculiar state in which
>> This makes me wonder if perhaps login sessions should have their
>> stdin/stdout/stderr set up on /dev/tty instead of the actual ctty
>> device.
> Interesting. Need to think about that...
One thing I can remark on already: tty(1) and ttyname(3) become less
useful, at least as they are currently
[bcc tech-kern, tech-security, tech-crypto; followups to
tech-userlevel to keep discussion in one place]
Many of you have no doubt noticed that a lot more things hang waiting
for entropy than used to on machines without hardware random number
generators (even as we've added a bunch of new drivers
>> I've got the test program written. On 5.2/amd64 with /dev/ttyE1 as
>> the test tty (no getty running on it, of course), output works just
>> fine [...]
> I tried it too, on 9.1 amd64, and that worked too. I did not expect
> that. While trying to write down why I thought that, I got even more
On Sun 10 Jan 2021 at 10:25:10 -0500, Mouse wrote:
> I've got the test program written. On 5.2/amd64 with /dev/ttyE1 as the
> test tty (no getty running on it, of course), output works just fine
> (this doesn't surprise me; I find it plausible that wscons tty
> open/close are pretty much no-ops as
> The case I'm wondering about is:
> - open real tty
> - make it the control tty
> - open /dev/tty
> - close the real tty
> - read/write the /dev/tty fd
> It looks to me as though this could lead to the underlying tty driver
> getting a read/write call when, accordin
>> It actually occurs to me that this is a potential problem even
>> today: what happens if all the processes in a session close the
>> descriptors they have on the ctty, and there are no others lying
>> around in other [...]
> or similarly, if they TIOCNOTTY it (although tty(4) tells me it's
> obs
On Sun 10 Jan 2021 at 09:44:18 -0500, Mouse wrote:
> >> This makes me wonder if perhaps login sessions should have their
> >> stdin/stdout/stderr set up on /dev/tty instead of the actual ctty
> >> device. But if that's done, will the `real' ctty device even be
> >> open? [...]
>
> It actually oc
>> This makes me wonder if perhaps login sessions should have their
>> stdin/stdout/stderr set up on /dev/tty instead of the actual ctty
>> device. But if that's done, will the `real' ctty device even be
>> open? [...]
It actually occurs to me that this is a potential problem even today:
what ha
>> This makes me wonder if perhaps login sessions should have their
>> stdin/stdout/stderr set up on /dev/tty instead of the actual ctty
>> device. But if that's done, will the `real' ctty device even be
>> open? [...]
> Interesting. Need to think about that...
All I've come up with so far is t
11 matches
Mail list logo
