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

[Thomas Huth]

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