diff for duplicates of <1491313228.3704.42.camel@linux.intel.com> diff --git a/a/1.txt b/N1/1.txt index 2d09027..e875d6b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,5 +1,5 @@ > But no job control. No line editing with echo when the shell is -> busy, +> busy,? > etc. This is a debug interface. If RAM is that precious do the line editing @@ -7,20 +7,20 @@ 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 +> 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 +> ?the same low-level UART interface as? > drivers/tty/serial/serial_core.c is using to interact with UART -> drivers. +> drivers.? > If someone wants to make a change to that interface, the 30 or so -> UART +> 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 +> a? +> big deal to change the minitty code to follow suit. And I won't hide? > under a rock while this happens. Fair enough. @@ -35,13 +35,13 @@ 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, +> 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 +> Linux? > code base is used rather than any random RTOS out there with only -> one +> one? > hundredth of the actual Linux following? If so please indulge me a > bit. diff --git a/a/content_digest b/N1/content_digest index 00b5eb0..bd63d45 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,23 +5,14 @@ "ref\0alpine.LFD.2.20.1704031121520.1847@knanqh.ubzr\0" "ref\01491242719.3704.33.camel@linux.intel.com\0" "ref\0alpine.LFD.2.20.1704031433480.1847@knanqh.ubzr\0" - "From\0Alan Cox <alan@linux.intel.com>\0" - "Subject\0Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems\0" + "From\0alan@linux.intel.com (Alan Cox)\0" + "Subject\0[PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems\0" "Date\0Tue, 04 Apr 2017 14:40:28 +0100\0" - "To\0Nicolas Pitre <nicolas.pitre@linaro.org>\0" - "Cc\0Andy Shevchenko <andy.shevchenko@gmail.com>" - Rob Herring <robh@kernel.org> - Peter Hurley <peter@hurleysoftware.com> - Ard Biesheuvel <ard.biesheuvel@linaro.org> - Greg Kroah-Hartman <gregkh@linuxfoundation.org> - Jiri Slaby <jslaby@suse.com> - linux-serial@vger.kernel.org <linux-serial@vger.kernel.org> - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> - " linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "> But no job control. No line editing with echo when the shell is\n" - "> busy,\302\240\n" + "> busy,?\n" "> etc.\n" "\n" "This is a debug interface. If RAM is that precious do the line editing\n" @@ -29,20 +20,20 @@ "terminal apps support line by line modes.\n" "\n" "> we're down to 5.6K. At which point there's only a raw device\n" - "> interface\302\240\n" + "> interface?\n" "> to serial hardware.\n" "\n" "Which if you did a simple plain chardev without trying to fake the\n" "rather out of date uart layer would come down way further still.\n" "\n" - "> \302\240the same low-level UART interface as\302\240\n" + "> ?the same low-level UART interface as?\n" "> drivers/tty/serial/serial_core.c is using to interact with UART\n" - "> drivers.\302\240\n" + "> drivers.?\n" "> If someone wants to make a change to that interface, the 30 or so\n" - "> UART\302\240\n" + "> UART?\n" "> drivers will have to be changed as well. I don't think that would be\n" - "> a\302\240\n" - "> big deal to change the minitty code to follow suit. And I won't hide\302\240\n" + "> a?\n" + "> big deal to change the minitty code to follow suit. And I won't hide?\n" "> under a rock while this happens.\n" "\n" "Fair enough.\n" @@ -57,13 +48,13 @@ "with a simple kfifo queue.\n" "\n" "> vices, though, have 256K of on-chip RAM. Those devices will\n" - "> make\302\240\n" - "> it into your surrounding. Having so much more RAM (no pun intended)\302\240\n" - "> they'll be capable of even more damage. Would you be more confident,\302\240\n" + "> make?\n" + "> it into your surrounding. Having so much more RAM (no pun intended)?\n" + "> they'll be capable of even more damage. Would you be more confident,?\n" "> when a security issue arises (because it will), to know that some\n" - "> Linux\302\240\n" + "> Linux?\n" "> code base is used rather than any random RTOS out there with only\n" - "> one\302\240\n" + "> one?\n" "> hundredth of the actual Linux following? If so please indulge me a\n" "> bit.\n" "\n" @@ -77,4 +68,4 @@ "\n" Alan -f7e12b2f70b7e44ad58ce1a0c75bd822b9092744f701208b324953489bca0309 +efa5dd402865b98bc00ab87d0d77a72e40b1da6c8661a53e1a221b1165bfa958
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.