On Wed, Sep 01, 2004 at 01:42:17PM -0700, Ian Romanick wrote:
Beyond the difference in the complexity of the devices, there isn't much *technical* difference. There are, however, significant "practical" differences. People are quite accustomed to updating their graphics drivers on a regular basis, independent of their kernel / OS. We already have a number of parts that need to be kept in sync. There's already the DDX, DRI, and DRM parts. Adding yet another part can only add more user headaches.
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.
Given the layered kernel module problems that we already have with agpgart and company, I don't want the user-support headaches that another such interface would bring. Almost every week someone on the 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!
Since people pretty much only change their SATA driver when they change their kernel, none of these problems exist WRT that driver or other layered drivers.
The way libata works is that it define a library - not a layered module.
So for drm we would have libdrm.o Then each and every module would link in and use their specific version of libdrm.o.
So, you have x_ata.ko and y_ata.ko that are both linked with libata. What happens when when the user loads both modules at once? How do you avoid symbol conflicts from the libata linked to both drivers? This is basically what the DRM does, but we have the evil macros (no, I don't like them either) to prevent the symbol conflicts.
When compiling the kernel with drm drivers built-in they all use the same libdrm.o - which they must be compatible with.
Right. I'm not so worried about that case. If the user has built the driver into the kernel, it should be safe to assume he/she isn't planning to upgrade it anytime soon. :)
See - no issues with users having to load two modules, and no issues with an incompatible libdrm.o.
Jeff - please confirm that this is the way libata works.
------------------------------------------------------- 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
