| 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
| ||
|
Message-Id: <200801172315.29976.michael-lists@free-electrons.com> Date: Thu, 17 Jan 2008 23:15:29 +0100 From: Michael Opdenacker <michael-lists@...e-electrons.com> To: Matt Mackall <mpm@...enic.com> Cc: linux-kernel@...r.kernel.org, Linux-tiny@...enic.com, Ingo Molnar <mingo@...e.hu> Subject: Re: [PATCH] x86: fix unconditional arch/x86/kernel/pcspeaker.c compiling On Thursday 17 January 2008, Matt Mackall wrote: > > >> diff -Naur linux-2.6.24-rc8-git1/arch/x86/kernel/Makefile_32 linux-2.6.24-rc8-git1-nopcspeaker/arch/x86/kernel/Makefile_32 > > >> --- linux-2.6.24-rc8-git1/arch/x86/kernel/Makefile_32 2008-01-17 09:48:58.000000000 +0100 > > >> +++ linux-2.6.24-rc8-git1-nopcspeaker/arch/x86/kernel/Makefile_32 2008-01-17 10:06:56.000000000 +0100 > > >> @@ -45,10 +45,13 @@ > > >> > > >> obj-$(CONFIG_VMI) += vmi_32.o vmiclock_32.o > > >> obj-$(CONFIG_PARAVIRT) += paravirt_32.o > > >> -obj-y += pcspeaker.o > > >> - > > >> obj-$(CONFIG_SCx200) += scx200_32.o > > >> > > >> +ifeq ($(CONFIG_INPUT_PCSPKR),y) > > >> + obj-y += pcspeaker.o > > >> +endif > > >> > > > > > > I'm not sure this does what you want. What if CONFIG_INPUT_PCSPKR = m? > > > > > Does it make sense to compile arch/x86/kernel/pcspeaker.c as a module? > > It defines no init and exit functions, and it defines an initcall, which > > only makes sense at boot time. > > Probably not. However, the above code won't build pcspeaker.o if > CONFIG_INPUT_PCSPKR = m. In other words, it'll break. > Here's a corrected version. Even if this patch doesn't seem to cause any bug (tested on a QEMU based PC), I'm wondering if this is "legal" (according to Linux standards) not to declare a device we don't care about, but that probably always exists in any PC-compatible machine? Doesn't this hurt the consistency of the device model? Another issue would be that we would no longer be able to load the speaker driver module from a kernel which wasn't originally compiled with support for this module. Perhaps we should only use this trick when CONFIG_EMBEDDED is set. In this case, we know we're using a limited, non-standard kernel, and having a partial device tree could be acceptable. What do you think? Thanks, Michael. Signed-off-by: Michael Opdenacker <michael@...e-electrons.com> diff -Naur linux-2.6.24-rc8-git1/arch/x86/kernel/Makefile_32 linux-2.6.24-rc8-git1-nopcspeaker/arch/x86/kernel/Makefile_32 --- linux-2.6.24-rc8-git1/arch/x86/kernel/Makefile_32 2008-01-17 09:48:58.000000000 +0100 +++ linux-2.6.24-rc8-git1-nopcspeaker/arch/x86/kernel/Makefile_32 2008-01-17 22:43:33.000000000 +0100 @@ -45,10 +45,13 @@ obj-$(CONFIG_VMI) += vmi_32.o vmiclock_32.o obj-$(CONFIG_PARAVIRT) += paravirt_32.o -obj-y += pcspeaker.o - obj-$(CONFIG_SCx200) += scx200_32.o +ifdef CONFIG_INPUT_PCSPKR + obj-y += pcspeaker.o +endif + + # vsyscall_32.o contains the vsyscall DSO images as __initdata. # We must build both images before we can assemble it. # Note: kbuild does not track this dependency due to usage of .incbin diff -Naur linux-2.6.24-rc8-git1/arch/x86/kernel/Makefile_64 linux-2.6.24-rc8-git1-nopcspeaker/arch/x86/kernel/Makefile_64 --- linux-2.6.24-rc8-git1/arch/x86/kernel/Makefile_64 2008-01-17 09:48:58.000000000 +0100 +++ linux-2.6.24-rc8-git1-nopcspeaker/arch/x86/kernel/Makefile_64 2008-01-17 22:46:07.000000000 +0100 @@ -40,6 +40,9 @@ obj-$(CONFIG_PCI) += early-quirks.o obj-y += topology.o -obj-y += pcspeaker.o + +ifdef CONFIG_INPUT_PCSPKR + obj-y += pcspeaker.o +endif CFLAGS_vsyscall_64.o := $(PROFILING) -g0 -- Michael Opdenacker, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) -- 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