[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <482AB615.5030000@bull.net>
Date: Wed, 14 May 2008 11:51:17 +0200
From: Benjamin Thery <benjamin.thery@...l.net>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Randy Dunlap <RANDY.DUNLAP@...CLE.COM>,
Greg KH <greg@...ah.com>, Al Viro <viro@....linux.org.uk>,
Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, Daniel Lezcano <dlezcano@...ibm.com>,
Pavel Emelyanov <xemul@...nvz.org>,
"Serge E. Hallyn" <serue@...ibm.com>, Tejun Heo <htejun@...il.com>
Subject: Re: [PATCH] Fix kobject_rename and !CONFIG_SYSFS v4
Andrew Morton wrote:
> On Wed, 14 May 2008 02:01:37 -0700 ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
>> Andrew Morton <akpm@...ux-foundation.org> writes:
>>
>>>> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
>>>> index 7858eac..6e61033 100644
>>>> --- a/include/linux/sysfs.h
>>>> +++ b/include/linux/sysfs.h
>>>> @@ -20,6 +20,8 @@
>>>> struct kobject;
>>>> struct module;
>>>>
>>>> +extern int kobject_set_name(struct kobject *kobj, const char *name, ...)
>>>> + __attribute__((format(printf, 2, 3)));
>>> Duplicating the kobject_set_name() declaration in sysfs.h is rather a hack.
>> A bit. It really isn't worse then a struct declaration like struct kobject;
>>
>>> It'd be better to move it into a new header file, included by both
>>> sysfs.h and kobject.h. Perhaps there are other declarations which can
>>> be moved with it.
>> My gut feel says that sysfs.h should include kobject.h instead of the
>> other way around.
This is also my feeling.
To do this, we need to move "struct attributes" related definitions to
kboject.h, and fix some .c files that don't include sysfs.h as they
should (sysfs.h was included indirectly via kojbect.h in these files: eg
kernel/sched.c, fs/partitions/check.c).
>>
>> However it gets reorganized, it is an entirely separate problem
>> from the one this patch sets out to solve and so should go in
>> a different patch.
>>
>
> umm, well, actually, it's a problem which your patch introduces, by adding a
> new dependency.
>
> uninlining sysfs_rename_dir() would be a sensible solution.
It is inlined only when CONFIG_SYSFS=n. When sysfs is enabled
sysfs_rename_dir() is compiled from fs/sysfs/dir.c
Uninlining it will require us to find an appropriate .c file to put it
in: we can't put it in fs/sysfs/dir.c. It is not built if CONFIG_SYSFS
is disabled.
-Benjamin
--
B e n j a m i n T h e r y - BULL/DT/Open Software R&D
http://www.bull.com
--
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