linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <alan@linux.intel.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Rob Herring <robh@kernel.org>,
	Peter Hurley <peter@hurleysoftware.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
Date: Mon, 03 Apr 2017 19:05:19 +0100	[thread overview]
Message-ID: <1491242719.3704.33.camel@linux.intel.com> (raw)
In-Reply-To: <alpine.LFD.2.20.1704031121520.1847@knanqh.ubzr>

> evertheless very convenient to be able to use a standard
> shell 
> with it.

A standard shell will work over things other than a tty device. It
really doesn't care so long as it gets a stream of data punctuated by
end of statement symbols. It'll work over pipes, sockets, from files.

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

I said the combination makes it more unmaintainable. If you have two
tty layers one of them faking the API of the other at various interface
points then if the core tty layer wants to make a major change it no
longer can - because it'll break the other tty layer. In addition I
worry it won't be long before someone wants kgdb, gdbstubs and sysrq
over the cut down console and on it will go.

The uart layer is also known broken as an API - it is itself bloated
and over-locking (for example if it was being written today kfifo would
be used). What happens if we want to abolish it or encourage people to
move away from it (as we IMHO should be) ?

The serio code started with exactly the same problem, but now at least
talks tty layer. In your case you are tying it to something we
eventually ought to get rid of.

I also find the large scale need for it hard to believe. If you are
within 64K of running out of memory on your debug/devel device how are
you going to have space to fix security holes and do upgrades as they
occur in production (where presumably you don't need the tty driver) ?
The kernel doesn't exactly get smaller each release.

Alan

  reply	other threads:[~2017-04-03 18:05 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
2017-04-03 18:05         ` Alan Cox [this message]
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=1491242719.3704.33.camel@linux.intel.com \
    --to=alan@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=peter@hurleysoftware.com \
    --cc=robh@kernel.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).