Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1614606 > unrolled thread

[PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-02 00:40 +0200
    Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-02 15:30 +0200
      Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-02 18:00 +0200
        Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Alan Cox <alan@linux.intel.com> - 2017-04-03 15:00 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 18:10 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Alan Cox <alan@linux.intel.com> - 2017-04-03 20:10 +0200
              Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 22:00 +0200
                Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Alan Cox <alan@linux.intel.com> - 2017-04-04 15:50 +0200
                  Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-04 21:30 +0200
    Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems Andi Kleen <andi@firstfloor.org> - 2017-04-02 22:50 +0200
      Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-02 23:50 +0200
        Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Stuart Longland <stuartl@longlandclan.id.au> - 2017-04-03 01:00 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 03:10 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Stuart Longland <stuartl@longlandclan.id.au> - 2017-04-04 02:50 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-03 20:20 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Rob Herring <robh@kernel.org> - 2017-04-03 21:00 +0200
              Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-03 21:50 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-03 23:10 +0200
              Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Tom Zanussi <tom.zanussi@linux.intel.com> - 2017-04-04 19:00 +0200
                Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-04 19:10 +0200
                  Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Tom Zanussi <tom.zanussi@linux.intel.com> - 2017-04-04 20:00 +0200
                    Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-04 20:10 +0200
                      Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-04 20:40 +0200
                      Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Tom Zanussi <tom.zanussi@linux.intel.com> - 2017-04-04 22:00 +0200
                        Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-04 22:30 +0200
                Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-04 21:00 +0200
        Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-03 10:00 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andi Kleen <andi@firstfloor.org> - 2017-04-03 17:40 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 19:30 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Adam Borowski <kilobyte@angband.pl> - 2017-04-03 22:00 +0200
              Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 22:10 +0200
                Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Adam Borowski <kilobyte@angband.pl> - 2017-04-03 22:40 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 18:50 +0200
    Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-03 09:50 +0200

Page 1 of 2  [1] 2  Next page →

#1614606 — [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

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.

Changes from v1:

- Added an entry to the MAINTAINERS file.
- Factored out more common core code into serial_lib.c.
- Implemented a few more TTY callback functions to be compatible with
  more UART drivers.

Overall diffstat:

 MAINTAINERS                                     |    8 +-
 drivers/tty/Kconfig                             |   10 +-
 drivers/tty/Makefile                            |    3 +-
 drivers/tty/serial/Kconfig                      |   12 +-
 drivers/tty/serial/Makefile                     |    7 +-
 .../serial/{serial_core.c => fulltty_serial.c}  |  419 +---
 drivers/tty/serial/minitty_serial.c             | 1793 +++++++++++++++++
 drivers/tty/serial/serial_lib.c                 |  440 ++++
 drivers/tty/tty_baudrate.c                      |  232 +++
 drivers/tty/tty_io.c                            |   24 -
 drivers/tty/tty_ioctl.c                         |  222 --
 include/linux/console.h                         |    2 +
 include/linux/serial_core.h                     |    1 +
 include/linux/tty.h                             |    7 +-
 include/linux/tty_flip.h                        |    9 +
 init/main.c                                     |    2 +-
 kernel/printk/printk.c                          |   24 +
 17 files changed, 2538 insertions(+), 677 deletions(-)

[toc] | [next] | [standalone]

#1614734 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

+Cc people, who have a key roles in all TTY stuff (btw, why you did
miss them? why you didn't include people who reacted on your v1
either?).
I'm pretty sure they are interested in what's going on here.

On Sun, Apr 2, 2017 at 1:21 AM, Nicolas Pitre <nicolas.pitre@linaro.org> 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
>   5241     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.
>
> Changes from v1:
>
> - Added an entry to the MAINTAINERS file.
> - Factored out more common core code into serial_lib.c.
> - Implemented a few more TTY callback functions to be compatible with
>   more UART drivers.
>
> Overall diffstat:
>
>  MAINTAINERS                                     |    8 +-
>  drivers/tty/Kconfig                             |   10 +-
>  drivers/tty/Makefile                            |    3 +-
>  drivers/tty/serial/Kconfig                      |   12 +-
>  drivers/tty/serial/Makefile                     |    7 +-
>  .../serial/{serial_core.c => fulltty_serial.c}  |  419 +---
>  drivers/tty/serial/minitty_serial.c             | 1793 +++++++++++++++++
>  drivers/tty/serial/serial_lib.c                 |  440 ++++
>  drivers/tty/tty_baudrate.c                      |  232 +++
>  drivers/tty/tty_io.c                            |   24 -
>  drivers/tty/tty_ioctl.c                         |  222 --
>  include/linux/console.h                         |    2 +
>  include/linux/serial_core.h                     |    1 +
>  include/linux/tty.h                             |    7 +-
>  include/linux/tty_flip.h                        |    9 +
>  init/main.c                                     |    2 +-
>  kernel/printk/printk.c                          |   24 +
>  17 files changed, 2538 insertions(+), 677 deletions(-)



-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1614762 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Sun, 2 Apr 2017, Andy Shevchenko wrote:

> +Cc people, who have a key roles in all TTY stuff (btw, why you did
> miss them?

I used what MAINTAINERS and get_maintainer.pl gave me.

> why you didn't include people who reacted on your v1
> either?).
> I'm pretty sure they are interested in what's going on here.

The only one I missed is Ard.

Thanks for pulling more people in.


> 
> On Sun, Apr 2, 2017 at 1:21 AM, Nicolas Pitre <nicolas.pitre@linaro.org> 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
> >   5241     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.
> >
> > Changes from v1:
> >
> > - Added an entry to the MAINTAINERS file.
> > - Factored out more common core code into serial_lib.c.
> > - Implemented a few more TTY callback functions to be compatible with
> >   more UART drivers.
> >
> > Overall diffstat:
> >
> >  MAINTAINERS                                     |    8 +-
> >  drivers/tty/Kconfig                             |   10 +-
> >  drivers/tty/Makefile                            |    3 +-
> >  drivers/tty/serial/Kconfig                      |   12 +-
> >  drivers/tty/serial/Makefile                     |    7 +-
> >  .../serial/{serial_core.c => fulltty_serial.c}  |  419 +---
> >  drivers/tty/serial/minitty_serial.c             | 1793 +++++++++++++++++
> >  drivers/tty/serial/serial_lib.c                 |  440 ++++
> >  drivers/tty/tty_baudrate.c                      |  232 +++
> >  drivers/tty/tty_io.c                            |   24 -
> >  drivers/tty/tty_ioctl.c                         |  222 --
> >  include/linux/console.h                         |    2 +
> >  include/linux/serial_core.h                     |    1 +
> >  include/linux/tty.h                             |    7 +-
> >  include/linux/tty_flip.h                        |    9 +
> >  init/main.c                                     |    2 +-
> >  kernel/printk/printk.c                          |   24 +
> >  17 files changed, 2538 insertions(+), 677 deletions(-)
> 
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 

[toc] | [prev] | [next] | [standalone]

#1615180 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Sun, 2017-04-02 at 11:55 -0400, Nicolas Pitre wrote:
> On Sun, 2 Apr 2017, Andy Shevchenko wrote:
> 
> > 
> > +Cc people, who have a key roles in all TTY stuff (btw, why you did
> > miss them?
> 
> I used what MAINTAINERS and get_maintainer.pl gave me.
> 

I didn't see this until now as I'm mid house move so not following a
lot of l/k.

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.

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.

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.

Alan

[toc] | [prev] | [next] | [standalone]

#1615370 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

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

[toc] | [prev] | [next] | [standalone]

#1615455 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

> 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

[toc] | [prev] | [next] | [standalone]

#1615524 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

[Multipart message — attachments visible in raw view] — view raw

On Mon, 3 Apr 2017, Alan Cox wrote:

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

But no job control. No line editing with echo when the shell is busy, 
etc.

And actually it is not the TTY support per se that takes the most code. 
Just the chardev read/write/poll/open/release stuff is rather 
significant. Removing canonical support makes it 7.3K down from 8K. 
Removing echo support makes it down to 7.2K. Removing baudrate support = 
7.0K. Copying termios to/from user space is horrid: removing that and 
we're down to 5.6K. At which point there's only a raw device interface 
to serial hardware.

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

sysrq is already there. It is handled directly at the UART driver level. 
I didn't have to do anything for it.

Isn't kgdb and gdbstubs the same thing?  In any case the TTY layer is 
also already completely bypassed in that case. Those are in fact just 
like kernel console targets that also can read and not just write.

Again, what I'm using is the same low-level UART interface as 
drivers/tty/serial/serial_core.c is using to interact with UART drivers. 
If someone wants to make a change to that interface, the 30 or so UART 
drivers will have to be changed as well. I don't think that would be a 
big deal to change the minitty code to follow suit. And I won't hide 
under a rock while this happens.

If you're making a change in any of the rest of the existing TTY stack, 
then my code won't care as it does not interact with it. I'm not even 
using tty_struct at all!

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

Same answer as above.

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

You won't get rid of UART drivers, right?

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

Some production devices can do it all in much less RAM than that and 
they are being connected to the net. Don't worry, that's not where I see 
any Linux derivative go.

Some devices, though, have 256K of on-chip RAM. Those devices will make 
it into your surrounding. Having so much more RAM (no pun intended) 
they'll be capable of even more damage. Would you be more confident, 
when a security issue arises (because it will), to know that some Linux 
code base is used rather than any random RTOS out there with only one 
hundredth of the actual Linux following? If so please indulge me a bit.

> The kernel doesn't exactly get smaller each release.

No kidding.

This is why a slight shift in the Linux model has to be accommodated 
for. We cannot just have a single subsystem to scale to both extremes 
all the time anymore.  We already have different memory allocators for 
different sizes and needs so precedents do exist.

The greatest value in Linux his its interfaces. Doesn't matter if the 
kernel internal interfaces change, the value is in having common 
interfaces for all Linux developers available anywhere. We should allow 
for parallel implementations of subsystems as long as they remain 
interchangeable. Hence this mini TTY alternative, and that's only the 
beginning.

I'd invite you to read more of the rationale for that here:

https://lkml.org/lkml/2017/3/24/634

It's rather long and I don't want to repeat it all.


Nicolas

[toc] | [prev] | [next] | [standalone]

#1616039 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

> But no job control. No line editing with echo when the shell is
> busy, 
> etc.

This is a debug interface. If RAM is that precious do the line editing
on the other end of the link, like normal sane RTOS people do. Most
terminal apps support line by line modes.

> we're down to 5.6K. At which point there's only a raw device
> interface 
> to serial hardware.

Which if you did a simple plain chardev without trying to fake the
rather out of date uart layer would come down way further still.

>  the same low-level UART interface as 
> drivers/tty/serial/serial_core.c is using to interact with UART
> drivers. 
> If someone wants to make a change to that interface, the 30 or so
> UART 
> drivers will have to be changed as well. I don't think that would be
> a 
> big deal to change the minitty code to follow suit. And I won't hide 
> under a rock while this happens.

Fair enough.


> > talks tty layer. In your case you are tying it to something we
> > eventually ought to get rid of.
> 
> You won't get rid of UART drivers, right?

Given infinite time the uart layer ought to go away and be replaced
with a simple kfifo queue.

> vices, though, have 256K of on-chip RAM. Those devices will
> make 
> it into your surrounding. Having so much more RAM (no pun intended) 
> they'll be capable of even more damage. Would you be more confident, 
> when a security issue arises (because it will), to know that some
> Linux 
> code base is used rather than any random RTOS out there with only
> one 
> hundredth of the actual Linux following? If so please indulge me a
> bit.

Actually for any safety critical system both terrify me about as much.
None of them are generally written to any appropriate ISO safety
standard, or in an appropriate language.

I did read your rationale. I am deeply dubious that re-doing the uart
layer is the right approach versus just doing a tiny char device, but
I've said my piece.

Alan

[toc] | [prev] | [next] | [standalone]

#1616351 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

[Multipart message — attachments visible in raw view] — view raw

On Tue, 4 Apr 2017, Alan Cox wrote:

> > we're down to 5.6K. At which point there's only a raw device
> > interface 
> > to serial hardware.
> 
> Which if you did a simple plain chardev without trying to fake the
> rather out of date uart layer would come down way further still.

Oh absolutely. I don't dispute that. Given infinite time as you said.

But I gained a 5x reduction already. I would prefer moving to some other 
part of the kernel where another 5x reduction could be achieved now 
rather than postponing that after I'm done rewriting the interface for 
all UART drivers.  Maybe someone else will feel inspired and take on 
this UART driver modernizing task (that could be a nice mentorred 
project for example).

PS: FUZIX is a real piece of art  ;-)


Nicolas

[toc] | [prev] | [next] | [standalone]

#1614812

Nicolas Pitre <nicolas.pitre@linaro.org> writes:
>
> Of course, making it "mini" means there are limitations to what it does:
>
> - This supports serial ports only. No VT's, no PTY's.

No PTYs seems like a big limitation. This means no sshd?

> But again, most small embedded systems simply don't need those things.

They don't need a (debug) way to login over the network? Hard to
believe.

Most of the other stuff we could indeed do without even on larger
systems.

-Andi

[toc] | [prev] | [next] | [standalone]

#1614826 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Sun, 2 Apr 2017, Andi Kleen wrote:

> Nicolas Pitre <nicolas.pitre@linaro.org> writes:
> >
> > Of course, making it "mini" means there are limitations to what it does:
> >
> > - This supports serial ports only. No VT's, no PTY's.
> 
> No PTYs seems like a big limitation. This means no sshd?

Again, my ultimate system target is in the sub-megabyte of RAM.  I 
really doubt you'll be able to fit an SSH server in there even if PTYs 
were supported, unless sshd (or dropbear) can be made really tiny. 
Otherwise you most probably have sufficient resources to run the regular 
TTY code.

That being said, maybe there could be a way to cheaply support PTYs. I 
just didn't investigate it.

> > But again, most small embedded systems simply don't need those things.
> 
> They don't need a (debug) way to login over the network? Hard to
> believe.

This most likely won't be via a standard shell.


Nicolas

[toc] | [prev] | [next] | [standalone]

#1614837 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

[Multipart message — attachments visible in raw view] — view raw

On 03/04/17 07:41, Nicolas Pitre wrote:
>> No PTYs seems like a big limitation. This means no sshd?
> Again, my ultimate system target is in the sub-megabyte of RAM.  I 
> really doubt you'll be able to fit an SSH server in there even if PTYs 
> were supported, unless sshd (or dropbear) can be made really tiny. 
> Otherwise you most probably have sufficient resources to run the regular 
> TTY code.

Are we talking small microcontrollers here?  The smallest machine in
terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
RAM, and that had a MMU.

I recall Slackware requiring that you booted with a mounted floppy (no
ramdisk) and possibly even required that you had a second floppy drive
formatted as swap so you'd be able to get through the install without
oomkiller knocking on your door.

The same machine could also "run" Windows 95.  When I say "run", it was
more like a slow crawl.  Bull sharks washed onto land by flood waters
run faster.

Sub-megabyte system support is a noble goal, but I'm wondering how
practical such systems would be, and whether an embedded real-time
kernel might be a better choice than Linux on such systems.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

[toc] | [prev] | [next] | [standalone]

#1614851 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, 3 Apr 2017, Stuart Longland wrote:

> On 03/04/17 07:41, Nicolas Pitre wrote:
> >> No PTYs seems like a big limitation. This means no sshd?
> > Again, my ultimate system target is in the sub-megabyte of RAM.  I 
> > really doubt you'll be able to fit an SSH server in there even if PTYs 
> > were supported, unless sshd (or dropbear) can be made really tiny. 
> > Otherwise you most probably have sufficient resources to run the regular 
> > TTY code.
> 
> Are we talking small microcontrollers here?  The smallest machine in
> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
> RAM, and that had a MMU.

Not to repeat what I've said already, I invite you to have a look at 
https://lkml.org/lkml/2017/3/24/634

> I recall Slackware requiring that you booted with a mounted floppy (no
> ramdisk) and possibly even required that you had a second floppy drive
> formatted as swap so you'd be able to get through the install without
> oomkiller knocking on your door.

Did the oom killer even exist in those days? I don't remember.
All I remember is the stack of 73 flopies or so to install Slackware... 
and of course floppy #68 would have developed a bad sector preventing 
you from completing the installation.

> Sub-megabyte system support is a noble goal, but I'm wondering how
> practical such systems would be, and whether an embedded real-time
> kernel might be a better choice than Linux on such systems.

Obviously, you need to leave the idea of a _distribution_ behind. If you 
think of a single user app, and a kernel that only provides those 
syscalls used by that app, and the minimal subset of kernel services 
that such an app require, then nothing prevents such and app/kernel from 
using the actual Linux API. And that's where you get a big advantage 
over other RTOSes. See the link above for the full rationale.


Nicolas

[toc] | [prev] | [next] | [standalone]

#1615637 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

[Multipart message — attachments visible in raw view] — view raw

On 03/04/17 11:01, Nicolas Pitre wrote:
> On Mon, 3 Apr 2017, Stuart Longland wrote:
>> On 03/04/17 07:41, Nicolas Pitre wrote:
>>>> No PTYs seems like a big limitation. This means no sshd?
>>> Again, my ultimate system target is in the sub-megabyte of RAM.  I 
>>> really doubt you'll be able to fit an SSH server in there even if PTYs 
>>> were supported, unless sshd (or dropbear) can be made really tiny. 
>>> Otherwise you most probably have sufficient resources to run the regular 
>>> TTY code.
>>
>> Are we talking small microcontrollers here?  The smallest machine in
>> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
>> RAM, and that had a MMU.
> 
> Not to repeat what I've said already, I invite you to have a look at 
> https://lkml.org/lkml/2017/3/24/634
> 
>> I recall Slackware requiring that you booted with a mounted floppy (no
>> ramdisk) and possibly even required that you had a second floppy drive
>> formatted as swap so you'd be able to get through the install without
>> oomkiller knocking on your door.
> 
> Did the oom killer even exist in those days? I don't remember.
> All I remember is the stack of 73 flopies or so to install Slackware... 
> and of course floppy #68 would have developed a bad sector preventing 
> you from completing the installation.

It probably didn't, my memory is a bit hazy, even though the machine in
question was long obsolete by the time I did this experiment.  The
version of Slackware was pretty old by that time too.

Luckily for me, I had a network, I could mount the CD disk sets over NFS
that way, and so the only floppies I had to worry about were the boot
and root floppies.

But I digress… :-)

