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

[Alexey Kardashevskiy]

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".


-- 
Alexey