linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>
>

  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).