>
> I looked at the code currently in CVS.  Is it the most recent?  I know CVS
> commits to X.org servers are toast right now.

I've another bunch of changes pending on my PC at home, these get rid of
the kernel context switch stuff for the sparc and the context ctor/dtor
macros...

>        if ( dev->fn_tbl.foo )
>        def->fn_tbl.foo();
>
> I'd rather have drivers init all the functions to some generic, noop function.
> I think that makes the code a lot cleaner to read.

I've thought about this and wasn't sure how acceptable adding a load of
NOP function calls would be.. I'm not sure too many of the current ptrs
are in any fast paths, my preference was to use a macro which wrap the
above but that may be the old way of thinking :-),
>
> Also, I think it might be better to embed a pointer to the function table in
> the device's data structure rather than the table itself.  If (when?) we go to
> a setup where we have a generic base structure that each of the drivers embeds
> and expands in it's structure, a pointer should be easier to work with.

At the moment each driver has its own dev_private portion that is adds to
so the central structure shouldn't change that often once the cleanups are
done ...

> You can't mix-and-match compiled kernel modules, so it may not matter.

I really don't want to have to introduce versioning between the drm kernel
module and the card dependant one.. I can see people building their own
card drivers from the DRM CVS and trying to load them vs a kernel with a
built-in DRM core.. my current thinking on this is we use the Kconfig to
try and ban it (I hope it is flexible enough)... so if a kernel has a
built-in drm library CVS won't build against it, and we won't build DRM
modules unless the library is a module ..

Dave.

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



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to