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

[Thomas Huth]

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