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

[Alan Cox]

> 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