kobject: Suppress compiler warning with gcc 3.x
in [Kernel]
|
Prev: [PATCH] kobject: Suppress compiler warning with gcc 3.x
Next: [PATCH 0/6] sctp: add multistream scheduling feature
From: Eric W. Biederman on 3 Jun 2010 02:50 Américo Wang <xiyou.wangcong(a)gmail.com> writes: > On Wed, Jun 02, 2010 at 11:02:28PM -0700, Eric W. Biederman wrote: >>Américo Wang <xiyou.wangcong(a)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(a)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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Américo Wang on 3 Jun 2010 05:00 On Wed, Jun 02, 2010 at 11:40:12PM -0700, Eric W. Biederman wrote: >Américo Wang <xiyou.wangcong(a)gmail.com> writes: > >> On Wed, Jun 02, 2010 at 11:02:28PM -0700, Eric W. Biederman wrote: >>>Américo Wang <xiyou.wangcong(a)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(a)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. Agreed. >Assuming/requiring that files that include sysfs.h also include >kobject.h to seems like the wrong way to go. Yeah. However, this compile warning only appears in gcc 3.x and it seems it's a fault of gcc 3.x, not the code. I am wondering if we need to fix it. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric Dumazet on 3 Jun 2010 05:40
Le jeudi 03 juin 2010 à 16:57 +0800, Américo Wang a écrit : > > Yeah. > > However, this compile warning only appears in gcc 3.x > and it seems it's a fault of gcc 3.x, not the code. I am wondering > if we need to fix it. > I believe gcc-3 was born before the code you mention. We can keep ability to compile kernel on old gcc for very litle care. Lets do it please, unless there is a real show-stopper, not because we feel gcc-3 is 'old' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |