Messages in this thread | | | From | (Eric W. Biederman) | Date | Wed, 02 Jun 2010 23:40:12 -0700 | Subject | Re: [PATCH] kobject: Suppress compiler warning with gcc 3.x |
| |
Américo Wang <xiyou.wangcong@gmail.com> writes:
> On Wed, Jun 02, 2010 at 11:02:28PM -0700, Eric W. Biederman wrote: >>Américo Wang <xiyou.wangcong@gmail.com> writes: >> >>> On Thu, Jun 03, 2010 at 07:31:41AM +0200, Eric Dumazet wrote: >>>>Le jeudi 03 juin 2010 à 14:23 +0900, Tetsuo Handa a écrit : >>>>> Gcc 3.x generates a warning >>>>> >>>>> include/linux/sysfs.h:183: warning: parameter has incomplete type >>>>> >>>>> on each file. >>>>> Suppress the warning by moving the definition of "enum kobj_ns_type" >>>>> to before "#include <linux/sysfs.h>". >>>>> >>>>> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> >>>> >>>> >>>>I was about to submit same patch, but I was also reverting 27eabc7cb4b3 >>>>(sysfs: Don't use enums in inline function declaration.) >>>> >>>>So that sysfs_exit_ns() prototype is consistent regardless of >>>>CONFIG_SYSFS >>>> >>>>What do you think ? >>>> >>> >>> This looks odd, in sysfs.h we do have a forward declaration of >>> enum kobj_ns_type... I am wondering why gcc 3.x doesn't recognize it. >> >>Because the replacement is an inline, and we are passing the enum by value >>gcc wants to see the full definition, at the point where the inline function >>is declared. >> > > But sysfs_exit_ns() is not inlined if CONFIG_SYSFS here.
You are right gcc 3.x seems full of it. I was thinking of the !CONFIG_SYSFS case where I had to pull out the enum because it is in fact inlined.
If we are going to worry about gcc 3.x and about my !CONFIG_SYSFS inline function the clean way to handle this seems to be to introduce a new header file that both sysfs.h and kobject.h can include. Assuming/requiring that files that include sysfs.h also include kobject.h to seems like the wrong way to go.
Eric
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |