Re: 2.6.25-rc regression: kernel panic on boot

[Ingo Molnar]

* Alexey Dobriyan <adobriyan@xxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/