Re: [Linuxconsole-dev] Welcome!!!

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

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

> > 	I think that we have three major areas of concern which will drive
> > the design of this project:
> > 
> > 1: What do we need?
> > 	* Better multiheading, 
> > 	* Cleaner and more abstract [virtual] console representation,
> > 	* fbcon backwards compatibility,
> > 	* /dev/gfx integration,
> > 	* Abstract input devices and event flow graphing,
> > 	* ...others...
> 
> I think this shoudl go on the web page. 

	There is a lot of stuff that should go on the web page:

* Links to prevous console work:
	* Voitchek(sp?)'s unified input device work
	* fbcon/fbdev stuff
	* EvStack/GGI Console stuff
	* KGI console stuff
	* ...other links...

* Analyses of the current console and its problems (FAQs)

* Links to info on how other Un*xen handle their console subsystem designs

> > 2: What does Linus want?
> 
> Something that works. 

	That's not nearly enough info IMHO.  This "just go ahead and write
something and I'll either accept it or not" system causes coders to waste
a lot of time implementing ideas which are later shot down by Linus. And
since the console subsystem is one of the more fundamental and critical
parts of the kernel, I suspect that Linus will in fact have a lot of
requirements that he'll want met, both in terms of design and coding
methodology.  All he needs to do to eliminate the bulk of this uncertainty
is give some simple answers to these questions:

* Must we "morph" fbcon/fbdev into the new console system, one tiny patch
at a time, or can we make larger and more radical changes a la devfs?
The latter would be much easier on the console coders, but might cause
Linus more hassles.  Or it might not, especially if we take care to see
that it doesn't.

* If we must implement the new console by parts, what is the largest
acceptable size of the parts, and in what order should these be worked on?

* To what extent, if any, is it acceptable to integrate the new console
stuff and kernel graphics handling?  Obviously the two topics are closely
related in some ways, so how do we handle this?


> Show me the code is his mato. 

	"If you are the boss, and you want something done, give me at
least a little direction here please so I have a better chance of doing it
right for you" is my motto |->.  I mean, Linus must have _some_ opinions
on this issue, or he would not have rejected the original EvStack concept.  
EvStack/GGI Console is far and away the most complete new console code
around, AFAIK.  If Linus genuinely wants us to just start throwing code at
him to accept or reject, maybe that would be a good place to start...?

> Once coding begins I
> suggest we send him some patches to look at. He will then add his
> comments. Some good, some bad.

	See above.  We already have a LOT of console, abstract messaging
and abstract input device code available.  The best thing Linus can do for
us is to _quickly_ tell us which ideas he will _not_ accept, so we can
avoid dead-ends and wasted coding effort.
  
> > 3: What will Linus accept into 2.5.x?
> > 
> > 	EvStacks was a _really_ good design, but I guss it was too complex
> > and ambitious for Linus.  Therefore, we really need to know where Linus
> > stands on the issues before we do any significant amount of design work
> > this time around.
> 
> One thing I can guarantee is his position on what a console is. I had the
> discussion with him on private mappings and bending the rules for the
> linux-SGI GFX port. We wouldn't go for it. The reason why is the concept.
> To him a thread process is and will always be a lightweight process. As he
> stated it is what it is. If not then rules don't mean much and you might
> as well allow people to break the basic definations that define UNIX for
> their own gain. To him a tty will always be a keyboard and a display.
> Thats it. Breaking what the meaning of a tty is will not go over with
> him.   

	No, and I would not propose such a thing.  Obviously the new
console system must preserve the current abstractions, probably by
encapsulation and extension as devfs does.  If Linus wants to preserve the
concept of a TTY, fine.  All we need to do is define the concept of a
'head', and we can use that as our basic unit of binding context for VTs,
multiheading, etc.

Jon

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