android_kernel_xiaomi_sm8350/arch/um/sys-x86_64/bugs.c

/*
 * Copyright 2003 PathScale, Inc.
 *
 * Licensed under the GPL
 */

#include "sysdep/ptrace.h"

void arch_check_bugs(void)
{
}

void arch_examine_signal(int sig, struct uml_pt_regs *regs)
{
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 2005-04-16 18:20:36 -04:00			`/*`
			`* Copyright 2003 PathScale, Inc.`
			`*`
			`* Licensed under the GPL`
			`*/`

			`#include "sysdep/ptrace.h"`

			`void arch_check_bugs(void)`
			`{`
			`}`

uml: further bugs.c tidying bugs.c, for both i386 and x86_64, can undergo further cleaning - The i386 arch_check_bugs only does one thing, so we might as well inline the cmov checking. The i386 includes can be trimmed down a bit. arch_init_thread wasn't used, so it is deleted. The panics in arch_handle_signal are turned into printks because the process is about to get segfaulted anyway, so something is dying no matter what happens here. Also, the return value was always the same, so it contained no information, so it can be void instead. The name is changed to arch_examine_signal because it doesn't handle anything. The caller of arch_handle_signal, relay_signal, does things in a different order. The kernel-mode signal check is now first, which puts everything else together, making things a bit clearer conceptually. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Jeff Dike <jdike@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2008-02-05 01:30:40 -05:00			`void arch_examine_signal(int sig, struct uml_pt_regs *regs)`
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 2005-04-16 18:20:36 -04:00			`{`
			`}`