[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1zkxtinlw.fsf@fess.ebiederm.org>
Date: Wed, 14 Jul 2010 17:40:27 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@...e.de>, Greg KH <greg@...ah.com>,
linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
alsa-devel@...a-project.org, Jens Axboe <axboe@...nel.dk>,
Stephen Hemminger <shemminger@...tta.com>,
Kay Sievers <kay.sievers@...y.org>,
Alan Stern <stern@...land.harvard.edu>,
"James E.J. Bottomley" <James.Bottomley@...e.de>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Randy Dunlap <randy.dunlap@...cle.com>,
Tejun Heo <tj@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
David Howells <dhowells@...hat.com>,
Dave Airlie <airlied@...il.com>
Subject: Re: [PATCH] driver core: remove CONFIG_SYSFS_DEPRECATED
Andrew Morton <akpm@...ux-foundation.org> writes:
> On Fri, 9 Jul 2010 11:54:50 -0700
> Greg Kroah-Hartman <gregkh@...e.de> wrote:
>
>> This is no longer needed by any userspace tools, so it's safe to
>> remove.
>
> Makes my FC6 test box not boot - can't find /dev/root. Then when I go
> back to plain old mainline (2.6.35-rc5) and run `make oldconfig', the
> .config change sticks:
>
> @@ -106,8 +106,7 @@
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> # CONFIG_CGROUPS is not set
> -CONFIG_SYSFS_DEPRECATED=y
> -CONFIG_SYSFS_DEPRECATED_V2=y
> +# CONFIG_SYSFS_DEPRECATED_V2 is not set
> CONFIG_RELAY=y
> CONFIG_NAMESPACES=y
> # CONFIG_UTS_NS is not set
>
> and the box still won't boot.
The reason FC6 doesn't boot is there is a userspace tool
I believe in the initrd that cares about symlinks when it should
not.
What is more interesting is that currently there is a bug in
2.6.35-rc5 where rmmod <netdriver> modprobe <netdriver> will in fact
fail. There was an inadvertent regression and no one has noticed or
complained. I spotted it by code review just a little bit ago and I
haven't had a chance to write and test the fix yet.
If the code is going to start bitrotting and no one is going to
notice or care simply removing the code instead of subjecting users
to weird unexpected breakage seems like a responsible thing to do.
Eric
--
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