[SLOF] [PATCH] slof/fs/accept: Allow Unix LF line endings, too
Alexey Kardashevskiy
aik at ozlabs.ru
Tue Aug 31 13:39:44 AEST 2021
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
More information about the SLOF
mailing list