| Message ID | 20210830105308.308539-1-thuth@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | slof/fs/accept: Allow Unix LF line endings, too | expand |
On Mon, 30 Aug 2021 12:53:08 +0200 Thomas Huth <thuth@redhat.com> wrote: > Currently SLOF only accepts CR (0x0d) line endings at the command prompt, > since this is the default line ending used on serial consoles. However, > sometimes people try to connect to SLOF directly in a way that uses the > typical Unix LF line endings (0x0a) which are then completely ignored, > for example running QEMU like this: > > qemu-system-ppc64 -nodefaults \ > -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ > -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 > > and then connect to that Unix socket via "nc -U /tmp/mysocket". > > For such use cases, allow the 0x0a line ending in SLOF, too. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > I'm not quite sure anymore ... didn't we already run into this problem > a couple of times in the past already? Was there a reason that we never > allowed 0x0a here, too? > FWIW I don't remember, but I see no reason not to allow LF as well. Reviewed-by: Greg Kurz <groug@kaod.org> and Tested-by: Greg Kurz <groug@kaod.org> > slof/fs/accept.fs | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/slof/fs/accept.fs b/slof/fs/accept.fs > index cb6f2fa..26e9216 100644 > --- a/slof/fs/accept.fs > +++ b/slof/fs/accept.fs > @@ -392,6 +392,7 @@ TABLE-EXECUTE handle-control > 1b emit 37 emit > BEGIN > key dup 0d <> > + over 0a <> and > WHILE > dup 9 <> IF 0 to ?tab-pressed THEN \ reset state machine > dup 7f = IF drop 8 THEN \ Handle DEL as if it was BS. ??? bogus
On 30/08/2021 20:53, Thomas Huth wrote: > Currently SLOF only accepts CR (0x0d) line endings at the command prompt, > since this is the default line ending used on serial consoles. However, > sometimes people try to connect to SLOF directly in a way that uses the > typical Unix LF line endings (0x0a) which are then completely ignored, > for example running QEMU like this: > > qemu-system-ppc64 -nodefaults \ > -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ > -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 > > and then connect to that Unix socket via "nc -U /tmp/mysocket". > > For such use cases, allow the 0x0a line ending in SLOF, too. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > I'm not quite sure anymore ... didn't we already run into this problem > a couple of times in the past already? Was there a reason that we never > allowed 0x0a here, too? I do not remember anything like this and git blame suggests the code is from the initial commit. David poked me today about it and I came up with the same patch which does not seem breaking anything but I did not test everything (unix socket, tcp socket, telnet on/off), did you? ;) But the question now is how come qemu's stdin sends 0xd on "enter" to SLOF. I kinda understand why "nc" does this (it just does not do anything funny) but I am lost with the shell and tty. All I can see is that qemu_chr_set_echo_stdio() sets tty.c_iflag to 0 which means we should have the same problem with -stdio but we do not - vty_receive() receives 0xd on "enter" while "strace cat" in the same terminal gives 0xa. Ideas? > > slof/fs/accept.fs | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/slof/fs/accept.fs b/slof/fs/accept.fs > index cb6f2fa..26e9216 100644 > --- a/slof/fs/accept.fs > +++ b/slof/fs/accept.fs > @@ -392,6 +392,7 @@ TABLE-EXECUTE handle-control > 1b emit 37 emit > BEGIN > key dup 0d <> > + over 0a <> and > WHILE > dup 9 <> IF 0 to ?tab-pressed THEN \ reset state machine > dup 7f = IF drop 8 THEN \ Handle DEL as if it was BS. ??? bogus >
On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: > Currently SLOF only accepts CR (0x0d) line endings at the command prompt, > since this is the default line ending used on serial consoles. > However, > sometimes people try to connect to SLOF directly in a way that uses the > typical Unix LF line endings (0x0a) which are then completely ignored, > for example running QEMU like this: > > qemu-system-ppc64 -nodefaults \ > -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ > -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 > > and then connect to that Unix socket via "nc -U /tmp/mysocket". > > For such use cases, allow the 0x0a line ending in SLOF, too. How does that work if you feed text with CRLF combos? If it does accept a new line at both CR and LF, that is problematic (it violates both the OF and ANS specifications of ACCEPT). A "real" terminal sends CR only, by default, and can be switched to send CRLF instead (by CSI 20h; switch back with CSI 20l). You cannot do only LF on a standard terminal. Can't you just use nc -C or similar? Segher
On 30/08/2021 23:10, Segher Boessenkool wrote: > On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: >> Currently SLOF only accepts CR (0x0d) line endings at the command prompt, >> since this is the default line ending used on serial consoles. > >> However, >> sometimes people try to connect to SLOF directly in a way that uses the >> typical Unix LF line endings (0x0a) which are then completely ignored, >> for example running QEMU like this: >> >> qemu-system-ppc64 -nodefaults \ >> -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ >> -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 >> >> and then connect to that Unix socket via "nc -U /tmp/mysocket". >> >> For such use cases, allow the 0x0a line ending in SLOF, too. > > How does that work if you feed text with CRLF combos? If it does accept > a new line at both CR and LF, that is problematic (it violates both the > OF and ANS specifications of ACCEPT). Is it in of1275 somewhere? I looked but did not spot quickly. > A "real" terminal sends CR only, by default, and can be switched to > send CRLF instead (by CSI 20h; switch back with CSI 20l). You cannot do > only LF on a standard terminal. "strace cat" shows this on "enter": read(0, "\n", 131072) = 1 write(1, "\n", 1) = 1 What do I miss? > Can't you just use nc -C or similar? This is an alternative solution, yes :) > > > Segher > _______________________________________________ > SLOF mailing list > SLOF@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/slof >
On Mon, Aug 30, 2021 at 11:28:15PM +1000, Alexey Kardashevskiy wrote: > On 30/08/2021 23:10, Segher Boessenkool wrote: > >On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: > >>Currently SLOF only accepts CR (0x0d) line endings at the command prompt, > >>since this is the default line ending used on serial consoles. > > > >>However, > >>sometimes people try to connect to SLOF directly in a way that uses the > >>typical Unix LF line endings (0x0a) which are then completely ignored, > >>for example running QEMU like this: > >> > >> qemu-system-ppc64 -nodefaults \ > >> -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ > >> -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 > >> > >>and then connect to that Unix socket via "nc -U /tmp/mysocket". > >> > >>For such use cases, allow the 0x0a line ending in SLOF, too. > > > >How does that work if you feed text with CRLF combos? If it does accept > >a new line at both CR and LF, that is problematic (it violates both the > >OF and ANS specifications of ACCEPT). > > Is it in of1275 somewhere? I looked but did not spot quickly. Hrm, the text skirts the issues somewhat :-) 7.2, in any case. 1275 doesn't really say what to do with input from another source I think? If you accept a new line at both CR and LF it will accept an empty line after every "real" input line. This breaks various things (and is super annoying in the first place). > >A "real" terminal sends CR only, by default, and can be switched to > >send CRLF instead (by CSI 20h; switch back with CSI 20l). You cannot do > >only LF on a standard terminal. > > "strace cat" shows this on "enter": > > read(0, "\n", 131072) = 1 > write(1, "\n", 1) = 1 > > What do I miss? You didn't use a communications terminal. You used a UNIX program :-) Segher
On Mon, Aug 30, 2021 at 08:55:34AM -0500, Segher Boessenkool wrote: > > Is it in of1275 somewhere? I looked but did not spot quickly. > > Hrm, the text skirts the issues somewhat :-) 7.2, in any case. > > 1275 doesn't really say what to do with input from another source I > think? A source other than "the keyboard" I mean. Segher
On 30/08/2021 23:55, Segher Boessenkool wrote: > On Mon, Aug 30, 2021 at 11:28:15PM +1000, Alexey Kardashevskiy wrote: >> On 30/08/2021 23:10, Segher Boessenkool wrote: >>> On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: >>>> Currently SLOF only accepts CR (0x0d) line endings at the command prompt, >>>> since this is the default line ending used on serial consoles. >>> >>>> However, >>>> sometimes people try to connect to SLOF directly in a way that uses the >>>> typical Unix LF line endings (0x0a) which are then completely ignored, >>>> for example running QEMU like this: >>>> >>>> qemu-system-ppc64 -nodefaults \ >>>> -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ >>>> -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 >>>> >>>> and then connect to that Unix socket via "nc -U /tmp/mysocket". >>>> >>>> For such use cases, allow the 0x0a line ending in SLOF, too. >>> >>> How does that work if you feed text with CRLF combos? If it does accept >>> a new line at both CR and LF, that is problematic (it violates both the >>> OF and ANS specifications of ACCEPT). >> >> Is it in of1275 somewhere? I looked but did not spot quickly. > > Hrm, the text skirts the issues somewhat :-) 7.2, in any case. > > 1275 doesn't really say what to do with input from another source I > think? You assumed "the keyboard" because of constant use of the "keystroke" word? > If you accept a new line at both CR and LF it will accept an empty line > after every "real" input line. This breaks various things (and is super > annoying in the first place). What things does this break? >>> A "real" terminal sends CR only, by default, and can be switched to >>> send CRLF instead (by CSI 20h; switch back with CSI 20l). You cannot do >>> only LF on a standard terminal. >> >> "strace cat" shows this on "enter": >> >> read(0, "\n", 131072) = 1 >> write(1, "\n", 1) = 1 >> >> What do I miss? > > You didn't use a communications terminal. You used a UNIX program :-) Where does this communication program take the input from? ;)
On Tue, Aug 31, 2021 at 12:07:29AM +1000, Alexey Kardashevskiy wrote: > On 30/08/2021 23:55, Segher Boessenkool wrote: > >On Mon, Aug 30, 2021 at 11:28:15PM +1000, Alexey Kardashevskiy wrote: > >>On 30/08/2021 23:10, Segher Boessenkool wrote: > >>>On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: > >>>>Currently SLOF only accepts CR (0x0d) line endings at the command > >>>>prompt, > >>>>since this is the default line ending used on serial consoles. > >>> > >>>>However, > >>>>sometimes people try to connect to SLOF directly in a way that uses the > >>>>typical Unix LF line endings (0x0a) which are then completely ignored, > >>>>for example running QEMU like this: > >>>> > >>>> qemu-system-ppc64 -nodefaults \ > >>>> -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ > >>>> -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 > >>>> > >>>>and then connect to that Unix socket via "nc -U /tmp/mysocket". > >>>> > >>>>For such use cases, allow the 0x0a line ending in SLOF, too. > >>> > >>>How does that work if you feed text with CRLF combos? If it does accept > >>>a new line at both CR and LF, that is problematic (it violates both the > >>>OF and ANS specifications of ACCEPT). > >> > >>Is it in of1275 somewhere? I looked but did not spot quickly. > > > >Hrm, the text skirts the issues somewhat :-) 7.2, in any case. > > > >1275 doesn't really say what to do with input from another source I > >think? > > You assumed "the keyboard" because of constant use of the "keystroke" word? It actually talks about it constantly. See 2.3.20 "console" for a start. > >If you accept a new line at both CR and LF it will accept an empty line > >after every "real" input line. This breaks various things (and is super > >annoying in the first place). > > What things does this break? It is a common pattern to accept lines of text that encode binary data in some way, in plugin drivers for example. > >>>A "real" terminal sends CR only, by default, and can be switched to > >>>send CRLF instead (by CSI 20h; switch back with CSI 20l). You cannot do > >>>only LF on a standard terminal. > >> > >>"strace cat" shows this on "enter": > >> > >>read(0, "\n", 131072) = 1 > >>write(1, "\n", 1) = 1 > >> > >>What do I miss? > > > >You didn't use a communications terminal. You used a UNIX program :-) > > Where does this communication program take the input from? ;) I said terminal :-) A real or emulated one. Something on a serial port for example, that talks ECMA-35, ECMA-48, etc. For your UNIX program, try using stty raw (or anything else that turns off icrnl -- the emulated UNIX terminal uses CR when you press return, it is the line discipline that turns it into a LF). Segher
On 30/08/2021 15.10, Segher Boessenkool wrote: > On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: >> Currently SLOF only accepts CR (0x0d) line endings at the command prompt, >> since this is the default line ending used on serial consoles. > >> However, >> sometimes people try to connect to SLOF directly in a way that uses the >> typical Unix LF line endings (0x0a) which are then completely ignored, >> for example running QEMU like this: >> >> qemu-system-ppc64 -nodefaults \ >> -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ >> -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 >> >> and then connect to that Unix socket via "nc -U /tmp/mysocket". >> >> For such use cases, allow the 0x0a line ending in SLOF, too. > > How does that work if you feed text with CRLF combos? It's currently detected as two "RETURN" key presses ... which is bad, of course. > If it does accept > a new line at both CR and LF, that is problematic (it violates both the > OF and ANS specifications of ACCEPT). > > A "real" terminal sends CR only, by default, and can be switched to > send CRLF instead (by CSI 20h; switch back with CSI 20l). You cannot do > only LF on a standard terminal. Now that you mentioned it, yes, that now rings a bell again, I think that's the reason why we never changed this in the past ... > Can't you just use nc -C or similar? That's certainly a way to get it working with nc, too ... but the problem is that every couple of years somebody still falls into this trap and wonders why it's not working by default yet. So we should still do something about it, I think. Maybe add a proper note to the README? Or should we try to be smart and detect CRLF line endings so that they are not interpreted as two key presses anymore if we accept 0x0a line endings, too? Thomas
On Mon, Aug 30, 2021 at 06:18:50PM +0200, Thomas Huth wrote: > On 30/08/2021 15.10, Segher Boessenkool wrote: > >On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: > >>Currently SLOF only accepts CR (0x0d) line endings at the command prompt, > >>since this is the default line ending used on serial consoles. > > > >>However, > >>sometimes people try to connect to SLOF directly in a way that uses the > >>typical Unix LF line endings (0x0a) which are then completely ignored, > >>for example running QEMU like this: > >> > >> qemu-system-ppc64 -nodefaults \ > >> -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ > >> -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 > >> > >>and then connect to that Unix socket via "nc -U /tmp/mysocket". > >> > >>For such use cases, allow the 0x0a line ending in SLOF, too. > > > >How does that work if you feed text with CRLF combos? > > It's currently detected as two "RETURN" key presses ... which is bad, of > course. > > > If it does accept > >a new line at both CR and LF, that is problematic (it violates both the > >OF and ANS specifications of ACCEPT). > > > >A "real" terminal sends CR only, by default, and can be switched to > >send CRLF instead (by CSI 20h; switch back with CSI 20l). You cannot do > >only LF on a standard terminal. > > Now that you mentioned it, yes, that now rings a bell again, I think that's > the reason why we never changed this in the past ... > > >Can't you just use nc -C or similar? > > That's certainly a way to get it working with nc, too ... but the problem > is that every couple of years somebody still falls into this trap and > wonders why it's not working by default yet. So we should still do > something about it, I think. Maybe add a proper note to the README? Or > should we try to be smart and detect CRLF line endings so that they are not > interpreted as two key presses anymore if we accept 0x0a line endings, too? You also have to make sure that telnet etc. stay working. Telnet uses CRLF. And maybe the best advice is to teach people to use socat instead of netcat? It can open a pty for you and ten million other things :-) You never need any other tool anymore, say goodbye to telnet and (serial) terminal emulators and most other similar things :-) Trying to be "smart" about CR/LF detection easily backfires. It is not unusual to have more CRs than LFs in output, for example, and someone can feed that back to you. Segher
On 31/08/2021 00:44, Segher Boessenkool wrote: > On Tue, Aug 31, 2021 at 12:07:29AM +1000, Alexey Kardashevskiy wrote: >> On 30/08/2021 23:55, Segher Boessenkool wrote: >>> On Mon, Aug 30, 2021 at 11:28:15PM +1000, Alexey Kardashevskiy wrote: >>>> On 30/08/2021 23:10, Segher Boessenkool wrote: >>>>> On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: >>>>>> Currently SLOF only accepts CR (0x0d) line endings at the command >>>>>> prompt, >>>>>> since this is the default line ending used on serial consoles. >>>>> >>>>>> However, >>>>>> sometimes people try to connect to SLOF directly in a way that uses the >>>>>> typical Unix LF line endings (0x0a) which are then completely ignored, >>>>>> for example running QEMU like this: >>>>>> >>>>>> qemu-system-ppc64 -nodefaults \ >>>>>> -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ >>>>>> -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 >>>>>> >>>>>> and then connect to that Unix socket via "nc -U /tmp/mysocket". >>>>>> >>>>>> For such use cases, allow the 0x0a line ending in SLOF, too. >>>>> >>>>> How does that work if you feed text with CRLF combos? If it does accept >>>>> a new line at both CR and LF, that is problematic (it violates both the >>>>> OF and ANS specifications of ACCEPT). >>>> >>>> Is it in of1275 somewhere? I looked but did not spot quickly. >>> >>> Hrm, the text skirts the issues somewhat :-) 7.2, in any case. >>> >>> 1275 doesn't really say what to do with input from another source I >>> think? >> >> You assumed "the keyboard" because of constant use of the "keystroke" word? > > It actually talks about it constantly. See 2.3.20 "console" for a start. "Typically, a console is either an ASCII terminal connected to a serial port or the combination of a text/graphics display device and a keyboard" Here we are dealing with a serial port. > >>> If you accept a new line at both CR and LF it will accept an empty line >>> after every "real" input line. This breaks various things (and is super >>> annoying in the first place). >> >> What things does this break? > > It is a common pattern to accept lines of text that encode binary data > in some way, in plugin drivers for example. Any example in SLOF? (I am not saying we should enable 0xA, just educating myself further). >>>>> A "real" terminal sends CR only, by default, and can be switched to >>>>> send CRLF instead (by CSI 20h; switch back with CSI 20l). You cannot do >>>>> only LF on a standard terminal. >>>> >>>> "strace cat" shows this on "enter": >>>> >>>> read(0, "\n", 131072) = 1 >>>> write(1, "\n", 1) = 1 >>>> >>>> What do I miss? >>> >>> You didn't use a communications terminal. You used a UNIX program :-) >> >> Where does this communication program take the input from? ;) > > I said terminal :-) A real or emulated one. Something on a serial port > for example, that talks ECMA-35, ECMA-48, etc. > > For your UNIX program, try using stty raw (or anything else that turns > off icrnl -- the emulated UNIX terminal uses CR when you press return, > it is the line discipline that turns it into a LF). "stty raw" makes "read" return ^M"\r". _Now_ I am truly confused although this behavior explains why QEMU works.
On 31/08/2021 05.39, Alexey Kardashevskiy wrote: > > > On 31/08/2021 00:44, Segher Boessenkool wrote: >> On Tue, Aug 31, 2021 at 12:07:29AM +1000, Alexey Kardashevskiy wrote: >>> On 30/08/2021 23:55, Segher Boessenkool wrote: >>>> On Mon, Aug 30, 2021 at 11:28:15PM +1000, Alexey Kardashevskiy wrote: >>>>> On 30/08/2021 23:10, Segher Boessenkool wrote: >>>>>> On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: >>>>>>> Currently SLOF only accepts CR (0x0d) line endings at the command >>>>>>> prompt, >>>>>>> since this is the default line ending used on serial consoles. >>>>>> >>>>>>> However, >>>>>>> sometimes people try to connect to SLOF directly in a way that uses the >>>>>>> typical Unix LF line endings (0x0a) which are then completely ignored, >>>>>>> for example running QEMU like this: >>>>>>> >>>>>>> qemu-system-ppc64 -nodefaults \ >>>>>>> -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ >>>>>>> -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 >>>>>>> >>>>>>> and then connect to that Unix socket via "nc -U /tmp/mysocket". >>>>>>> >>>>>>> For such use cases, allow the 0x0a line ending in SLOF, too. >>>>>> >>>>>> How does that work if you feed text with CRLF combos? If it does accept >>>>>> a new line at both CR and LF, that is problematic (it violates both the >>>>>> OF and ANS specifications of ACCEPT). >>>>> >>>>> Is it in of1275 somewhere? I looked but did not spot quickly. >>>> >>>> Hrm, the text skirts the issues somewhat :-) 7.2, in any case. >>>> >>>> 1275 doesn't really say what to do with input from another source I >>>> think? >>> >>> You assumed "the keyboard" because of constant use of the "keystroke" word? >> >> It actually talks about it constantly. See 2.3.20 "console" for a start. > > > "Typically, a console is either an ASCII terminal connected to a serial port > or the combination of a text/graphics display device and a keyboard" > > Here we are dealing with a serial port. > > >> >>>> If you accept a new line at both CR and LF it will accept an empty line >>>> after every "real" input line. This breaks various things (and is super >>>> annoying in the first place). >>> >>> What things does this break? >> >> It is a common pattern to accept lines of text that encode binary data >> in some way, in plugin drivers for example. > > Any example in SLOF? (I am not saying we should enable 0xA, just educating > myself further). > > >>>>>> A "real" terminal sends CR only, by default, and can be switched to >>>>>> send CRLF instead (by CSI 20h; switch back with CSI 20l). You cannot do >>>>>> only LF on a standard terminal. >>>>> >>>>> "strace cat" shows this on "enter": >>>>> >>>>> read(0, "\n", 131072) = 1 >>>>> write(1, "\n", 1) = 1 >>>>> >>>>> What do I miss? >>>> >>>> You didn't use a communications terminal. You used a UNIX program :-) >>> >>> Where does this communication program take the input from? ;) >> >> I said terminal :-) A real or emulated one. Something on a serial port >> for example, that talks ECMA-35, ECMA-48, etc. >> >> For your UNIX program, try using stty raw (or anything else that turns >> off icrnl -- the emulated UNIX terminal uses CR when you press return, >> it is the line discipline that turns it into a LF). > > "stty raw" makes "read" return ^M"\r". _Now_ I am truly confused although > this behavior explains why QEMU works. I haven't looked very close, but I think QEMU is likely using cfmakeraw() on stdio by default - which then disables the INLCR bit. Thomas
On 31/08/2021 15:12, Thomas Huth wrote: > On 31/08/2021 05.39, Alexey Kardashevskiy wrote: >> >> >> On 31/08/2021 00:44, Segher Boessenkool wrote: >>> On Tue, Aug 31, 2021 at 12:07:29AM +1000, Alexey Kardashevskiy wrote: >>>> On 30/08/2021 23:55, Segher Boessenkool wrote: >>>>> On Mon, Aug 30, 2021 at 11:28:15PM +1000, Alexey Kardashevskiy wrote: >>>>>> On 30/08/2021 23:10, Segher Boessenkool wrote: >>>>>>> On Mon, Aug 30, 2021 at 12:53:08PM +0200, Thomas Huth wrote: >>>>>>>> Currently SLOF only accepts CR (0x0d) line endings at the command >>>>>>>> prompt, >>>>>>>> since this is the default line ending used on serial consoles. >>>>>>> >>>>>>>> However, >>>>>>>> sometimes people try to connect to SLOF directly in a way that >>>>>>>> uses the >>>>>>>> typical Unix LF line endings (0x0a) which are then completely >>>>>>>> ignored, >>>>>>>> for example running QEMU like this: >>>>>>>> >>>>>>>> qemu-system-ppc64 -nodefaults \ >>>>>>>> -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ >>>>>>>> -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 >>>>>>>> >>>>>>>> and then connect to that Unix socket via "nc -U /tmp/mysocket". >>>>>>>> >>>>>>>> For such use cases, allow the 0x0a line ending in SLOF, too. >>>>>>> >>>>>>> How does that work if you feed text with CRLF combos? If it does >>>>>>> accept >>>>>>> a new line at both CR and LF, that is problematic (it violates >>>>>>> both the >>>>>>> OF and ANS specifications of ACCEPT). >>>>>> >>>>>> Is it in of1275 somewhere? I looked but did not spot quickly. >>>>> >>>>> Hrm, the text skirts the issues somewhat :-) 7.2, in any case. >>>>> >>>>> 1275 doesn't really say what to do with input from another source I >>>>> think? >>>> >>>> You assumed "the keyboard" because of constant use of the >>>> "keystroke" word? >>> >>> It actually talks about it constantly. See 2.3.20 "console" for a >>> start. >> >> >> "Typically, a console is either an ASCII terminal connected to a >> serial port or the combination of a text/graphics display device and >> a keyboard" >> >> Here we are dealing with a serial port. >> >> >>> >>>>> If you accept a new line at both CR and LF it will accept an empty >>>>> line >>>>> after every "real" input line. This breaks various things (and is >>>>> super >>>>> annoying in the first place). >>>> >>>> What things does this break? >>> >>> It is a common pattern to accept lines of text that encode binary data >>> in some way, in plugin drivers for example. >> >> Any example in SLOF? (I am not saying we should enable 0xA, just >> educating myself further). >> >> >>>>>>> A "real" terminal sends CR only, by default, and can be switched to >>>>>>> send CRLF instead (by CSI 20h; switch back with CSI 20l). You >>>>>>> cannot do >>>>>>> only LF on a standard terminal. >>>>>> >>>>>> "strace cat" shows this on "enter": >>>>>> >>>>>> read(0, "\n", 131072) = 1 >>>>>> write(1, "\n", 1) = 1 >>>>>> >>>>>> What do I miss? >>>>> >>>>> You didn't use a communications terminal. You used a UNIX program :-) >>>> >>>> Where does this communication program take the input from? ;) >>> >>> I said terminal :-) A real or emulated one. Something on a serial port >>> for example, that talks ECMA-35, ECMA-48, etc. >>> >>> For your UNIX program, try using stty raw (or anything else that turns >>> off icrnl -- the emulated UNIX terminal uses CR when you press return, >>> it is the line discipline that turns it into a LF). >> >> "stty raw" makes "read" return ^M"\r". _Now_ I am truly confused >> although this behavior explains why QEMU works. > > I haven't looked very close, but I think QEMU is likely using > cfmakeraw() on stdio by default - which then disables the INLCR bit. QEMU does disable everything including INCLR, literally sets flags o 0 which is pretty much what "stty raw" does. But I'd think that not having INCLR won't produce ^M"\r".
On Tue, Aug 31, 2021 at 01:39:44PM +1000, Alexey Kardashevskiy wrote: > On 31/08/2021 00:44, Segher Boessenkool wrote: > >It is a common pattern to accept lines of text that encode binary data > >in some way, in plugin drivers for example. > > Any example in SLOF? (I am not saying we should enable 0xA, just > educating myself further). SLOF does not really do plugin drivers. It usually compiles things from surce on the fly, which is more powerful. The problem is what was modified here is the ACCEPT code, so that some strange use of one device works better. If you want to change anything it should be the driver for that one device. Is ACCEPT currently a DEFERred / hookable word? > >I said terminal :-) A real or emulated one. Something on a serial port > >for example, that talks ECMA-35, ECMA-48, etc. > > > >For your UNIX program, try using stty raw (or anything else that turns > >off icrnl -- the emulated UNIX terminal uses CR when you press return, > >it is the line discipline that turns it into a LF). > > "stty raw" makes "read" return ^M"\r". _Now_ I am truly confused > although this behavior explains why QEMU works. 00/13 (CR) is what the return key normally produces. The terminal line discipline's "cooked" mode (which is default) transforms this into a 00/10 (LF). If you go via a pty in cooked mode all will be fine. You want to go via a pty anyway, for many reasons (it buffers, to start with) :-) Segher
On Tue, Aug 31, 2021 at 04:21:37PM +1000, Alexey Kardashevskiy wrote: > >>>For your UNIX program, try using stty raw (or anything else that > >>>turns > >>>off icrnl -- the emulated UNIX terminal uses CR when you press return, > >>>it is the line discipline that turns it into a LF). > >> > >>"stty raw" makes "read" return ^M"\r". _Now_ I am truly confused > >>although this behavior explains why QEMU works. > > > >I haven't looked very close, but I think QEMU is likely using > >cfmakeraw() on stdio by default - which then disables the INLCR bit. > > QEMU does disable everything including INCLR, literally sets flags o 0 > which is pretty much what "stty raw" does. But I'd think that not having > INCLR won't produce ^M"\r". (icrnl) The return key should produce hex 0d (CR). If icrnl is on that is transformed into hex 0a (LF) (by the kernel, in the terminal line disc). Segher
On 01/09/2021 03:24, Segher Boessenkool wrote: > On Tue, Aug 31, 2021 at 01:39:44PM +1000, Alexey Kardashevskiy wrote: >> On 31/08/2021 00:44, Segher Boessenkool wrote: >>> It is a common pattern to accept lines of text that encode binary data >>> in some way, in plugin drivers for example. >> >> Any example in SLOF? (I am not saying we should enable 0xA, just >> educating myself further). > > SLOF does not really do plugin drivers. It usually compiles things > from surce on the fly, which is more powerful. > > The problem is what was modified here is the ACCEPT code, so that some > strange use of one device works better. If you want to change anything > it should be the driver for that one device. Is ACCEPT currently a > DEFERred / hookable word? deferred in a quirky way :) https://git.qemu.org/?p=SLOF.git;a=blob;f=slof/engine.in;h=549e40918ab4834ce1cf5fa8ecbf350caa4401d8;hb=HEAD#l278 >>> I said terminal :-) A real or emulated one. Something on a serial port >>> for example, that talks ECMA-35, ECMA-48, etc. >>> >>> For your UNIX program, try using stty raw (or anything else that turns >>> off icrnl -- the emulated UNIX terminal uses CR when you press return, >>> it is the line discipline that turns it into a LF). >> >> "stty raw" makes "read" return ^M"\r". _Now_ I am truly confused >> although this behavior explains why QEMU works. > > 00/13 (CR) is what the return key normally produces. The terminal line > discipline's "cooked" mode (which is default) transforms this into a > 00/10 (LF). Ah. I was confused by ^M printed in the terminal but it seems to be the gnome-terminal's echo. With "strace -o", read(0, "\n", 4096) in the default terminal and read(0, "\r", 4096) in raw (which is what QEMU sets to fd=0). Uff. Alright. > If you go via a pty in cooked mode all will be fine. You want to go > via a pty anyway, for many reasons (it buffers, to start with) :-) I am really not sure about that when I talk to the vm interactive prompt but ok.
diff --git a/slof/fs/accept.fs b/slof/fs/accept.fs index cb6f2fa..26e9216 100644 --- a/slof/fs/accept.fs +++ b/slof/fs/accept.fs @@ -392,6 +392,7 @@ TABLE-EXECUTE handle-control 1b emit 37 emit BEGIN key dup 0d <> + over 0a <> and WHILE dup 9 <> IF 0 to ?tab-pressed THEN \ reset state machine dup 7f = IF drop 8 THEN \ Handle DEL as if it was BS. ??? bogus
Currently SLOF only accepts CR (0x0d) line endings at the command prompt, since this is the default line ending used on serial consoles. However, sometimes people try to connect to SLOF directly in a way that uses the typical Unix LF line endings (0x0a) which are then completely ignored, for example running QEMU like this: qemu-system-ppc64 -nodefaults \ -chardev socket,path=/tmp/mysocket,wait=off,id=cs0,server=on \ -device spapr-vty,id=serial0,reg=0x30000000,chardev=cs0 and then connect to that Unix socket via "nc -U /tmp/mysocket". For such use cases, allow the 0x0a line ending in SLOF, too. Signed-off-by: Thomas Huth <thuth@redhat.com> --- I'm not quite sure anymore ... didn't we already run into this problem a couple of times in the past already? Was there a reason that we never allowed 0x0a here, too? slof/fs/accept.fs | 1 + 1 file changed, 1 insertion(+)