--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Here's the problem that I want to avoid. Imagine a case where a user
> has 2 graphics cards. Say, an integrated i915 and a PCI R200. The
> installed versions both use drm_core version N. Now the user wants
> to upgrade the R200 driver, but the new R200 DRM requires drm_core
> version N+1. Suddenly the user is forced to upgrade both drivers or
> neither driver.
My take on this is that drm_core should be closely tied to the OS
version and not be distributed separately. Much of the volatility in
core functions is caused by tracking changing kernel APIs. I also think
that the library functions supplied by core will be fairly static. We
already have a bunch of 3D driver implementations so it is pretty
obvious what needs to go into the library. One the other hand, the
personality modules are much more volatile and are updated more often.
Some possible solutions...
1) personality modules can read the core API version and adjust. If
they can't adjust they fail to load. We can allow for adjusting
personality modules by exporting a function table from the library
instead of symbols. This allow the same personality to work on
different versions of the library.
2) The core gets backported for each API change. This is tricky since
some of the OS features like hotplug can't get backported since the
older OS's don't have them. The backported core could stub these out.
3) an extension query API. drm_core 1.0 has a fixed set of entry
points. any new extensions are queried like OpenGL does. After a while
(couple of years) we create drm_core 2.0 and bless the extensions that
have proven good. If there is enough interest, drm_core 2.0 will get
backported to older OS versions.
drm_core might actually reduce the volatility in DRM drivers by
isolating them from kernel API changes.
The current scheme is also complex. We have some global variables that
have to be tracked across all DRM instances. Examples, free minor node
numbers, /proc root, sysfs class, max device limit, etc. There is
complicated code tracking these using inter_module register. This code
has to deal with drivers being removed in a different order than they
were loaded - the module that created something is not necessarily the
module that has to clean it up. We also have ifdef/inlines all over the
code hiding difference in kernel API's.
> team has to spend time telling a user that they need to load both
> agpgart and intel_agp. If people have trouble figuring that out,
> there's pretty much no hope they could deal with radeon.ko and
> drm_core.ko!
Should we rename agpgart to agp_library? Loading intel_agp
automatically loads agpgart. When we get to a fully hotplug kernel you
shouldn't even need to load intel_agp. The kernel will see the PCI ID
for it and load intel_agp automatically which will also bring in agpgart.
=====
Jon Smirl
[EMAIL PROTECTED]
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
