Re: [Linuxconsole-dev] EvStack - 2.3.x?

[James S. <jsi...@ac...>]

> IMO console and vc's are different. So let's agree on consistent terminology
> right away:
> 
>    console = /dev/console    System console device, might be serial terminal
>                              or even a teletype/line printer.
> 
>    virtual tty's = /dev/tty[0-9]+
> 
>                              Virtual tty's with VT102 terminal emulation.
>                              Should be called vt's IMHO and we should use
>                              something like ptmx/pts to create the devices
>                              on demand (what do you think? And PLEASE nobody
>                              mention devfs in my presence!)

Agree. In fact when I think VT I prefere to think of it as Video Terminal
instead of virtual terminal. In theory you could have vitrual terminals
even on serial consoles. 

P.S
  I read your page on devfs.   
 
> What i want to do is to separate the two. Keep the console small and clean.
> If you are running linux on a PC104 embedded system with serial console,
> then there is no need for VC's. Fortunately we can do this already, but the
> code is still mixed right now.

Agree. I like to see that as well. 

> Some thing we might want to look into is a network-base console (using UDP
> unicast/multicast/broadcast or whatever one uses for these things).

Wow. That would be powerful. 

> > Vojtechs work :) Screw the /dev/mouse crap. We have /dev/event. It
> > basically works like /dev/shmiq on IRIX. Its a event queue. A app opens it
> > and reads the event packets that arrive. It works for ANY input device :)
> > Raw access to the input hardware.
> 
> The problem i see here is that this becomes too opaque for the casual user.
> Might be clean and nice from a design standpoint, but will certainly irritate
> some folks.

Well such a system is being used for USB already so I think people are
getting use to it. Especially people with iMacs which have only USB. 

> > We have to deal with SMP multihead systems. You could have different
> > processes running on different CPUs using different heads. As you can see
> > we need locking to ensure data structures are altered by the wrong VT.
> > Next problem I bet you didn't think about. Printk being called inside a
> > bottom handler can also cause nasty race conditions. This was something
> > Mares notices while working with Vojtech. 
> 
> Ouch!  Your pulling my leg, do you?  We don't even have support for partioning
> linux systems and you want to build a console framework for this?  But with
> the /390 port and thingies like E10k around this is something we have to
> think about.  I'll ask a friend of mine about his input: he's the local expert
> for the Convex/HP supercomputers... I think they use a seperate HP workstation
> as console device.

Nope I'm not pulling you leg. 


> It's the same i posted to linux-kernel last week when this discussion
> started.  Unfortunately i have (again!) no network when running >2.3.36
> kernels and my laptop just forgot about some essential keys (i wonder
> what the DELL support will say about this when i call in tomorrow!) so i
> am somewhat hobbled at the moment.

I looked over your patch. It nice to see better VT102 emulation. I thought
you where the one that posted about splitting the terminal emulation from
the console code. You could do things like HP console emulation etc. Thats
a possible idea. 

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U