lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 26 Feb 2012 12:34:58 -0500 From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> To: "Liu, Jinsong" <jinsong.liu@...el.com> Cc: Jan Beulich <jbeulich@...e.com>, "keir.xen@...il.com" <keir.xen@...il.com>, "Brown, Len" <len.brown@...el.com>, "Li, Shaohua" <shaohua.li@...el.com>, "lenb@...nel.org" <lenb@...nel.org>, "xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>, "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 1/2] RFC: Prepare PAD for native and xen platform On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote: > Liu, Jinsong wrote: > > Jan Beulich wrote: > >>>>> "Liu, Jinsong" <jinsong.liu@...el.com> 02/23/12 2:29 PM >>> > >>> --- a/drivers/acpi/Kconfig > >>> +++ b/drivers/acpi/Kconfig > >>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU > >>> default y > >> > > >>> config ACPI_PROCESSOR_AGGREGATOR > >>> - tristate "Processor Aggregator" > >>> + bool "Processor Aggregator" > >> > >> There must be ways to address whatever strange problem you see > >> without making this piece of code non-modular. > >> > > > > Yes, another approach is x86_init approach, defining acpi_pad_ops at > > x86_init.c and overwritten when xen_start_kernel. This patch is just > > a RFC patch, to evaluate which approch is more reasonable :-) > > > > Have a more think about it, x86_init approach still need to disable acpi_pad module. > Seems we have to set acpi_pad as bool, as long as it need to hook to native acpi_pad fucs/variables. What about the other approach I suggested where there are some function overrides in osl.c? Something similar to https://lkml.org/lkml/2012/1/17/401, specifically https://lkml.org/lkml/2012/1/17/403 - that way you are not turning the modules into being built in, but intead have the function table already in the kernel (as some form of EXPORT_SYMBOL_GPL or a registration function). Instead of just one function being over-ridden it could have some more. However I am not sure if the osl.c is the place for this either. Perhaps Len might have some better ideas? -- 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