[SLOF] [PATCH] slof/fs/accept: Allow Unix LF line endings, too

[Segher Boessenkool]

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