[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20101113144512.GB29781@kroah.com>
Date: Sat, 13 Nov 2010 06:45:12 -0800
From: Greg KH <greg@...ah.com>
To: Rakib Mullick <rakib.mullick@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] fs, sysfs: Change sysfs_pathname function prototype.
On Sat, Nov 13, 2010 at 07:35:10PM +0600, Rakib Mullick wrote:
> On 11/11/10, Rakib Mullick <rakib.mullick@...il.com> wrote:
> > On 11/11/10, Greg KH <greg@...ah.com> wrote:
> >>
> >> perhaps, yes, that might be correct, but as almost no one builds with
> >> WARN not enabled, is this a real issue?
> >
> > I'm trying to find out the config, which causes the warning (it gets
> > overwritten). Not all config produces the warning. Maybe - it was a
> > randconfig, which generates the warning. I'll again try some
> > randconfig and will try to find the config which generates the
> > warning. If I find something I'll notice. But, I think the issue is
> > real.
> >
> CONFIG_EMBEDDED=y and CONFIG_BUG=n produces that warning, in that case
> #ifndef WARN is defined as follows:
>
> #define WARN(condition, format...) ({ \
> int __ret_warn_on = !!(condition); \
> unlikely(__ret_warn_on); \
> })
>
> from above we can see, format isn't used. sysfs_pathname is passed as
> format when called from sysfs_add_one through WARN(). Since format
> isn't used, that's why we're having that problem. Am I right? Should I
> create a patch to split up WARN() and calling sysfs_pathname ? Or is
> there any better way?
No, you should probably just not worry about it as the number of people
using those two configuration options are in the extreme minority so
it's really not a big issue at all.
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