Re: sysdev_class use from DRM

[Jon Smirl <jonsmirl@gmail.com>]

On 7/1/05, Greg KH <greg@kroah.com> wrote:
> Last kernel summit I thought this was all hashed out.  I guess the
> people not there didn't agree...

There are more layers to the problem. 

For example there is a bunch of redundant code between radeonDRM and
radeonfb. To make the embedded people happy things are set up so that
radeonfb can be run standalone and a merged radeonDRM can optionally
be loaded. Since radeonfb is always there you put all of the redundant
code into radeonfb, right?

But radeonDRM has shared source with BSD. The BSD people started
howling when I tried to remove the redundant code since they don't
have an radeonfb equivalent to put it into.

Then there is the pure architecture group. This group wants to define
a small layer that works as a multiplexer and let you plug fbdev and
DRM into it. This is a great idea if you have someone lined up to
modify 67 fbdev drivers on ten different platforms/archs.

Next is defense of backwards compatibility. Right now the rules of VT
swap are that after swap another driver can reset the card and wipe
it's memory, then when you VT swap back to the first driver it has to
gracefully recover all of it's state. This was fine where there were
14 VGA registers but now we have 500 registers and 256MB of video
memory. Trying to tamper with the rules of VT swap sets off major
screams from groups like DirectFB.

At a higher level the problem is tied into the Xserver. The server
community is split right now between the EXA group and Xgl. EXA
extends the current XAA model of doing almost every in user space and
having platform independent drivers. Xgl take the philosophy that the
OpenGL stack is the device driver and it can be as platform dependent
as it wants. Then the Xgl server which sits on top is platform
independent. This is really hurting because it is splitting our very
small number of driver developers.

There is still no agreement on the very basic concept of a single
driver being in charge of the hardware and other are subordinate to
it. I've also left out another dozen side arguments, like should mode
setting be in-kernel or out?

Another unsettled area is consoles and the kernel. If I put two
graphics cards in a system should I get two consoles with VT's? Right
now the kernel supports a single console, there is a 100K line patch
to make it support more than one. I think it is crazy to further the
current VT mess and I want to push console support into user space.
(there would still be an in-kernel emergency console with no VTs).

> Hey, how about at KS/OLS we (anyone who cares about this) sit down and
> hash it all out and produce code that does this?  With a working patch,
> it should be simple to get it into the tree and then everyone can move
> on.

I am still uncommitted to coming. We have a new set of eight month old
twins and I can't get permission to leave. The compromise may be to
bring the wife, twins and nanny.

This is not an easy area to get consensus on. You can get agreements
from small groups but when it expands the agreements fall apart. It
may require that someone like Linus bless a roadmap for video
development and then reject anything that is not on the roadmap. With
road we are on right now we are going to end up with ten different
half finished systems.

> I don't want to see any silly workarounds like what you are being forced
> to do to happen.
> 
> thanks,
> 
> greg k-h
> 


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel