[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1314022627.68014.YahooMailNeo@web162017.mail.bf1.yahoo.com>
Date: Mon, 22 Aug 2011 07:17:07 -0700 (PDT)
From: Pintu Agarwal <pintu_agarwal@...oo.com>
To: Américo Wang <xiyou.wangcong@...il.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: help for kernel initcall section (init.h)
----- Original Message -----
> From: Américo Wang <xiyou.wangcong@...il.com>
> To: Pintu Agarwal <pintu_agarwal@...oo.com>
> Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
> Sent: Monday, 22 August 2011 2:38 PM
> Subject: Re: help for kernel initcall section (init.h)
>
> On Sun, Aug 21, 2011 at 11:54 AM, Pintu Agarwal <pintu_agarwal@...oo.com>
> wrote:
>> Hi,
>>
>> I need some help in modifying initcall section in init.h.
>>
>> That is :
>>
>> #define __define_initcall(level,fn,id) \
>> static initcall_t __initcall_##fn##id __used \
>> __attribute__((__section__(".initcall" level
> ".init"))) = fn
>>
>> I have to create two different kinds (and later more) of init section and
> use one of them based on some condition.
>> For example, I have one init section for normal mode and one init section
> for charger mode.
>> During charger mode, I do not have to execute all the initcall so a
> charger.initcall is create with lesser init function.
>> The charger initcall section is as follows:
>> #define __define_charger_initcall(level,fn,id) \
>> static initcall_t __charger_initcall_##fn##id __used \
>> __attribute__((__section__(".charger.initcall" level
> ".init"))) = fn
>>
>>
>> Now the problem is that during compile time both of them needs to be
> polulated based on CHARGER_MODE is enabled or disabled.
>> How can this decision be taken during compile time under the macro
> "__define_initcall" ??
>>
>> Something like :
>>
>> #define __define_initcall(level,fn,id) \
>> static initcall_t
> __initcall_##fn##id __used \
>>
> __attribute__((__section__(".initcall" level ".init"))) =
> fn \
>> #if
> defined(CHARGER_MODE) \
>> static initcall_t
> __charger_initcall_##fn##id __used \
>>
> __attribute__((__section__(".charger.initcall"
> level ".init"))) = fn \
>> #endif
>
> Hi,
>
> Why not
>
> X_initcall(foo_initcall);
> #ifdef CHARGER_MODE
> X_initcall(foo_charger_initcall);
> #endif
>
> ?
>
No the requirement is not to do like this.
This requires defining 2 set of init calls, one for normal and one for charger init call.
We do not want to define separate init calls for charger.
We just want to take a decision during compile time to determine which initcalls should be used during charger mode.
Thus we need compile time comparison in macro which helps us in determining whether _this__ init call should be added in charger.init section or not.
Thus we can do as follows:-
------------------------------------------------------------------------------------------------------------------------------------
#define __define_initcall(level,fn,id) static initcall_t __initcall_##fn##id __used __attribute__ ((__section__(".initcall" level ".init"))) = fn \
#ifdef CHARGER_MODE \
static initcall_t __charger_initcall_##fn##id __used __attribute__ ((__section__(".charger.initcall" level ".init"))) = fn \
#endif
#define device_initcall(fn) __define_initcall("6", fn, 6, 1)
#define __initcall(fn) device_initcall(fn)
#define module_init(x) __initcall(x);
#define early_initcall(fn) module_init(fn)
------------------------------------------------------------------------------------------------------------------------------------
Basically we need something like:
#define __define_initcall(....) \
/* polupate init section */ \
#ifdef CHARGER_MODE \
/* polupate charger.init section also */ \
#elif ANOTHER_MODE \
/* polupate another.init section also */ \
#elif ....
.............
.............
#endif
Is it possible to do "#if or #ifdef" inside "#define" ?????
Basically, we need to populate each.init section based on some compile time condition.
How can we do that????
Thanks,
Pintu
--
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