Re: New proposed DRM interface design

Dave Airlie
2004-09-04T04:58:58Z

>
> If you're Nvidia you ship the library source (since it is GPL) and a

is it GPL though.. we are X licensed at the moment and all my changes are
under the original license...

> binary driver. You compile the library on your kernel so that kernel
> API IFDEF's get executed and then link to the binary driver. This model
> won't work with IFDEF'd inline functions that are used in a binary
> driver. They will have to be real functions in the library.

there shouldn't be many ifdefs left, AGP and MTRR, if you re building a
binary driver for x86 you can assume the platform has AGP and MTRR and the
kernel should sort it all out, the remaining macros are mainly for
building on Alpha and Sparc...

>
> How big is the library that is going to get duplicated? Note that it
> only gets duplicated for different cards not multiple instances of the
> same card family.

it'll be big but that's the same as we have now as I said, I believe the
balance between having a common library with an extensive new binary
interface, vs the un-common use case of using two different graphics card
in one PC is worth having the library in eeach driver, the binary
interface needs to be avoided at all costs, and I believe Keith's opinion
is worth listening to on binary interfaces :-)

> Are you going to hide the exported symbols so that we don't need the
> DRM() macros?
>

Again that is a bit of a separate project, my thinking on all these
projects is that I can feed them into the kernel is small obvious changes
this change will probably just fall out at the end as obvious it isn't so
for me yet...

I'm willing to spend the time doing an initial implementation (as we all
know, code talks, I'm not sure what talking does :-)

Dave.

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