linux-kernel - Re: [PATCH 1/1] export native versions of machine

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 6 Mar 2008 13:28:23 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...ranet.com>
Cc:	Glauber Costa <glommer@...il.com>,
	Glauber Costa <gcosta@...hat.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	tglx@...utronix.de
Subject: Re: [PATCH 1/1] export native versions of machine_ops functions


* Avi Kivity <avi@...ranet.com> wrote:

>> i mean, i agree in general - but KVM is not a user of any of those 
>> currently static functions. So i've applied your patch but lets make 
>> sure those functions really get used :)
>
> The user will be in my 2.6.26 queue.  Unfortunately it means a 
> dependency between kvm.git and x86.git, again.

a couple of solutions:

- add the same patch to kvm.git (find it below), integrators 
  ought to be able to detect and exclude it

- i could start an x86.git#core tree that would include the for-linus 
  bits and any agreed-upon infrastructure changes [like this one]. (but 
  it would not include any other more experimental x86.git bits) You 
  could base kvm.git on that and track it. This makes integration even 
  easier because the commit IDs would be the same and git would be able 
  to resolve it. [but note, x86.git#core would not be an append-only 
  tree, it's a daily-rebased tree]

	Ingo

------------------>
Subject: x86: export native versions of machine_ops functions
From: Glauber Costa <gcosta@...hat.com>
Date: Wed, 5 Mar 2008 14:44:00 -0300

People overriding machine_ops provided functions may want to
call the native version after its pre-processing. It already
happens for the smp_ops functions, so I don't see a reason
for avoiding it here.

Signed-off-by: Glauber Costa <gcosta@...hat.com>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
 arch/x86/kernel/reboot.c |   10 +++++-----
 include/asm-x86/reboot.h |    5 +++++
 2 files changed, 10 insertions(+), 5 deletions(-)

Index: linux-x86.q/arch/x86/kernel/reboot.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/reboot.c
+++ linux-x86.q/arch/x86/kernel/reboot.c
@@ -326,7 +326,7 @@ static inline void kb_wait(void)
 	}
 }
 
-static void native_machine_emergency_restart(void)
+void native_machine_emergency_restart(void)
 {
 	int i;
 
@@ -376,7 +376,7 @@ static void native_machine_emergency_res
 	}
 }
 
-static void native_machine_shutdown(void)
+void native_machine_shutdown(void)
 {
 	/* Stop the cpus and apics */
 #ifdef CONFIG_SMP
@@ -432,7 +432,7 @@ static void native_machine_shutdown(void
 #endif
 }
 
-static void native_machine_restart(char *__unused)
+void native_machine_restart(char *__unused)
 {
 	printk("machine restart\n");
 
@@ -441,11 +441,11 @@ static void native_machine_restart(char 
 	machine_emergency_restart();
 }
 
-static void native_machine_halt(void)
+void native_machine_halt(void)
 {
 }
 
-static void native_machine_power_off(void)
+void native_machine_power_off(void)
 {
 	if (pm_power_off) {
 		if (!reboot_force)
Index: linux-x86.q/include/asm-x86/reboot.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/reboot.h
+++ linux-x86.q/include/asm-x86/reboot.h
@@ -16,5 +16,10 @@ struct machine_ops
 extern struct machine_ops machine_ops;
 
 void machine_real_restart(unsigned char *code, int length);
+void native_machine_emergency_restart(void);
+void native_machine_shutdown(void);
+void native_machine_restart(char *__unused);
+void native_machine_halt(void);
+void native_machine_power_off(void);
 
 #endif	/* _ASM_REBOOT_H */
--
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/