[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080305132952.GD11701@elte.hu>
Date: Wed, 5 Mar 2008 14:29:53 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Alexey Dobriyan <adobriyan@...ru>
Cc: Greg KH <gregkh@...e.de>, "Zhang, Rui" <rui.zhang@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
kay.sievers@...y.org, Andrew Morton <akpm@...ux-foundation.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: 2.6.25-rc regression: kernel panic on boot
* Alexey Dobriyan <adobriyan@...ru> wrote:
> On Tue, Mar 04, 2008 at 02:54:47PM +0100, Ingo Molnar wrote:
> > CONFIG_SYSFS_DEPRECATED=y changed its meaning recently and causes
> > regressions in working setups that had SYSFS_DEPRECATED disabled.
> >
> > so rename it to SYSFS_DEPRECATED_V2 so that testers pick up the new
> > default via 'make oldconfig', even if their old .config's disabled
> > CONFIG_SYSFS_DEPRECATED ...
>
> It has all the same help text, so people who disabled it in the past
> will disable again!
please send a patch that changes the help text. For this to happen
people have to change the default consciously.
> > +config SYSFS_DEPRECATED_V2
> > bool "Create deprecated sysfs files"
> > depends on SYSFS
> > default y
> > + select SYSFS_DEPRECATED
> > help
> > This option creates deprecated symlinks such as the
> > "device"-link, the <subsystem>:<name>-link, and the
>
> Is anyone aware of a case when turning SYSFS_DEPRECATED back on also
> breaks something? I mean, option can be simply removed and sysfs
> people can finally stop breaking boxes.
i have no strong opinion either way, but i think distributions that ship
new userspace can legitimately disable this option.
That way once all new distributions have updated userspace we can flip
the default around and can mark it 'default n'. This at least gives us a
theoretical path towards getting rid of unwanted legacies. (I suspect
this was the plan all along, it's just that the clock got restarted now
with the different legacy/breakage property.)
longer term we could also put in a WARN_ON_ONCE() which kerneloops.org
would automatically track. That would give an objective metric about
when to change the default. (and when to get rid of the legacy
altogether)
Ingo
--
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