- 23 Dec, 2007 1 commit
-
-
Paul Mundt authored
Currently when using KCONFIG_ALLCONFIG with randconfig the choice options are clobbered. As recommended by Roman, this adds an is_new test to see whether to select a new option or obey the existing one. This is a resend of the earlier patch a couple of weeks ago, since there was no reply. Original thread is at http://lkml.org/lkml/2007/11/28/94 Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 17 Dec, 2007 1 commit
-
-
Nathan Lynch authored
bloat-o-meter assumes that a '.' anywhere in a symbol's name means that it is static and prepends 'static.' to the first part of the symbol name, discarding the portion of the name that follows the '.'. However, the names of function entry points begin with '.' in the ppc64 ABI. This causes all function text size changes to be accounted to a single 'static.' entry in the output when comparing ppc64 kernels. Change getsizes() to ignore the first character of the symbol name when searching for '.'. Signed-off-by:
Nathan Lynch <ntl@pobox.com> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by:
-
- 13 Dec, 2007 1 commit
-
-
Guillaume Chazarain authored
The commit: 18c32dac "kbuild: fix building with O=.. options" disabled the creation of a Makefile in a new O=... directory. Restore it. Signed-off-by:
Guillaume Chazarain <guichaz@yahoo.fr> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org>
-
- 09 Dec, 2007 1 commit
-
-
Sam Ravnborg authored
The check introduced in commit: 4f1127e2 "kbuild: fix infinite make recursion" caused certain external modules not to build and also caused 'make targz-pkg' to fail. This is a minimal fix so we revert to previous behaviour - but we do not overwrite the Makefile in the top-level directory. Signed-off-by:
Jay Cliburn <jacliburn@bellsouth.net> Cc: Jay Cliburn <jacliburn@bellsouth.net>
-
- 29 Nov, 2007 1 commit
-
-
Andy Whitcroft authored
This version brings a new terse output mode as well as many improvements to the unary detection and bare type regcognition. It also brings the usual updates for false positives, though these seem to be slowing markedly now that the unary detector is no longer just putting its finger in the air and guessing. Of note: - new --terse mode producing a single line per report - loosening of the block brace checks - new checks for enum/union/struch brace placements - hugely expanded "bare type" detection - checks for inline usage - better handling of already open comment blocks - handle patches which introduce or remove lines without newlines Andy Whitcroft (19): Version: 0.12 style fixes as spotted by checkpatch add a --terse options of a single line of output per report block brace checks should only apply for single line blocks all new bare type detector check spacing for open braces with enum, union and struct check for LINUX_VERSION_CODE macros definition bracketing checks need to ignore -ve context clean up the mail-back mode, -q et al expand possible type matching to declarations allow const and sparse annotations on possible types handle possible types as regular types everywhere prefer plain inline over __inline__ and __inline all new open comment detection fix up conditional extraction for if assignment checks add const to the possible type matcher unary checks: a for loop is a conditional too possible types: detect function pointer definitions handle missind newlines at end of file, report addition Signed-off-by:Andy Whitcroft <apw@shadowen.org> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
- 17 Nov, 2007 2 commits
-
-
Sam Ravnborg authored
Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in all.config. For a fix the diffstat is nice: 6 files changed, 3 insertions(+), 36 deletions(-) The patch reverts these commits: - 0f855aa6 ("kconfig: add helper to set config symbol from environment variable") - 2a113281 ("kconfig: use $K64BIT to set 64BIT with all*config targets") Roman Zippel pointed out that kconfig supported string compares so the additional complexity introduced by the above two patches were not needed. With this patch we have following behaviour: # make {allno,allyes,allmod,rand}config [ARCH=...] option \ host arch | 32bit | 64bit ===================================================== ./. | 32bit | 64bit ARCH=x86 | 32bit | 32bit ARCH=i386 | 32bit | 32bit ARCH=x86_64 | 64bit | 64bit The general rule are that ARCH= and native architecture takes precedence over the configuration. So make ARCH=i386 [whatever] will always build a 32-bit kernel no matter what the configuration says. The configuration will be updated to 32-bit if it was configured to 64-bit and the other way around. This behaviour is consistent with previous behaviour so no suprises here. make ARCH=x86 will per default result in a 32-bit kernel but as the only ARCH= value x86 allow the user to select between 32-bit and 64-bit using menuconfig. Signed-off-by:
-
Sam Ravnborg authored
Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in all.config. For a fix the diffstat is nice: 6 files changed, 3 insertions(+), 36 deletions(-) The patch reverts these commits: 0f855aa6 -> kconfig: add helper to set config symbol from environment variable 2a113281 -> kconfig: use $K64BIT to set 64BIT with all*config targets Roman Zippel pointed out that kconfig supported string compares so the additional complexity introduced by the above two patches were not needed. With this patch we have following behaviour: # make {allno,allyes,allmod,rand}config [ARCH=...] option \ host arch | 32bit | 64bit ===================================================== ./. | 32bit | 64bit ARCH=x86 | 32bit | 32bit ARCH=i386 | 32bit | 32bit ARCH=x86_64 | 64bit | 64bit The general rule are that ARCH= and native architecture takes precedence over the configuration. So make ARCH=i386 [whatever] will always build a 32-bit kernel no matter what the configuration says. The configuration will be updated to 32-bit if it was configured to 64-bit and the other way around. This behaviour is consistent with previous behaviour so no suprises here. make ARCH=x86 will per default result in a 32-bit kernel but as the only ARCH= value x86 allow the user to select between 32-bit and 64-bit using menuconfig. Signed-off-by:
-
- 12 Nov, 2007 4 commits
-
-
Sam Ravnborg authored
After unification of the Kconfig files and introducing K64BIT support in kconfig it required only trivial changes to enable "make ARCH=x86". With this patch you can build for x86_64 in several ways: 1) make ARCH=x86_64 2) make ARCH=x86 K64BIT=y 3) make ARCH=x86 menuconfig => select 64-bit Likewise for i386 with the addition that i386 is default is you say ARCH=x86. Signed-off-by: -
Sam Ravnborg authored
The variable K64BIT can now be used to select the value of CONFIG_64BIT. This is for example useful for powerpc to generate allmodconfig for both bit sizes - like this: make ARCH=powerpc K64BIT=y make ARCH=powerpc K64BIT=n To use this the Kconfig file must use "64BIT" as the config value to select between 32 and 64 bit. Signed-off-by: -
Sam Ravnborg authored
Add conf_set_env_sym() that can set an already defined symbol based on the value of an environment variable. Unknown symbols are silently ignored. A warning is printed if the value of the environment variable is unexpected. Signed-off-by: -
Sam Ravnborg authored
This patch introduce no functional changes. Signed-off-by:
-
- 25 Oct, 2007 3 commits
-
-
Sam Ravnborg authored
After a small change in kconfig Makefile we could move all x86 Kconfig files to x86 directory. Signed-off-by: -
Sam Ravnborg authored
Do not hardcode the arch/$(ARCH)/Kconfig name all over Signed-off-by: -
Sam Ravnborg authored
With some small changes to kconfig makefile we can now locate the defconfig files for i386 and x86_64 in the configs/ subdirectory under x86. make ARCH=i386 defconfig and make defconfig works as expected also after this change. But arch maintainers shall now update a defconfig file in the configs/ directory. Signed-off-by:
-
- 23 Oct, 2007 1 commit
-
-
Rusty Russell authored
This adds the logic to convert the virtio ids into module aliases, and includes a modalias entry in sysfs and the env var to make probing work. Signed-off-by:Rusty Russell <rusty@rustcorp.com.au>
-
- 20 Oct, 2007 3 commits
-
-
Kyle McMartin authored
Signed-off-by:Kyle McMartin <kyle@mcmartin.ca>
-
Randy Dunlap authored
Put kernel version info on title bar in xconfig (qconf) instead of defaulting to "qconf". Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Linus Torvalds authored
This reverts commit a5bf3d89 . David Brownell notes that this causes a regression visible in the drivers/usb/gadget Kconfig file: "That Kconfig hasn't changed (other than adding new drivers), and it's worked that way for several years now ... so the issue seems to be changes in menuconfig/kconfig/etc semantics. The issue is that when USB_GADGET=m, it's no longer possible to configure peripheral controller drivers as modules ... the controller drivers can now only be configured for static linkage. It should be making a choice of one of the controller drivers which could work on the target system, and allow that driver to be linked either as a module (ok iff USB_GADGET=m) or statically." Reverting this commit resolves the problem, and also fixes a second problem that David noticed: various dependent options couldn't be enabled. Tested-and-reported-by:
David Brownell <david-b@pacbell.net> Cc: Randy Dunlap <rdunlap@xenotime.net> Cc: Jan Beulich <jbeulich@novell.com>, Cc: Andrew Morton <akpm@linux-foundation.org>, Cc: Sam Ravnborg <sam@ravnborg.org>, Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
-
- 19 Oct, 2007 2 commits
-
-
Sam Ravnborg authored
cc-cross-prefix is useful for the architecture that like to provide a default CROSS_COMPILE value, but may have several to select between. Sample usage: ifneq ($(SUBARCH),$(ARCH)) ifeq ($(CROSS_COMPILE),) CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- m68k-linux-) endif endif Actual usage by the different archs will taken care of later. Signed-off-by: -
Joern Engel authored
Trivial change in a comment. Signed-off-by:
Joern Engel <joern@logfs.org> Signed-off-by:
Andre Haupt <andre@finow14.de> Signed-off-by:
-
- 18 Oct, 2007 5 commits
-
-
Andy Whitcroft authored
This version brings a more cautious checkpatch.pl by default. The more subjective checks are only applied with the --strict option. It also brings the usual slew of corrections for false positives. Of note: - new tree detection, the source tree will be found via the executable - a major revamp of the unary detection to make it more parser like - a new summary at the bottom of the report - --strict option for subjective checks - --file to enable checking on complete files - support for use in emacs "compile" window Andy Whitcroft (27): Version: 0.11 fix up cat_vet for the case where there are no control characters any cast to a pointer introduces a type cpp unary operator detection needs to float attributes are also valid in type definitions sizeof may be a bareword and makes its argument unary unary checks for #ifdef et al need to find end of line add new --file mode to handle raw source files add --strict/--subjective which enables the subjective tests add some additional standard type suffixes cpp #elif is also a unary prefix case is not a function name widen asm volatile exceptions __kprobes is a type attribute typeof is a unary operator function open parenthesis checks should check all occurances expand sizeof() binary exceptions linux/irq.h should not be recommended work harder to find the kernel root and add --root= fix --emacs mode line numbers and string concatenation warnings add a summary to the bottom of the main report loosen assignment in if checks update operator spacing to maintain tabs in output revamp unary detection corruption/line wrapped patches need only reporting once revamp s/u/be/le 8/16/32/64 bit types handle missing ,1 in uni-diff header Mike D. Day (2): Adds support to checkpatch.pl for running in the emacs compile window. checkpatch: Fix line number reporting Signed-off-by: -
bugme-daemon@bugzilla.kernel.org authored
http://bugzilla.kernel.org/show_bug.cgi?id=8941 Current Debian's kernel-modules depend on matching linux-image-$version, though Linux's make deb-pkg build a .deb that 'Provides: kernel-image-$version' only. The following patch adds the Debian-compliant 'Provides', leaving the default one; hopely this will make way all happy. Signed-off-by:
paolo <oopla@users.sf.net> Signed-off-by:
-
Rob Landley authored
Typo in comment in scripts/kconfig/Makefile. Signed-off-by:
Rob Landley <rob@landley.net> Signed-off-by:
-
Rob Landley authored
Prevent docproc from segfaulting when SRCTREE isn't set. Signed-off-by:
-
Trent Piepho authored
When part of build an external module tree, modpost first reads in the kernel's and then the external tree's Module.symvers files. From these files it establishes a symbol => module mapping. When it later reads in each module built and processes the symbols it finds, it discovers the symbol=>module mapping from Module.symvers and leaves it as it is. The problem comes with a module has been re-named or a symbol has moved from one module to another, since the Module.symvers file was generated. modpost does not update the symbol=>module mapping when it finds the new location of the symbol when scanning the newly built modules. This results in the module containing incorrect dependency information and the new Module.symvers file written by modpost will also contain the incorrect mappings, perpetuating the problem to the next build, and so on. When building the out of kernel development tree for kernel subsystem, like v4l-dvb or ALSA, deleting the external Module.symvers file before building (which the kernel build system doesn't do and shouldn't be necessary anyway), won't fix the problem. modpost still reads the kernel's Module.symvers, and since we a building a kernel subsystem, it will define the same symbols as the external modules. Signed-off-by:
Trent Piepho <xyzzy@speakeasy.org> Signed-off-by:
-
- 17 Oct, 2007 3 commits
-
-
Randy Dunlap authored
Johannes Berg reports (Thanks!) that &struct names are not highlighted in html output format when they are inside a DOC: block. DOC: blocks were not escaped thru xml_escape() like other kernel-doc comments were. Fixed that. However, that left a problem with <p> ($blankline_html) being processed thru xml_escape(), converting it to <p>, which isn't good for the generated html output (the <p> should remain unchanged), so this patch also introduces the notion of "local" kernel-doc meta-characters ('\\\\mnemonic:'), which are converted to html just before writing the stream to its output file. Please report any problems that you (anyone) see in "highlighting" in any output mode (text, man, html, xml). Also update copyright to include me. Signed-off-by: -
Andy Whitcroft authored
This version brings a number of new checks, and a number of bug fixes. Of note: - better categorisation and space checks for dual use unary/binary operators - warn on deprecated use of {SPIN,RW}_LOCK_UNLOCKED - check if/for/while with trailing ';' for hanging statements - detect DOS line endings - detect redundant casts for kalloc() Andy Whitcroft (18): Version: 0.10 asmlinkage is also a storage type pull out inline specifiers allow only some operators before a unary operator parenthesised values may span line ends add additional attribute matching handle sparse annotations within pointer type space checks support alternative function definition syntax for typedefs check if/for/while with trailing ';' for hanging statements fix output format for case checks deprecate SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED allow complex macros with bracketing braces detect and report DOS line endings fastcall is a valid function attribute bracket spacing is ok for 'for' categorise operators into unary/binary/definitions add heuristic to pick up on unannotated types remove spurious warnings from cat_vet Dave Jones (1): Make checkpatch warn about pointless casting of kalloc returns. Signed-off-by: -
Mike Frysinger authored
Simply fill out the bits in checkstack.pl for Blackfin. I thought I already sent this, but I don't see it in -mm anywhere ... Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Cc: Bryan Wu <bryan.wu@analog.com> Signed-off-by:
-
- 15 Oct, 2007 3 commits
-
-
Sam Ravnborg authored
Introduce ccflags-y, asflags-y and ldflags-y so we soon can deprecate use of EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. This patch does not touch any in-tree users - thats next round. Lets get this committed first and then fix the users of the soon to be deprecated variants next. The rationale behind this change is to introduce support for makefile fragments like: ccflags-$(CONFIG_WHATEVER_DEBUG) := -DDEBUG As a replacement for the uglier: ifeq ($(CONFIG_WHATEVER_DEBUG),y) EXTRA_CFLAGS := -DDEBUG endif Signed-off-by: -
Sam Ravnborg authored
The variable CPPFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. This patch replace use of CPPFLAGS with KBUILD_CPPFLAGS all over the tree and enabling one to use: make CPPFLAGS=... to specify additional CPP commandline options. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by: -
Sam Ravnborg authored
The variable AFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. On top of that several people over time has asked for a way to pass in additional flags to gcc. This patch replace use of AFLAGS with KBUILD_AFLAGS all over the tree. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by:
-
- 14 Oct, 2007 2 commits
-
-
Sam Ravnborg authored
External modules have in a few cases modifed gcc option by modifying CFLAGS. This has never been documented and was a bad practice. With the check to use KBUILD_CFLAGS it will no longer work so we better error out and tell what was wrong as a service to the external module users. This check can be overruled if KBUILD_NOPEDANTIC is set to something. Addid this possibility may allow older external module to build without any code modifications but potentially only loosing some un-important gcc options. Signed-off-by: -
Sam Ravnborg authored
The variable CFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. On top of that several people over time has asked for a way to pass in additional flags to gcc. This patch replace use of CFLAGS with KBUILD_CFLAGS all over the tree and enabling one to use: make CFLAGS=... to specify additional gcc commandline options. One usecase is when trying to find gcc bugs but other use cases has been requested too. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k Test was simple to do a defconfig build, apply the patch and check that nothing got rebuild. Signed-off-by:
-
- 13 Oct, 2007 1 commit
-
-
Jean Delvare authored
I2C devices do not have any form of ID as PCI or USB devices have. No driver uses "MODULE_DEVICE_TABLE(i2c, ...)" because it doesn't make sense. So we can get rid of struct i2c_device_id and the associated support code. Signed-off-by:Jean Delvare <khali@linux-fr.org> Cc: Greg KH <greg@kroah.com>
-
- 12 Oct, 2007 6 commits
-
-
Kees Cook authored
Cause modpost to fail if any device id lists are incorrectly terminated, after reporting the offender. Improved reporting by akpm Signed-off-by:
Kees Cook <kees@ubuntu.com> Cc: Greg KH <greg@kroah.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Jeff Garzik <jeff@garzik.org> Cc: Ben Collins <bcollins@ubuntu.com> Cc: Michael Wu <flamingice@sourmilk.net> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Matej Laitl authored
menuconfig currently represents options implied by another option ('select' directive in Kconfig) by prefixing them with '---'. Unfortunately the same notation is used for comments. If the implied option is module capable, user can still switch between Y and M, all without any feedback until she visits option's help. (try saying M to MAC80211 and then toggling CFG80211) This patch changes notation of selected-by-another items by introducing 2 new representations for implied options: {*} or {M} for options selected by another modularized one, thus builtin or module capable, -*- or -M- for options that cannot be at the moment changed by user. The idea is to represent actual capability of the option by braces (dashes) around and to always report actual state by * or M inside. Signed-off-by:Matej Laitl <strohel@gmail.com> Acked-by:
-
Jan Beulich authored
Change kconfig behavior so that mixing bool and tristate config settings in a choice is possible and has the desired effect of offering just the tristate options individually if the choice gets set to M, and a normal boolean selection if the choice gets set to Y. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
-
Sam Ravnborg authored
These checks has been present for several kernel releases (> 5). So lets just get rid of them. With this we no longer check for use of: EXTRA_TARGETS, O_TARGET, L_TARGET, list-multi, export-objs There were three remaining in-tree users of O_TARGET in some unmaintained sh64 code - mail sent to the maintainer + list. Signed-off-by: -
Sam Ravnborg authored
EXTRA_ARFLAGS have never been used so no need to carry around on this. A google search did not reveal any external module using this either. Signed-off-by: -
Milton Miller authored
Change the invocations of make in the output directory Makefile and the main Makefile for separate object trees to pass all goals to one $(MAKE) via a new phony target "sub-make" and the existing target _all. When compiling with separate object directories, a separate make is called in the context of another directory (from the output directory the main Makefile is called, the Makefile is then restarted with current directory set to the object tree). Before this patch, when multiple make command goals are specified, each target results in a separate make invocation. With make -j, these invocations may run in parallel, resulting in multiple commands running in the same directory clobbering each others results. I did not try to address make -j for mixed dot-config and no-dot-config targets. Because the order does matter, a solution was not obvious. Perhaps a simple check for MAKEFLAGS having -j and refusing to run would be appropriate. Signed-off-by:
Milton Miller <miltonm@bga.com> Signed-off-by:
-
