From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Jiri Slaby <jslaby@suse.com>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
Date: Mon, 3 Apr 2017 09:44:37 +0200 [thread overview]
Message-ID: <20170403074437.GA20683@kroah.com> (raw)
In-Reply-To: <20170401222119.25106-1-nicolas.pitre@linaro.org>
On Sat, Apr 01, 2017 at 06:21:14PM -0400, Nicolas Pitre wrote:
> Many embedded systems don't need the full TTY layer support. Most of the
> time, the TTY layer is only a conduit for outputting debugging messages
> over a serial port. The TTY layer also implements many features that are
> very unlikely to ever be used in such a setup. There is great potential
> for both code and dynamic memory size reduction on small systems. This is
> what this patch series is achieving.
>
> The existing TTY code is quite large and complex. Trying to shrink it
> is risky as the potential for breakage is non negligeable, and its
> interchangeable layers impose a lower limit on the code to implement it.
> Therefore, the approach used here consists in the creation of a parallel
> implementation with the very minimal amount of code collapsed together
> that interfaces with existing UART drivers directly and provides TTY-like
> character devices to user space. When the regular TTY layer is disabled,
> then this minitty alternative layer is proposed by Kconfig.
>
> For more details on the rationale and motivations driving this approach
> please see: https://lkml.org/lkml/2017/3/24/634
>
> Of course, making it "mini" means there are limitations to what it does:
>
> - This supports serial ports only. No VT's, no PTY's.
>
> - The default n_tty line discipline is hardcoded and no other line
> discipline are supported.
>
> - The line discipline features are not all implemented. Notably, XON/XOFF
> is currently not implemented (although this might not require a lot of
> code to do it if someone were to need it).
>
> - Hung-up state is not implemented.
>
> - No error handling on RX bytes other than counting them.
>
> - Job control is currently not supported (this may change in the future and
> be configurable).
>
> But again, most small embedded systems simply don't need those things.
>
> This can be used on any architecture of course, but here's some numbers
> using a minimal ARM config.
>
> When CONFIG_TTY=y, the following files are linked into the kernel:
>
> text data bss dec hex filename
> 8796 128 0 8924 22dc drivers/tty/n_tty.o
> 11809 276 0 12085 2f35 drivers/tty/serial/fulltty_serial.o
> 1376 0 0 1376 560 drivers/tty/tty_buffer.o
> 13571 172 132 13875 3633 drivers/tty/tty_io.o
> 3072 0 0 3072 c00 drivers/tty/tty_ioctl.o
> 2457 2 120 2579 a13 drivers/tty/tty_ldisc.o
> 1328 0 0 1328 530 drivers/tty/tty_ldsem.o
> 316 0 0 316 13c drivers/tty/tty_mutex.o
> 2516 0 0 2516 9d4 drivers/tty/tty_port.o
> 45241 578 252 46071 b3f7 (TOTALS)
>
> When CONFIG_TTY=n and CONFIG_MINITTY_SERIAL=y, the above files are replaced
> by the following:
>
> text data bss dec hex filename
> 8063 8 64 8135 1fc7 drivers/tty/serial/minitty_serial.o
>
> That's it! And the runtime buffer usage is much less as well. Future plans
> such as removing runtime baudrate handling for those targets with a known
> fixed baudrate will shrink the code even more.
Thanks for the resend. I agree with your goal of getting Linux running
on these very tiny chips, I want that to happen too. I'm traveling at
the moment for the next 2 weeks, but will review it in detail when I get
back. It's in my queue, don't worry, it's not lost.
Ideally others would review it as well...
thanks,
greg k-h
prev parent reply other threads:[~2017-04-03 7:44 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
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 [this message]
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=20170403074437.GA20683@kroah.com \
--to=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 \
/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).