From: Alex Deucher <alexdeucher@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
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 14:18:20 -0500 [thread overview]
Message-ID: <a728f9f91002041118m6415844fp1740f18fdc1c9757@mail.gmail.com> (raw)
In-Reply-To: <20100204190649.GB6665@elte.hu>
On Thu, Feb 4, 2010 at 2:06 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Alex Deucher <alexdeucher@gmail.com> wrote:
>
>> On Thu, Feb 4, 2010 at 1:12 PM, Ingo Molnar <mingo@elte.hu> wrote:
>> >
>> > * Matthew Garrett <mjg59@srcf.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.
>
> Will the user know? IMHO what matters in the end is user expectation.
>
> Lets walk through what a current kernel tester of the drm/radeon driver sees
> when he types 'make oldconfig' after installing the (to-be-released) .33-rc7
> kernel. Firstly, the user with a brand-new distro already has this enabled:
>
> CONFIG_DRM_RADEON=y
>
> and knows the driver, and it performs adequately. Then in -rc7 he gets a new
> option:
>
> ATI Radeon (DRM_RADEON) [Y/n/?] y
> Enable modesetting on radeon by default (DRM_RADEON_KMS) [N/y/?] (NEW)
>
> The user might easily go: "Hey this is a driver i already have, and there's a
> new sub-option for this well-working driver. Sure, enable it, these kernel
> folks know what they are doing and i rarely see any crashes past -rc2
> kernels."
>
> Does this new option tell him what you just told me, 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.
>
> ?
>
> it doesnt. Even if he types '?', it tells:
>
> CONFIG_DRM_RADEON_KMS:
>
> Choose this option if you want kernel modesetting enabled by default,
> and you have a new enough userspace to support this. Running old
> userspaces with this enabled will cause pain.
>
> The user will likely go "cool I have a fresh distro with recent Xorg, lets
> try it".
>
And if it crashes, he'll report a bug and we'll fix it.
Alex
> If this is really a brand new driver essentially fresh out of
> drivers/staging/ in -rc7 you should be abundantly clear about that in the
> Kconfig help text - that it's a brand new driver and that it might crash on
> bootup, etc.
>
> Thanks,
>
> Ingo
>
>
next prev parent reply other threads:[~2010-02-04 19:18 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
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 [this message]
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=a728f9f91002041118m6415844fp1740f18fdc1c9757@mail.gmail.com \
--to=alexdeucher@gmail.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.sf.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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).