>> Sub-megabyte system support is a noble goal, but I'm wondering how
>> practical such systems would be, and whether an embedded real-time
>> kernel might be a better choice than Linux on such systems.
> 
> Obviously, you need to leave the idea of a _distribution_ behind. If you 
> think of a single user app, and a kernel that only provides those 
> syscalls used by that app, and the minimal subset of kernel services 
> that such an app require, then nothing prevents such and app/kernel from 
> using the actual Linux API. And that's where you get a big advantage 
> over other RTOSes. See the link above for the full rationale.

Fair enough… so basically using the Linux kernel in place of an embedded
kernel like FreeRTOS or eCos.  Still, as I say a noble goal, I wish the
project well.  I guess it can be our answer to RetroBSD. :-)
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

[toc] | [prev] | [next] | [standalone]

#1615459 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
<stuartl@longlandclan.id.au> wrote:
> On 03/04/17 07:41, Nicolas Pitre wrote:
>>> No PTYs seems like a big limitation. This means no sshd?
>> Again, my ultimate system target is in the sub-megabyte of RAM.  I
>> really doubt you'll be able to fit an SSH server in there even if PTYs
>> were supported, unless sshd (or dropbear) can be made really tiny.
>> Otherwise you most probably have sufficient resources to run the regular
>> TTY code.
>
> Are we talking small microcontrollers here?  The smallest machine in
> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
> RAM, and that had a MMU.

Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
Of course with swap enabled.  And swapping like hell.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1615476 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 3, 2017 at 1:14 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
> <stuartl@longlandclan.id.au> wrote:
>> On 03/04/17 07:41, Nicolas Pitre wrote:
>>>> No PTYs seems like a big limitation. This means no sshd?
>>> Again, my ultimate system target is in the sub-megabyte of RAM.  I
>>> really doubt you'll be able to fit an SSH server in there even if PTYs
>>> were supported, unless sshd (or dropbear) can be made really tiny.
>>> Otherwise you most probably have sufficient resources to run the regular
>>> TTY code.
>>
>> Are we talking small microcontrollers here?  The smallest machine in
>> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
>> RAM, and that had a MMU.
>
> Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
> Of course with swap enabled.  And swapping like hell.

