The current implementation of per_cpu relies on several non-c99 features,
and in additional involves arbitrary pointer arithmetic which is not MIS-
RA C friendly.
This patch introduces struct per_cpu_region which holds all the per_cpu
variables. Allocation of per_cpu data regions and access to per_cpu vari-
ables are greatly simplified, at the cost of making all per_cpu varaibl-
es accessible in files.
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
There are some massages which is not fatal error but should to print
to serial and sbuf(hvlog) at the same time. pr_fatal is for fatal error
massages and it is not good choice for the situation above.
Introduce a new API pr_acrnlog to deal with the situation. And replace the
following printf with pr_acrnlog for massages should be print to sbuf and
serial. Then developers can get those massages on serial and BTM(Boot Time
Measurement) can use acrnlog to get those massages from sbuf.
BTM refers to Boot Time Measurement which will read acrnlog file to get
timestamps of steps we want.
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
It is an extension of GCC CPP to:
* allow omitting a variable macro argument entirely, and
* use ## __VA_ARGS__ to remove the the comma before ## __VA_ARGS__ when
__VA_ARGS__ is empty.
The only use of ## _VA_ARGS__ is to define the pr_xxx() macros, with the first
argument being the format string and the rest the to-be-formatted arguments. The
format string is explicitly spelled out because another macro pr_fmt() is used
to add to the format string a prefix which is customizable by defining what
pr_fmt() expands to.
For C99 compliance, this patch changes the pr_xxx() macros in the following
pattern.
- #define pr_fatal(fmt, ...) \
- do_logmsg(LOG_FATAL, pr_fmt(fmt), ## __VA_ARGS__); \
+ #define pr_fatal(...) \
+ do_logmsg(LOG_FATAL, pr_prefix __VA_ARGS__); \
Reference:
* https://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic-Macros
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Huihuang Shi