Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754009AbdDDNkj (ORCPT ); Tue, 4 Apr 2017 09:40:39 -0400 Received: from mga05.intel.com ([192.55.52.43]:21279 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752584AbdDDNkh (ORCPT ); Tue, 4 Apr 2017 09:40:37 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,275,1486454400"; d="scan'208";a="73421225" Message-ID: <1491313228.3704.42.camel@linux.intel.com> Subject: Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems From: Alan Cox To: Nicolas Pitre 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 Date: Tue, 04 Apr 2017 14:40:28 +0100 In-Reply-To: References: <20170401222119.25106-1-nicolas.pitre@linaro.org> <1491224186.3704.11.camel@linux.intel.com> <1491242719.3704.33.camel@linux.intel.com> Organization: Intel Corporation Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1937 Lines: 56 > 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