These are different target uses. We're talking about fixed function,
statically linked user space at the minimum (some may want no
userspace even). Applications that could use an RTOS instead but
benefit from the Linux hardware support, features and ecosystem. It's
not a whole new code base or environment to learn. Maybe Zephyr will
have traction and improve things, but projects I've been involved with
using RTOSs generally have discussions around needing to re-write the
crappy RTOS.

The absolute amount of RAM target is not so important. What's
important is getting to a size feasible for onchip RAM. That's always
moving (up), but has generally been out of reach for Linux.

Rob

[toc] | [prev] | [next] | [standalone]

#1615519 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 3, 2017 at 8:57 PM, Rob Herring <robh@kernel.org> wrote:
> On Mon, Apr 3, 2017 at 1:14 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
>> <stuartl@longlandclan.id.au> wrote:
>>> On 03/04/17 07:41, Nicolas Pitre wrote:
>>>>> No PTYs seems like a big limitation. This means no sshd?
>>>> Again, my ultimate system target is in the sub-megabyte of RAM.  I
>>>> really doubt you'll be able to fit an SSH server in there even if PTYs
>>>> were supported, unless sshd (or dropbear) can be made really tiny.
>>>> Otherwise you most probably have sufficient resources to run the regular
>>>> TTY code.
>>>
>>> Are we talking small microcontrollers here?  The smallest machine in
>>> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
>>> RAM, and that had a MMU.
>>
>> Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
>> Of course with swap enabled.  And swapping like hell.
>
> These are different target uses. We're talking about fixed function,
> statically linked user space at the minimum (some may want no
> userspace even). Applications that could use an RTOS instead but
> benefit from the Linux hardware support, features and ecosystem. It's
> not a whole new code base or environment to learn. Maybe Zephyr will
> have traction and improve things, but projects I've been involved with
> using RTOSs generally have discussions around needing to re-write the
> crappy RTOS.

