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

[Alexey Kardashevskiy]

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.



-- 
Alexey