Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754019AbdDCQHV (ORCPT ); Mon, 3 Apr 2017 12:07:21 -0400 Received: from mail-qk0-f173.google.com ([209.85.220.173]:35300 "EHLO mail-qk0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753913AbdDCQHS (ORCPT ); Mon, 3 Apr 2017 12:07:18 -0400 Date: Mon, 3 Apr 2017 12:06:55 -0400 (EDT) From: Nicolas Pitre To: Alan Cox cc: Andy Shevchenko , Rob Herring , Peter Hurley , Ard Biesheuvel , Greg Kroah-Hartman , Jiri Slaby , "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-arm Mailing List Subject: Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems In-Reply-To: <1491224186.3704.11.camel@linux.intel.com> Message-ID: References: <20170401222119.25106-1-nicolas.pitre@linaro.org> <1491224186.3704.11.camel@linux.intel.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1807 Lines: 41 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