linux-kernel - Re: [PATCH] x86: fix unconditional arch/x86/kernel/pcspeaker.c?compiling

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <47909821.1090907@free-electrons.com>
Date:	Fri, 18 Jan 2008 13:14:25 +0100
From:	Michael Opdenacker <michael-lists@...e-electrons.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org,
	Linux-tiny@...enic.com
Subject: Re: [PATCH] x86: fix unconditional	arch/x86/kernel/pcspeaker.c?compiling

On 01/18/2008 12:02 PM, Ingo Molnar wrote:
>
> why didnt you make this:
>
>   obj-$(CONFIG_INPUT_PCSPKR)		+= pcspeaker.o
>
> ?
>   
Many thanks for your feedback.

That's what I did first, but if  CONFIG_INPUT_PCSPKR=m,
arch/x86/kernel/pcspeaker.c gets compiled as a module. While compiling
doesn't fail, is this still a valid module? It defines no init and exit
functions, and it defines an initcall, which only makes sense at boot time.

We could make pcspeaker.c depend on another switch, like
CONFIG_PCSPEAKER on mips. We could offer the possibility to disable it
when CONFIG_EMBEDDED is set.

What do you think?

Michael.

-- 
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/