From: Jon S. <jon...@ya...> - 2004-09-02 17:12:06
|
--- Ian Romanick <id...@us...> 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 jon...@ya... __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail |