linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: nicolas.pitre@linaro.org (Nicolas Pitre)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
Date: Mon, 3 Apr 2017 12:06:55 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.20.1704031121520.1847@knanqh.ubzr> (raw)
In-Reply-To: <1491224186.3704.11.camel@linux.intel.com>

On Mon, 3 Apr 2017, Alan Cox wrote:

> If you need a tiny tiny tty layer console for some kind of not quite
> mini-Linux please just steal the one from Fuzix or something similar
> thats only a couple of K in size and only needs extremely simple send
> byte/rx byte type handlers.

This, however, requires that every UART driver be rewritten to suit this 
code. I don't want to lose one of Linux's best advantage which is 
extensive hardware support. I want to reuse as much of the existing 
hardware drivers as possible unchanged.

I already have code that fits the Linux model and it weights 
only 8K.

> Alternatively just compile out tty support entirely. What do you
> actually need ? Console doesn't need tty layer and if you have a
> debug/management interface that doesn't have to be tty and text based
> either.

It is nevertheless very convenient to be able to use a standard shell 
with it. I can easily remove canonical mode support and then it is down 
to 7.3K. Modem line control and runtime baudrate handling could also 
trivially be configured out for yet more saving.

> Being able to compile out tty support would be useful, having two tty
> layers that are intertwined and now both totally unmaintable is not
> IMHO progress.

I beg to disagree here.  First, before you call my code "totally 
unmaintainable" I'd politely ask you to have a look at it first.

There is also very little intertwining here. My code does not rely on 
the existing TTY code (except for the termios baudrate handling which I 
factored out). I'm creating my own char devices on one end and 
interacting with UART drivers using the same low-level call interface 
used by the existing code at the other end. And given that it is much 
simpler in termps of capabilities, it is also very easy to maintain.


Nicolas

  reply	other threads:[~2017-04-03 16:06 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01 22:21 [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems Nicolas Pitre
2017-04-01 22:21 ` [PATCH v2 1/5] console: move console_init() out of tty_io.c Nicolas Pitre
2017-04-01 22:21 ` [PATCH v2 2/5] tty: move baudrate handling code to a file of its own Nicolas Pitre
2017-04-01 22:21 ` [PATCH v2 3/5] serial: small Makefile reordering Nicolas Pitre
2017-04-02 12:55   ` Andy Shevchenko
2017-04-02 15:49     ` Nicolas Pitre
2017-04-01 22:21 ` [PATCH v2 4/5] serial: split generic UART driver helper functions into a separate file Nicolas Pitre
2017-04-02 13:16   ` Andy Shevchenko
2017-04-02 15:44     ` Nicolas Pitre
2017-04-03  7:35   ` kbuild test robot
2017-04-01 22:21 ` [PATCH v2 5/5] minitty: minimal TTY support alternative for serial ports Nicolas Pitre
2017-04-02 13:22 ` [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems Andy Shevchenko
2017-04-02 15:55   ` Nicolas Pitre
2017-04-03 12:56     ` Alan Cox
2017-04-03 16:06       ` Nicolas Pitre [this message]
2017-04-03 18:05         ` Alan Cox
2017-04-03 19:50           ` Nicolas Pitre
2017-04-04 13:40             ` Alan Cox
2017-04-04 19:26               ` Nicolas Pitre
2017-04-02 20:47 ` Andi Kleen
2017-04-02 21:41   ` Nicolas Pitre
2017-04-02 22:44     ` Stuart Longland
2017-04-03  1:01       ` Nicolas Pitre
2017-04-04  0:39         ` Stuart Longland
2017-04-03 18:14       ` Geert Uytterhoeven
2017-04-03 18:57         ` Rob Herring
2017-04-03 19:46           ` Geert Uytterhoeven
2017-04-03 21:05         ` Andy Shevchenko
2017-04-04 16:59           ` Tom Zanussi
2017-04-04 17:08             ` Andy Shevchenko
2017-04-04 17:59               ` Tom Zanussi
2017-04-04 18:04                 ` Andy Shevchenko
2017-04-04 18:31                   ` Nicolas Pitre
2017-04-04 19:58                   ` Tom Zanussi
2017-04-04 20:27                     ` Nicolas Pitre
2017-04-04 18:53             ` Nicolas Pitre
2017-04-03  7:54     ` Andy Shevchenko
2017-04-03 15:31       ` Andi Kleen
2017-04-03 17:27         ` Nicolas Pitre
2017-04-03 19:57         ` Adam Borowski
2017-04-03 20:09           ` Nicolas Pitre
2017-04-03 20:32             ` Adam Borowski
2017-04-03 16:40       ` Nicolas Pitre
2017-04-03  7:44 ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.20.1704031121520.1847@knanqh.ubzr \
    --to=nicolas.pitre@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).