Re: [PATCH] kobject: Suppress compiler warning with gcc 3.x

["Américo Wang" <xiyou.wangcong@gmail.com>]

On Wed, Jun 02, 2010 at 11:40:12PM -0700, Eric W. Biederman wrote:
>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.

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.