Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switchout of staging."

[Ingo Molnar]

* Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:

> On Thu, Feb 04, 2010 at 07:12:18PM +0100, Ingo Molnar wrote:
> > 
> > * Matthew Garrett <mjg59@xxxxxxxxxxxxx> 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
--
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/