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

Segher Boessenkool segher at kernel.crashing.org
Wed Sep 1 03:24:08 AEST 2021

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?

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

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) :-)


More information about the SLOF mailing list