Re: New proposed DRM interface design

[Felix Kühling]

I realized, that from a snapshot point of view, it would be easy to cope
with a separate library module + additional binary interface. As far as
I gathered the main argument against another binary interface is that
upgrading one driver would break the other ones that may still be
installed on the system. It would be no problem to update all of them at
the same time. The snapshots include all the DRM sources anyway, they
just build the DRM for a single type of card right now.

The snapshots have been split into a common and a hardware-specific part
some time ago. Just move the DRM into the common part of the snapshots
and make it build and upgrade all DRM drivers at the same time. This way
a change in the binary interface won't break any other drivers (provided
that DRM CVS is the authoritative source for *all* DRM drivers that rely
on that library module).

Regards,
  Felix

On Sat, 4 Sep 2004 23:17:40 +0100 (IST)
Dave Airlie <airlied@xxxxxxxx> wrote:

> 
> Actually after sleeping on this, I've just realised technically whether
> the code is in a core separate module or driver module is only going to
> affect maybe 5% of the work and the Makefiles/Kconfig at the end, so
> following the principles of a)least surprise, b) kernel must remain
> stable, I think I can proceed with moving stuff into libraries and the
> likes without making the final decision until later, we will probably
> start with having the library type code in the driver (where it is now)
> and make it possible to change later, as it evolves..
> 
> I'll do some more research...
> 
> Dave.
> 

| Felix Kühling <fxkuehl@xxxxxx>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |
-
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/