Message-ID: <a728f9f91002041030o7c8d38edxe573bc0a1327d79@mail.gmail.com>
Date:	Thu, 4 Feb 2010 13:30:37 -0500
From:	Alex Deucher <alexdeucher@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Dave Airlie <airlied@...ux.ie>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.sf.net
Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch 
	out of staging."

On Thu, Feb 4, 2010 at 1:12 PM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Matthew Garrett <mjg59@...f.ucam.org> wrote:
>
>> On Thu, Feb 04, 2010 at 06:54:45PM +0100, Ingo Molnar wrote:
>>
>> > But you could claim that it's not a regression because 1) technically the
>> > code got introduced in drivers/staging/, and staging drivers are not on
>> > the regression list 2) the Kconfig value is default-off so it can only
>> > harm those who got lured by a new Kconfig value popping up in -rc7 in a
>> > well working driver they already have enabled.
>> >
>> > So the moving of driver functionality from drivers/staging/ to drivers/
>> > is a grey area it appears. Wouldnt it have been better to do this in the
>> > next merge window, as all other drivers do? It's not new hardware
>> > enablement either, it's feature enablement for an existing driver.
>>
>> The reason the option was in staging (as has been mentioned before) was
>> because the ABI wasn't felt to be stable enough. Upstream is now willing to
>> commit to that stability, so now seems as good a time to move it as any.
>> There's no code change and there's no default configuration change, so I
>> really can't see any way that it can be classed as a regression.
>
> But that argument in essence renders the regression policy meaningless for
> such code: just about any new driver feature under the sun could be shaped as
> a Kconfig option, introduced via a drivers/staging Kconfig entry, and then
> activated via a twoliner commit in a later -rc.
>
> IMHO the point of tracking regressions is to reduce the bugginess of the
> kernel and thus to help users, not to give ground for legalistic arguments.
>
> There _are_ common-sense exceptions from the regression rules, such as the
> introduction of a new piece of hardware that was previously unsupported
> (hence there's no expectation of stability) - but the tweaking of an
> existing, widely used driver (even if the new opion is default-off) hardly
> seems to qualify for that.
>

This is a completely new driver.  It's only part of the existing drm
for compatibility reasons.  It requires an entirely different graphics
stack above it and works very differently from the old drm stack.

Alex

> I dont mind making useful exceptions from rules, as long as we are honest
> about having done it.
>
> Anyway, i've bisected it back to that Kconfig change and i am able to work
> the crashes around by reverting that, so my immediate problems are solved.
>
> Thanks,
>
>        Ingo
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
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/

Powered by blists - more mailing lists