From: Ingo Molnar <mingo@elte.hu>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dave Airlie <airlied@gmail.com>, Dave Airlie <airlied@linux.ie>,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
dri-devel@lists.sf.net
Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."
Date: Thu, 4 Feb 2010 19:56:03 +0100 [thread overview]
Message-ID: <20100204185603.GA6665@elte.hu> (raw)
In-Reply-To: <20100204181540.GA20922@srcf.ucam.org>
* Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Thu, Feb 04, 2010 at 07:12:18PM +0100, Ingo Molnar wrote:
> >
> > * Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > > 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.
>
> Before this patch, CONFIG_DRM_RADEON_KMS=y would crash your system on boot.
> [...]
Hm, in what way does that observation address the concerns i've outlined?
Before this patch i could enable CONFIG_DRM_RADEON_KMS=y only if i enabled
CONFIG_STAGING, which i dont, because doing so would taint my kernel with
TAINT_CRAP, and the kernel log would contain:
"%s: module is from the staging directory, the quality is unknown, you have been warned.",
> [...] After this patch, CONFIG_DRM_RADEON_KMS=y still crashes your system.
> [...]
After this patch i suddenly get a new body of code with a default-off option
that would only show up before if i had CONFIG_STAGING=y enabled before.
Do you see my argument why any user who is hit by this would categorize this
as a kernel regression in an existing driver?
Moving driver functionality from drivers/staging/ to drivers/ might be
justified, it might be pragmatic, but you dont try to justify it and you dont
try to outline the pragmatic reasons - from all i can see you seem to argue
that this is all perfectly fine in late -rc's, which has me worried somewhat.
[ And if that is really fine i'd like to hear Linus's amen on that as well,
because i'm sure others would like to use that mechanism too to enable
new functionality in late -rc's. ]
Thanks,
Ingo
next prev parent reply other threads:[~2010-02-04 18:57 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-01 2:20 [git pull] drm fixes Dave Airlie
2010-02-01 2:53 ` Dave Airlie
2010-02-02 8:17 ` [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging." Ingo Molnar
2010-02-02 8:25 ` Dave Airlie
2010-02-02 15:44 ` Ingo Molnar
2010-02-04 20:39 ` Dave Airlie
2010-02-04 20:46 ` Ingo Molnar
2010-02-04 21:14 ` Dave Airlie
2010-02-05 0:43 ` Dave Airlie
2010-02-05 7:32 ` Ingo Molnar
2010-02-02 8:35 ` Dave Airlie
2010-02-02 8:37 ` Dave Airlie
2010-02-02 15:42 ` Ingo Molnar
2010-02-02 15:46 ` Ingo Molnar
2010-02-02 20:34 ` Dave Airlie
2010-02-04 6:26 ` Ingo Molnar
2010-02-04 6:39 ` Dave Airlie
2010-02-04 7:36 ` Ingo Molnar
2010-02-04 7:49 ` Dave Airlie
2010-02-04 7:17 ` hung bootup with " Ingo Molnar
2010-02-04 16:48 ` Matthew Garrett
2010-02-04 17:08 ` Ingo Molnar
2010-02-04 17:15 ` Linus Torvalds
2010-02-04 17:36 ` Ingo Molnar
2010-02-04 17:36 ` Matthew Garrett
2010-02-04 17:54 ` Ingo Molnar
2010-02-04 17:59 ` Matthew Garrett
2010-02-04 18:12 ` Ingo Molnar
2010-02-04 18:15 ` Matthew Garrett
2010-02-04 18:56 ` Ingo Molnar [this message]
2010-02-04 19:00 ` Matthew Garrett
2010-02-04 19:19 ` Ingo Molnar
2010-02-04 19:28 ` Jerome Glisse
2010-02-04 20:34 ` Ingo Molnar
2010-02-04 18:30 ` Alex Deucher
2010-02-04 19:06 ` Ingo Molnar
2010-02-04 19:18 ` Alex Deucher
2010-02-04 19:24 ` Linus Torvalds
2010-02-04 19:34 ` Dave Airlie
2010-02-04 20:27 ` Ingo Molnar
2010-02-04 19:32 ` Ingo Molnar
2010-02-04 19:53 ` Jesse Barnes
2010-02-04 20:22 ` Ingo Molnar
2010-02-04 20:27 ` david
2010-02-04 20:33 ` Jesse Barnes
2010-02-04 20:57 ` Ingo Molnar
2010-02-04 20:48 ` Matthew Garrett
2010-02-04 21:05 ` Ingo Molnar
2010-02-04 21:09 ` Matthew Garrett
2010-02-05 7:56 ` Ingo Molnar
2010-02-05 8:34 ` Dave Airlie
2010-02-05 9:00 ` Ingo Molnar
2010-02-05 9:18 ` Dave Airlie
2010-02-05 10:47 ` Ingo Molnar
2010-02-04 21:23 ` Andrew Morton
2010-02-04 21:34 ` Jesse Barnes
2010-02-04 21:35 ` Dave Airlie
2010-02-06 11:10 ` Felipe Contreras
2010-02-02 8:58 ` [crash, PATCH] Revert " Domenico Andreoli
2010-02-02 11:59 ` Jerome Glisse
2010-02-02 15:11 ` Domenico Andreoli
2010-02-02 11:56 ` Jerome Glisse
2010-02-02 15:42 ` Ingo Molnar
2010-02-02 23:15 ` Jerome Glisse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100204185603.GA6665@elte.hu \
--to=mingo@elte.hu \
--cc=airlied@gmail.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.sf.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).