Sure. I just wanted to point out that there was a time you could have
_more_ than you need for small fixed function embedded systems in
2 MiB of RAM.

> The absolute amount of RAM target is not so important. What's
> important is getting to a size feasible for onchip RAM. That's always
> moving (up), but has generally been out of reach for Linux.

DigiKey shows 39 ARM SoCs with 1 MiB or more of RAM.
But once you want 3 MiB or more, the lone winner is Renesas' RZ/A1 (up to
10 MiB).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1615554 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

+Cc: Tom

Summon Tom to the discussion. He tried once hard to shrink a Linux
kernel to something working in 1M+ RAM on x86.

Tom, sorry, I recall this a bit late, perhaps you might be interested
in reading discussion from the beginning.

On Mon, Apr 3, 2017 at 9:14 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
> <stuartl@longlandclan.id.au> wrote:
>> On 03/04/17 07:41, Nicolas Pitre wrote:
>>>> No PTYs seems like a big limitation. This means no sshd?
>>> Again, my ultimate system target is in the sub-megabyte of RAM.  I
>>> really doubt you'll be able to fit an SSH server in there even if PTYs
>>> were supported, unless sshd (or dropbear) can be made really tiny.
>>> Otherwise you most probably have sufficient resources to run the regular
>>> TTY code.
>>
>> Are we talking small microcontrollers here?  The smallest machine in
>> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
>> RAM, and that had a MMU.
>
> Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
> Of course with swap enabled.  And swapping like hell.


-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1616210 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

Hi,

On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
> +Cc: Tom
> 
> Summon Tom to the discussion. He tried once hard to shrink a Linux
> kernel to something working in 1M+ RAM on x86.
> 

Yes, in a previous project, I had been working toward getting a < 1M
system to boot on Galileo hardware (which it did, but using more than
that - the Galileo2 has 256MB, but it was the target hardware at the
time, and I was hoping eventually to be able to boot out of the 512k
on-chip SRAM).

I was focused at that point mainly on the kernel static size, and using
a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
net-diet patches, and my own miscellaneous patches that I was planning
on eventually upstreaming, I ended up with a system that I could boot to
shell with a 455k text size:

Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)

virtual kernel memory layout:
    fixmap  : 0xfffe5000 - 0xfffff000   ( 104 kB)
    vmalloc : 0xd05f0000 - 0xfffe3000   ( 761 MB)
    lowmem  : 0xc0000000 - 0xcfdf0000   ( 253 MB)
      .init : 0xc1094000 - 0xc10b5000   ( 132 kB)
      .data : 0xc1071fac - 0xc1092760   ( 129 kB)
      .text : 0xc1000000 - 0xc1071fac   ( 455 kB)

That was without networking.  Enabling networking added about 250k, and
at that point I could ssh in and run a webserver, still less than 1M as
far as kernel static size, which of course completely ignores the kernel
dynamic size and userspace.

