Re: New proposed DRM interface design

[Dave Airlie]

>
> Then drm_core would always be bundled with the OS.
>
> Is there any real advantage to spliting core/library and creating three
> interface compatibily problems?

Yes we only have one binary interface, between the core and module, this
interface is minimal, so AGP won't go in it... *ALL* the core does is deal
with the addition/removal of modules, the idea being that the interface is
very minor and new features won't change it...

The library/driver interface then becomes a source interface as the
library isn't a separate module, it is linked into the modules, so we have
no binary interface issues with it, so the library/driver interface is
what we have at the moment minus the uglyness of DRM() and templated
header files... so if a vendor wants to ship a binary DRM, they only worry
about the drm core interface, and we avoid moving that interface as all it
does is keep track of all installed drms and the major device number..

> What about the VM page fault routines with 2.4 vs 2.6 differences?
> How about HAS_WORKQUEUE?

These are things to worry about later, as I said the code was just
experimental hackery to get my head around the issues. I'm not proposing
it for inclusion at any point, it also doesn't follow the design I
proposed, it makes the library as a separate module at the moment, and
uses an EXPORT_SYMBOL table, which isn't what I want to do...

Dave.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/