lkml.org 
[lkml]   [2017]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
On Mon, 3 Apr 2017, Andy Shevchenko wrote:

> On Mon, Apr 3, 2017 at 12:41 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Sun, 2 Apr 2017, Andi Kleen 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.
>
> Are you sure you need Linux there? There is a nice Zephyr project
> (OpenSource RTOS, POSIX compatible) exactly for microcontrollers.

I know that Zephyr is LF endorsed, aim to slow fragmentation in that
space, etc. But it is in itself yet another RTOS. It doesn't look like
it is really POSIX compatible yet, and is certainly not Linux
compatible.

I don't pretend that Linux should always be preferred to Zephyr. For
example, I don't think Linux could ever be used with 32KB of RAM while
Zephyr easily can. However, in the hundreds of KB of RAM, given the
choice between Linux and anything else, I can tell you that many people
would go with Linux.

The goal is really to be able to leverage the existing Linux knowledge
and ecosystem. Be able to develop your application on your PC
workstation, singlestep it, strace it, validate the tiny version of
those kernel subsystems there too with existing fuzers, etc. If a
security issue turns up in your product, you have plenty of people who
are already familiar with the Linux environment, much more than Zephyr
or any other RTOSes.

> While I can agree on making Linux stuff less fatty, I can't agree on
> doing this way. We have for now two subsystems to serve for serial
> devices, you are proposing third one for only narrow class of devices.
> From my point of view is better to achive your goal with existing
> system (as a proof of concept maybe even with ugly #ifdef:fery).

Been there already. It doesn't work. The #ifdef:fery in the existing
code simply doesn't cut it. Because of its flexibility, the existing
code constitutes a stack of many layers each with its own interface and
buffering. It uses much more runtime memory simply because it can afford
it on all existing systems supported by Linux. It can drive a large bank
of modems without a single hiccup if you're still into running a BBS.
That's why the existing code is how it is.

I don't want a proof of concept. I want something that is maintainable.
Adding #ifdef's to the existing code will make the end result way less
maintainable, either for the standard or the mini use case. By being
really small, the maintenance cost of a parallel implementation isn't
very high, certainly much less than trying to maintain a single version
that can scale to both extremes.


Nicolas

\
 
 \ /
  Last update: 2017-04-03 18:40    [W:0.184 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site