RE: [Linuxconsole-dev] Welcome!!!

[Jon M. T. <ta...@ec...>]

On Thu, 2 Mar 2000, James A Simmons wrote:

> > 	Careful, a "head" is really just the set of all input and output
> > devices, and their associated event handling 'map', which are being used
> > by one person.  A binding, basically.  A "console" in the traditional UNIX
> > sense is a keyboard and a TTY.  A head could consist of a VT102 terminal,
> > or a standard PC keyboard + mouse + monitor + joystick, or even extreme
> > cases like two monitors, a braille touchpad on a serial port, a USB
> > joystick and keyboard, and no /dev/tty at all.  Heads and consoles are
> > often the same thing, but sometimes they will be quite different.
> 
> Very true. Consider a workstation with several sound cards. Each employee
> wants to listen to his own stuff. You have to make sure it goes to the
> right person. This has to be done. 

	Right, and this is easy if you decide not to treat any particular
I/O hardware or abstraction any differently from any other.  You have
event and data sources from input devices (keyboard, mouse, joystick,
remote network event sources, dummy devices, etc) and output devices
(framebuffer, TTY console, /dev/dsp, remote network event sinks, etc).
Event "packets" are generated by event sources, flow to event sinks
according to simple rulesets, and are handled by the event sinks.  As with
TCP networking, the kernel is basically a traffic cop.

	If you do this, suddenly the kernel does not have to deal with a
lot of issues that it does now.  The kernel does not need to care about
anything but the proper routing of abstract events according to internal
tables, just as it now does not have to care about what is inside the TCP
packets (well sort of, you know what I mean).  It just handles them
properly and lets the userspace applications figure out what they _mean_.  
Likewise, if you define a "head" as a binding of input devices and output
devices with some rules about where the events are routed, the kernel does
not have to care about the nature of the individual devices which are
bound into the head.  Whether the head is a VT102 terminal on a serial
port or a very complex multihead+remote setup as has been described before
does not matter _at all_ to the kernel.
 
> > 	Yes, this could be an issue.  Right now I advocate head == VT, but
> > for multi-monitor and such things this could get real ugly real fast |->.
> > Watch the kernel remap a dozen different widely varying types of input and
> > output devices back and forth every time you switch VCs!  Drown in races!
> > Throw spinlocks all over the place!  Get into remote event handling and
> > watch your network latency become your user interface latency!  Etc etc
> > etc.  Of course we will probably want to be able to do most or all of this
> > type of stuff, but Linus may balk at adding such complexity to the kernel,
> > at least all in one go |->.  IMHO, this is an issue for Linus to decide.
> 
> KISS. See my other post about what a tty is to linus.

	Well, if Linus were to allow an abstracted system like the one
outlined above, it would certainly be _different_ from what we have now.
But would it be more complex?  I say no!  I think it would be quite a bit
simpler conceptually, actually.  But we'll see what Linus is willing to
accept, I guess.
 
> > > How does this fit in with DRI (I'm unable to find decent documentation)?
> > > Are gfx and DRI trying to do the same thing?
> > 
> > 	More or less.  It would be very cool if we could design this new
> > console system such that it could easily support and plug into /dev/gfx,
> > DRI, KGI, fbdev, or any other potential kernel graphics (and input device)
> > driver framework(s). 
> 
> Removing the consoel system from hardware drivers is the way to go IMHO.

	Yes.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed