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

Alexey Kardashevskiy aik at ozlabs.ru
Wed Sep 1 11:39:25 AEST 2021

On 01/09/2021 03:24, Segher Boessenkool wrote:
> On Tue, Aug 31, 2021 at 01:39:44PM +1000, Alexey Kardashevskiy wrote:
>> On 31/08/2021 00:44, Segher Boessenkool wrote:
>>> 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).
> SLOF does not really do plugin drivers.  It usually compiles things
> from surce on the fly, which is more powerful.
> The problem is what was modified here is the ACCEPT code, so that some
> strange use of one device works better.  If you want to change anything
> it should be the driver for that one device.  Is ACCEPT currently a
> DEFERred / hookable word?

deferred in a quirky way :)


>>> 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.
> 00/13 (CR) is what the return key normally produces.  The terminal line
> discipline's "cooked" mode (which is default) transforms this into a
> 00/10 (LF).

Ah. I was confused by ^M printed in the terminal but it seems to be the 
gnome-terminal's echo. With "strace -o",

read(0, "\n", 4096) in the default terminal and
read(0, "\r", 4096) in raw (which is what QEMU sets to fd=0).

Uff. Alright.

> If you go via a pty in cooked mode all will be fine.  You want to go
> via a pty anyway, for many reasons (it buffers, to start with) :-)

I am really not sure about that when I talk to the vm interactive prompt 
but ok.


More information about the SLOF mailing list