[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B454F59.1030503@cn.fujitsu.com>
Date: Thu, 07 Jan 2010 11:04:57 +0800
From: Li Zefan <lizf@...fujitsu.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
CC: Randy Dunlap <randy.dunlap@...cle.com>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org,
"menage@...gle.com" <menage@...gle.com>, kirill@...temov.name
Subject: Re: mmotm 2010-01-06-14-34 uploaded (kernel/cgroup)
>>>>> It contains the following patches against 2.6.33-rc3:
>>>> kernel/cgroup.c: In function 'cgroup_write_event_control':
>>>> kernel/cgroup.c:2949: error: implicit declaration of function 'eventfd_fget'
>>>> kernel/cgroup.c:2949: warning: assignment makes pointer from integer without a cast
>>>> kernel/cgroup.c:2955: error: implicit declaration of function 'eventfd_ctx_fileget'
>>>> kernel/cgroup.c:2955: warning: assignment makes pointer from integer without a cast
>>>> make[2]: *** [kernel/cgroup.o] Error 1
>>>>
>>> Hmm, how about this rather than adding #ifdefs..
>>> Paul, Li, how do you think ?
>> I think make CONFIG_CGROUPS select EVENTFD would be better.
>>
> Hm, as far as I know, SELECT is not recommended. But yes, it seems side-effect
> of select is small here. But I avoid it as much as possible, usually.
>
> Moreover, in this case,
> - EVENTFD is a feature which is enabled by default.
> - cgroup is "Say N if unsure" config.
>
> In this case, "depends on" is good.
>
I thought we use "depends on" if it's obvious by the config name
that a config depends on another config, and use "select" otherwise.
Referring to Documentation/Kbuild/kconfig-language.txt:
select should be used with care.
...
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
It does suggest "depends on" is better. :)
--
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