linux-kernel - Re: [git pull] drm request 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100304105624.70fe845e@jbarnes-piketon>
Date:	Thu, 4 Mar 2010 10:56:24 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

On Thu, 4 Mar 2010 10:51:20 -0800 (PST)
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> 
> 
> On Thu, 4 Mar 2010, Jesse Barnes wrote:
> 
> > On Thu, 4 Mar 2010 10:36:55 -0800
> > Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> > > Yes Dave probably should have mentioned it in his pull request, but
> > > that doesn't seem to be a good reason not to pull imo...
> > 
> > And now I see Dave did mention this, so what gives.  Guidance please.
> 
> Yeah, it's in the first one. My bad. I didn't notice, because that one got 
> cancelled for other reasons and never even tested.
> 
> That doesn't change the simple basic issue: how are people with Fedora-12 
> going to test any kernel out now? And are there libdrm versions that can 
> handle _both_ cases, so that people can bisect things? IOW, even if you 
> have a new libdrm, will it then work with the _old_ kernel too?
> 
> Backwards compatibility is really important.

Sure it is.  But OTOH this is very clearly a "use at your own risk"
driver.  Dave and the nouveau guys include the driver in Fedora to get
much needed test coverage, and make sure the latest bits in rawhide
work together.

The "use at your own risk" part is that you get to keep both pieces if
you try to mix and match kernels and userspace until the STAGING
moniker is removed.

If marking the driver as staging doesn't allow them to break ABI when
they need to, then it seems like they'll have no choice but to either
remove the driver from upstream and only submit it when the ABI is
stable, or fork the driver and submit a new one only when the ABI is
stable.  Neither seem particularly attractive.

Of course I'm implicitly trusting their motivation for breaking ABI in
this case, but that was very much a part of the merge discussion so
shouldn't come as a surprise to anyone.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/