On Tue, 4 Apr 2017, Tom Zanussi wrote:
> On Tue, 2017-04-04 at 21:04 +0300, Andy Shevchenko wrote:
> > I believe you did some research during time of that project…
> >
>
> Yes, as a matter of fact I did, and just found some notes I took at the
> time. I didn't dive into the code in detail - tha
On Tue, 2017-04-04 at 21:04 +0300, Andy Shevchenko wrote:
> On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi
> wrote:
> > On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
> >> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi
> >> wrote:
> >> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko w
On Tue, 4 Apr 2017, Alan Cox wrote:
> > 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.
Oh absolutely. I d
On Tue, 4 Apr 2017, Tom Zanussi wrote:
> Yes, in a previous project, I had been working toward getting a < 1M
> system to boot on Galileo hardware (which it did, but using more than
> that - the Galileo2 has 256MB, but it was the target hardware at the
> time, and I was hoping eventually to be abl
On Tue, 4 Apr 2017, Andy Shevchenko wrote:
> On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi
> wrote:
> > On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
> >> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi
> >> wrote:
> >> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
>
> >>
On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi wrote:
> On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
>> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi
>> wrote:
>> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
>> > I was focused at that point mainly on the kernel static siz
On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi
> wrote:
> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
>
> > Yes, in a previous project, I had been working toward getting a < 1M
> > system to boot on Galileo hardware (which
On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi wrote:
> On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
> Yes, in a previous project, I had been working toward getting a < 1M
> system to boot on Galileo hardware (which it did, but using more than
> that - the Galileo2 has 256MB, but it was
Hi,
On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
> +Cc: Tom
>
> Summon Tom to the discussion. He tried once hard to shrink a Linux
> kernel to something working in 1M+ RAM on x86.
>
Yes, in a previous project, I had been working toward getting a < 1M
system to boot on Galileo hardw
> 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 poi
On 03/04/17 11:01, Nicolas Pitre wrote:
> On Mon, 3 Apr 2017, Stuart Longland wrote:
>> On 03/04/17 07:41, Nicolas Pitre 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 fi
+Cc: Tom
Summon Tom to the discussion. He tried once hard to shrink a Linux
kernel to something working in 1M+ RAM on x86.
Tom, sorry, I recall this a bit late, perhaps you might be interested
in reading discussion from the beginning.
On Mon, Apr 3, 2017 at 9:14 PM, Geert Uytterhoeven wrote:
>
On Mon, Apr 03, 2017 at 04:09:38PM -0400, Nicolas Pitre wrote:
> On Mon, 3 Apr 2017, Adam Borowski wrote:
>
> > On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote:
> > > Except for that (and possibly VT) it is unlikely that people really
> > > rely on the obsolete terminal features from th
On Mon, 3 Apr 2017, Adam Borowski wrote:
> On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote:
> > Except for that (and possibly VT) it is unlikely that people really
> > rely on the obsolete terminal features from the 70ies. So it's a kind
> > of cleanup.
>
> But... but... but what shall
On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote:
> Except for that (and possibly VT) it is unlikely that people really
> rely on the obsolete terminal features from the 70ies. So it's a kind
> of cleanup.
But... but... but what shall we do without OLCUC?!?
I guess sending these feature
On Mon, 3 Apr 2017, Alan Cox wrote:
> > evertheless very convenient to be able to use a standard
> > shell
> > with it.
>
> A standard shell will work over things other than a tty device. It
> really doesn't care so long as it gets a stream of data punctuated by
> end of statement symbols. It'll
On Mon, Apr 3, 2017 at 8:57 PM, Rob Herring wrote:
> On Mon, Apr 3, 2017 at 1:14 PM, Geert Uytterhoeven
> wrote:
>> On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
>> wrote:
>>> On 03/04/17 07:41, Nicolas Pitre wrote:
> No PTYs seems like a big limitation. This means no sshd?
Again, m
On Mon, Apr 3, 2017 at 1:14 PM, Geert Uytterhoeven wrote:
> On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
> wrote:
>> On 03/04/17 07:41, Nicolas Pitre 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
>>>
On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
wrote:
> On 03/04/17 07:41, Nicolas Pitre 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
> evertheless very convenient to be able to use a standard
> shell
> with it.
A standard shell will work over things other than a tty device. It
really doesn't care so long as it gets a stream of data punctuated by
end of statement symbols. It'll work over pipes, sockets, from files.
> I beg to
On Mon, 3 Apr 2017, Andi Kleen wrote:
> I like the idea of mintty (if it supported ptys).
In fact PTYs could probably be implemented like another UART driver for
the master side.
But that may come later.
> Except for that (and possibly VT) it is unlikely that people really
> rely on the obsole
On Mon, 3 Apr 2017, Andy Shevchenko wrote:
> On Mon, Apr 3, 2017 at 12:41 AM, Nicolas Pitre
> 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
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, re
> 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.
It should be actually most (all?) real serial ones.
> From my point of view is bette
On Sun, 2017-04-02 at 11:55 -0400, Nicolas Pitre wrote:
> On Sun, 2 Apr 2017, Andy Shevchenko wrote:
>
> >
> > +Cc people, who have a key roles in all TTY stuff (btw, why you did
> > miss them?
>
> I used what MAINTAINERS and get_maintainer.pl gave me.
>
I didn't see this until now as I'm mid
On Mon, Apr 3, 2017 at 12:41 AM, Nicolas Pitre 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
>
On Sat, Apr 01, 2017 at 06:21:14PM -0400, Nicolas Pitre wrote:
> Many embedded systems don't need the full TTY layer support. Most of the
> time, the TTY layer is only a conduit for outputting debugging messages
> over a serial port. The TTY layer also implements many features that are
> very unlik
On Mon, 3 Apr 2017, Stuart Longland wrote:
> On 03/04/17 07:41, Nicolas Pitre 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
> >
On 03/04/17 07:41, Nicolas Pitre 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
On Sun, 2 Apr 2017, Andi Kleen wrote:
> Nicolas Pitre writes:
> >
> > Of course, making it "mini" means there are limitations to what it does:
> >
> > - This supports serial ports only. No VT's, no PTY's.
>
> No PTYs seems like a big limitation. This means no sshd?
Again, my ultimate system tar
Nicolas Pitre writes:
>
> Of course, making it "mini" means there are limitations to what it does:
>
> - This supports serial ports only. No VT's, no PTY's.
No PTYs seems like a big limitation. This means no sshd?
> But again, most small embedded systems simply don't need those things.
They don
On Sun, 2 Apr 2017, Andy Shevchenko wrote:
> +Cc people, who have a key roles in all TTY stuff (btw, why you did
> miss them?
I used what MAINTAINERS and get_maintainer.pl gave me.
> why you didn't include people who reacted on your v1
> either?).
> I'm pretty sure they are interested in what's
+Cc people, who have a key roles in all TTY stuff (btw, why you did
miss them? why you didn't include people who reacted on your v1
either?).
I'm pretty sure they are interested in what's going on here.
On Sun, Apr 2, 2017 at 1:21 AM, Nicolas Pitre wrote:
> Many embedded systems don't need the fu
Many embedded systems don't need the full TTY layer support. Most of the
time, the TTY layer is only a conduit for outputting debugging messages
over a serial port. The TTY layer also implements many features that are
very unlikely to ever be used in such a setup. There is great potential
for both
34 matches
Mail list logo