Re: [git pull] drm request 3

[Maarten Maathuis <madman2003@gmail.com>]

On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> Hmm. What the hell am I supposed to do about
>
>        (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
>        (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
>        (EE) NOUVEAU(0): 879:
>
> now?
>
> What happened to the whole backwards compatibility thing? I wasn't even
> warned that this breaks existing user space. That makes it impossible to
> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid
> model, lots of people are just using some random distribution (F12 in my
> case), and you just broke it.
>
> I see the commit that does this was very aware of it:
>
>        commit a1606a9596e54da90ad6209071b357a4c1b0fa82
>        Author: Ben Skeggs <bskeggs@redhat.com>
>        Date:   Fri Feb 12 10:27:35 2010 +1000
>
>            drm/nouveau: new gem pushbuf interface, bump to 0.0.16
>
>            This commit breaks the userspace interface, and requires a new libdrm for
>            nouveau to operate again.
>
>            The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
>            compatibility purposes are now gone, and replaced with the new ioctl which
>            allows for multiple push buffers to be submitted (necessary for hw index
>            buffers in the nv50 3d driver) and relocations to be applied on any buffer.
>
>            A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
>            for userspace modesetting have also been removed.
>
>            Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>            Signed-off-by: Francisco Jerez <currojerez@riseup.net>
>
> but why the hell wasn't I made aware of it before-hand? Quite frankly, I
> probably wouldn't have pulled it.
>
> We can't just go around breaking peoples setups. This driver is, like it
> or not, used by Fedora-12 (and probably other distros). It may say
> "staging", but that doesn't change the fact that it's in production use by
> huge distributions. Flag days aren't acceptable.
>
>                Linus
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

What i'm about to say is my personal opinion, not that of nouveau as a
whole (not even sure if such a thing exists).

1. We are in staging because our abi isn't final yet.
2. We (already) adjusted our way of working to ensure we have a usable
and proper codebase by the time we are ready for mainline.
3. Redhat through Ben Skeggs contributes to nouveau (quite a bit i agree).
4. You are forcing red hat to force something on the rest of us.
5. I for one am happy we keep a clean api.
6. We keep an internal kernel tree that is tested to some degree (in
this case the abi break was in there for a few weeks iirc) none of the
developers asked for a revert.
7. Everyone (users, distros) are (or should) be aware of the nature of
this driver, our userspace interface is experimental for that very
reason.
8. Experience has tought me that in the case of nouveau, if a
developer isn't using a codepath it will bitrot.

So please, also take into consideration that this project isn't solely
made by red hat and it's usually the other people that get to keep the
pieces.

Sincerely,

Maarten Maathuis.