On Wed, Sep 01, 2004 at 01:42:17PM -0700, Ian Romanick wrote:
> Sam Ravnborg wrote:
> >On Wed, Sep 01, 2004 at 09:33:05AM -0700, Ian Romanick wrote:
> >>Jon Smirl wrote:
> >>
> >>>Why don't we just address the real problem and split DRM into
> >>>core/personalities. Doing this would eliminate the whole intermodule
> >>>mess. Intermodule support could even be removed from the kernel since
> >>>DRM is the only user. With all of the macro elimination and current
> >>>code rework in DRM I don't this splitting a core off is that hard to
> >>>do.
> >>
> >>Okay, this is getting frustrating. I have posted *numerous times* a
> >>very detailed description of a show-stopper problem with the separate
> >>library idea. Until somebody can post a solution to that problem,
> >>PLEASE STOP SUGGESTING IT.
> >
> >I'm just so stupid I cannot see why DRM is special compared to sata :-(
>
> 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.
When compiling the kernel with drm drivers built-in they all use the
same libdrm.o - which they must be compatible with.
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.
Sam
-------------------------------------------------------
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