My goal was to get rid of shell access and dropbear altogether and have
all access be via webserver, which I did by using nostromo, mainly for
convenience, until I could get some 'cgi' added to Alan Cox's µWeb
(about 20k).

Anyway, that work, as I left it a couple years ago, is here, in case
anyone's interested (it's a yocto layer and yocto-based kernel
containing many topic branches, but building it according to the
directions in the README will yield a standard kernel and .config in the
working directory and allow you to ignore all the yocto stuff): 

https://github.com/tzanussi/linux-yocto-micro-4.1  
https://github.com/tzanussi/meta-microlinux/tree/jethro

It's nice to see tinification work being done again - at the time I
stopped working on it it seemed there was no desire from maintainers in
general to merge anything that would create new options designed only
for the purpose of tinification.

In fact, as a kind of backup plan for that, I also played around with
the idea of auto-generating a kernel that would contain only the
functions that were demonstrated to be used by the (single-purpose)
workload.  It was similar to the idea of making every system call
configurable and then including only the ones used by the workload, but
taking it a step further and doing that for every function in the
kernel, not just system calls.

I had a script that would take the output of the function_hist histogram
taken while exhaustively running the workload:

  https://lkml.org/lkml/2015/5/20/994

And with a kernel compiled using -ffunction-sections removing all
functions that were never referenced.  I never got a bootable kernel out
of it, but mainly just because I ran out of time and had to move onto
other things.  I may dust it off and try again, just for fun... ;-)

