[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120201222441.GB2333@kroah.com>
Date: Wed, 1 Feb 2012 14:24:41 -0800
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Jiri Slaby <jslaby@...e.cz>, Alan Cox <alan@...rguk.ukuu.org.uk>,
LKML <linux-kernel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Maciej Rutecki <maciej.rutecki@...il.com>
Subject: Re: [PATCH] sysfs: Optionally count subdirectories to support buggy
applications
On Wed, Feb 01, 2012 at 02:21:59PM -0800, Eric W. Biederman wrote:
>
> lm_sensors and possibly other applications get confused if all sysfs
> directories return nlink == 1. The lm_sensors code that got confused
> was just wrong and a fixed version of lm_sensors should be released
> shortly.
>
> There may be other applications that have problems with sysfs return
> nlink == 1 for directories. To allow people to continue to use old
> versions of userspace with new kernels add to sysfs a compile time
> option to maintain mostly precise directory counts for those people who
> don't mind the cost.
>
> I have moved where we keep nlink in sysfs_dirent as compared to previous
> versions of subdirectory counting to a location that packs better.
>
> Signed-off-by: Eric W. Biederman <ebiederm@...ssion.com>
> ---
> fs/sysfs/Kconfig | 15 +++++++++++++++
> fs/sysfs/dir.c | 8 ++++++++
> fs/sysfs/inode.c | 2 ++
> fs/sysfs/sysfs.h | 38 ++++++++++++++++++++++++++++++++++++++
> 4 files changed, 63 insertions(+), 0 deletions(-)
>
> diff --git a/fs/sysfs/Kconfig b/fs/sysfs/Kconfig
> index 8c41fea..9b403e9 100644
> --- a/fs/sysfs/Kconfig
> +++ b/fs/sysfs/Kconfig
> @@ -21,3 +21,18 @@ config SYSFS
> example, "root=03:01" for /dev/hda1.
>
> Designers of embedded systems may wish to say N here to conserve space.
> +
> +config SYSFS_COUNT_LINKS
> + bool "sysfs count subdirectoires to support buggy applications"
> + default n
As we don't want to break things, this should be default y, right?
Also, should we list this in the feature_removal list as well so that we
can get rid of it in a year or so?
thanks,
greg k-h
--
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