Re: [Linuxconsole-dev] Welcome!!!

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

> > 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

Very nice? 

> 	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:

Your right. I will talk to linus about this.

> * 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.

Morph a small piece at a time. Try not to break any drivers. This is what
I'm doing for fbdev. Its slow and painful but it works. 

> * 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?

I think some code clean up for the console system. A good example is the
vt_struct, struct vc_data and then struct vc. This really needs to be
cleaned up. If this can be done without breaking the current console
drivers this would be a plus. Merge these into one universal data struct. 

Keep up the input suite started by Vojtech. Do what I have been doing with
fbdev. Move the console dependent code up out of the input devices into
the console system.

> * 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?

Well the important thing is to ensure the graphics engine is executed only
by a process on the local console. This is required for /dev/graphics on
SGI workstations. 

> 	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.

I will talk to 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.

Okay.

"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