hth,

Tom

> Tom, sorry, I recall this a bit late, perhaps you might be interested
> in reading discussion from the beginning.
> 
> On Mon, Apr 3, 2017 at 9:14 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
> > <stuartl@longlandclan.id.au> wrote:
> >> On 03/04/17 07:41, Nicolas Pitre wrote:
> >>>> No PTYs seems like a big limitation. This means no sshd?
> >>> Again, my ultimate system target is in the sub-megabyte of RAM.  I
> >>> really doubt you'll be able to fit an SSH server in there even if PTYs
> >>> were supported, unless sshd (or dropbear) can be made really tiny.
> >>> Otherwise you most probably have sufficient resources to run the regular
> >>> TTY code.
> >>
> >> Are we talking small microcontrollers here?  The smallest machine in
> >> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
> >> RAM, and that had a MMU.
> >
> > Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
> > Of course with swap enabled.  And swapping like hell.
> 
> 

[toc] | [prev] | [next] | [standalone]

#1616213 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:

> Yes, in a previous project, I had been working toward getting a < 1M
> system to boot on Galileo hardware (which it did, but using more than
> that - the Galileo2 has 256MB, but it was the target hardware at the
> time, and I was hoping eventually to be able to boot out of the 512k
> on-chip SRAM).
>
> I was focused at that point mainly on the kernel static size, and using
> a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> net-diet patches, and my own miscellaneous patches that I was planning
> on eventually upstreaming, I ended up with a system that I could boot to
> shell with a 455k text size:
>
> Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
>
> virtual kernel memory layout:
>     fixmap  : 0xfffe5000 - 0xfffff000   ( 104 kB)
>     vmalloc : 0xd05f0000 - 0xfffe3000   ( 761 MB)
>     lowmem  : 0xc0000000 - 0xcfdf0000   ( 253 MB)
>       .init : 0xc1094000 - 0xc10b5000   ( 132 kB)
>       .data : 0xc1071fac - 0xc1092760   ( 129 kB)
>       .text : 0xc1000000 - 0xc1071fac   ( 455 kB)
>
> That was without networking.  Enabling networking added about 250k, and
> at that point I could ssh in and run a webserver, still less than 1M as
> far as kernel static size, which of course completely ignores the kernel
> dynamic size and userspace.

Thanks for sharing your experience. The question closer to this
discussion what did you do against TTY/UART/(related) layer(s)?

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web