Re: DRM code reorganization

[Dave Airlie]

>
> If this is something that we really want to pursue, someone needs to dig in
> and figure out:
>
> 1. How much / which code can be "trivially" shared?
> 2. How much / which code can be shared with very little work?
> 3. How much / which code would we rather get a root-canal than try to make
> shared?
>
> The concern has been that, by making a "generic" library layer, we'd actually
> make the DRM more difficult to maintain.  Nobody has really had the time to do
> the research required to either substantiate or refute those claims.  Based on
> the little experience I have in the DRM, I tend to believe them.

I'm going to agree with Ian here, making a generic library layer is going
to make maintaining  the DRM a full time job as opposed to the 5-6 hrs a
week I do on it ... also the change to a library needs to be done in
little steps, removing something from one place and adding it to another,
a big code-drop from the DRI CVS is not going to be acceptable to anyone,
however breaking things in the kernel tree is also not going to be...

So if people are proposing a complete DRM re-write, then what I forsee has
to happen is, a new development tree is setup, the code is beaten into shape,
we rename the project something else like ghm (graphics hardware manager -
you heard it here first :-), we import it into the kernel and deprecate
the DRM in-kernel, maybe we can develop it in the kernel tree as
(EXPERIMENTAL), then everyone can give out about it while the work is in
progress as opposed to when we are finished it ...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/