Re: Linux kernel in-tree Rust support
On Sun, Jul 12, 2020 at 12:39:44PM -0700, Josh Triplett wrote: >... > Rust has hard stability guarantees when upgrading from one stable > version to the next. If code compiles with a given stable version of > Rust, it'll compile with a newer stable version of Rust. >... In librsvg, breakages with more recent Rust versions in the past year required updates of two vendored crates: https://gitlab.gnome.org/GNOME/librsvg/-/commit/de26c4d8b192ed0224e6d38f54e429838608b902 https://gitlab.gnome.org/GNOME/librsvg/-/commit/696e4a6be2aeb00ea27945f94da066757431684d For updating Rust in Debian stable for the next Firefox ESR update it would actually be useful if these violations of the "hard stability guarantee" in Rust get fixed, so that the old librsvg 2.44.10 builds again with the latest Rust. It also makes me wonder how such regressions slip into Rust releases. cu Adrian
Re: Linux kernel in-tree Rust support
On Thu, Jul 16, 2020 at 03:06:01PM +0200, Arnd Bergmann wrote: > > I would expect we'd want a fairly tight coupling between kernel > releases and minimum rust releases at first. Whatever is the latest > stable rust version during the kernel's merge window might be > assumed to be the minimum version for the life of that kernel, but > an LTS release would not suddenly start relying on features > from a newer compiler (thought it might warn about known bugs). > > This might mean that linux-next requires a beta version of rust, if > the release is expected before the merge window and it contains > an important change. I would expect this is absolutely not wanted, it would make testing recent kernels very hard. If you want to keep a tool that tightly to the kernel, please bundle it with the kernel and build it as part of the kernel build. I would suggest to start with a proper design/specification what the kernel wants to use, so that you are confident that a compiler implementing this will be sufficient for the next 5 years. As a secondary benefit, starting with a proper design often brings a better result than adding permanent features piece by piece. As a tertiary benefit, it would avoid tying the kernel to one specific compiler implementation. A compiler like mrustc or a hypothetical Rust frontend for gcc could then implement a superset of what the kernel needs. > Staying with fairly recent versions of clang > certainly helped in getting clang and the kernel to co-evolve and > get to the point we are now in using it as an alternative to gcc. The main difference is between an alternative to an existing tool, and a mandatory new tool. > While Linux used to build with 12 year old compilers (4.1 until > 2018), we now require a 6 year old gcc (4.9) or 1 year old > clang/llvm. I don't know whether these will fully converge over > time but it seems sensible that the minimum rust frontend version > we require for a new kernel release would eventually also fall > in that range, requiring a compiler that is no more than a few > years old, but not requiring the latest stable release. The correct range for a mandatory tool are the 6 to 12 years for gcc. Debian stable and Ubuntu LTS are providing (different) mechanisms for installing the kernel from the next stable/LTS release 2 years later[1] for supporting new hardware. If kernel 5.12 LTS cannot be compiled on Ubuntu 20.04 LTS with the 2019 gcc 9 there would be pain downstream. In the embedded world spreads far wider than these 3 years are common. I would currently have a real-life usecase for compiling a recent kernel with a gcc 4.0 (sic) toolchain. Properly supporting 15 year old toolchains would be painful upstream, supporting 6 year old toolchains is a reasonable compromise between not being too painful upstream while rarely causing pain downstream. What applies to gcc does also apply to other external tools used during the kernel build. > Arnd cu Adrian [1] following a new upstream kernel stable branch every 6 months (Ubuntu) or the latest upstream stable kernels (Debian) until this is reached
Re: Linux kernel in-tree Rust support
On Sun, Jul 12, 2020 at 12:39:44PM -0700, Josh Triplett wrote: > On Sun, Jul 12, 2020 at 03:31:51PM +0300, Adrian Bunk wrote: > > On Thu, Jul 09, 2020 at 11:41:47AM -0700, Nick Desaulniers wrote: > > >... > > > but also a larger question of "should we do > > > this?" or "how might we place limits on where this can be used?" > > >... > > > > I won't attend, but I do have a topic that should be covered: > > > > Firefox always depends on recent Rust, which forces distributions to > > update Rust in stable releases. > > > > As an example: > > Ubuntu LTS releases upgrade to a new Rust version every 1-2 months. > > Ubuntu 16.04 started with Rust 1.7.0 and is now at Rust 1.41.0. > > > > It would not sound good to me if security updates of distribution > > kernels might additionally end up using a different version of the > > Rust compiler - the toolchain for the kernel should be stable. > > > > Would Rust usage in the kernel require distributions to ship > > a "Rust for Firefox" and a "Rust for the kernel"? > > Rust has hard stability guarantees when upgrading from one stable > version to the next. If code compiles with a given stable version of > Rust, it'll compile with a newer stable version of Rust. Given that, a > stable distribution will just need a single sufficiently up-to-date Rust > that meets the minimum version requirements of both Firefox and Linux. >... API stability avoids problems that are visible early as build errors. Rust cannot offer a hard stability guarantee that there will never be a code generation regression on any platform. Rust gets updated frequently. Sometimes this also changes the LLVM version used by Rust. Debian stable supports targets like ARMv5 and 32bit MIPS. Distribution kernel updates are often automatically installed on user hardware. cu Adrian
Re: Linux kernel in-tree Rust support
On Thu, Jul 09, 2020 at 11:41:47AM -0700, Nick Desaulniers wrote: >... > but also a larger question of "should we do > this?" or "how might we place limits on where this can be used?" >... I won't attend, but I do have a topic that should be covered: Firefox always depends on recent Rust, which forces distributions to update Rust in stable releases. As an example: Ubuntu LTS releases upgrade to a new Rust version every 1-2 months. Ubuntu 16.04 started with Rust 1.7.0 and is now at Rust 1.41.0. It would not sound good to me if security updates of distribution kernels might additionally end up using a different version of the Rust compiler - the toolchain for the kernel should be stable. Would Rust usage in the kernel require distributions to ship a "Rust for Firefox" and a "Rust for the kernel"? > Thanks, > ~Nick Desaulniers cu Adrian
Re: Fixing Linux getrandom() in stable
On Mon, May 14, 2018 at 03:11:30AM +0100, Ben Hutchings wrote: > On Sun, 2018-05-13 at 23:48 +0300, Adrian Bunk wrote: >... > > Due to the gdm bugs mentioned above we know that there are real-life > > situations where gdm currently uses "random" data that might be > > predictable. > > > > grep tells me: > > daemon/gdm-x-session.c:auth_entry.data = gdm_generate_random_bytes > > (auth_entry.data_length, ); > > daemon/gdm-display-access-file.c:*cookie = > > gdm_generate_random_bytes (GDM_DISPLAY_ACCESS_COOKIE_SIZE, > > > > Repeat the same for every package that uses /dev/urandom. > > This is certain undesirable, but it's exploitable only by local users. > (If you let the X server listen to the network, all authentication > cookies are sent in the clear so you've already lost. If you use ssh X > forwarding, it generates a new authentication cookie for use with the X > proxy on the remote machine.) It is possible that this specific case is not a problem. There was a certain "never use /dev/random, /dev/urandom is always good enough" push that started several years before getrandom() became available, and I'd bet someone will find exploitable cases due to that somewhere. The documented behaviour is that it is safe to use /dev/urandom except during "early boot", and this is not always true in practice. >... > > The proper way forward might be to deprecate /dev/urandom and add a > > third option GRND_UNSAFE_RANDOM to getrandom() that is documented to > > never block but might return predictable data in some cases. > > This doesn't solve anything for us. (It does help with the original > problem of device nodes possibly being absent from a minimal container > or chroot.) >... I am less worried about device nodes possibly being absent, and more worried about 3 different cases splintered over 2 completely different APIs. Ignoring any security implications, "workaround by switching from getrandom() to /dev/urandom" sounds wrong since you shouldn't be forced to a different API for that - getrandom() is what people should use, therefore it should offer all 3 options. > Ben. >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Fixing Linux getrandom() in stable
On Mon, May 14, 2018 at 03:11:30AM +0100, Ben Hutchings wrote: > On Sun, 2018-05-13 at 23:48 +0300, Adrian Bunk wrote: >... > > Due to the gdm bugs mentioned above we know that there are real-life > > situations where gdm currently uses "random" data that might be > > predictable. > > > > grep tells me: > > daemon/gdm-x-session.c:auth_entry.data = gdm_generate_random_bytes > > (auth_entry.data_length, ); > > daemon/gdm-display-access-file.c:*cookie = > > gdm_generate_random_bytes (GDM_DISPLAY_ACCESS_COOKIE_SIZE, > > > > Repeat the same for every package that uses /dev/urandom. > > This is certain undesirable, but it's exploitable only by local users. > (If you let the X server listen to the network, all authentication > cookies are sent in the clear so you've already lost. If you use ssh X > forwarding, it generates a new authentication cookie for use with the X > proxy on the remote machine.) It is possible that this specific case is not a problem. There was a certain "never use /dev/random, /dev/urandom is always good enough" push that started several years before getrandom() became available, and I'd bet someone will find exploitable cases due to that somewhere. The documented behaviour is that it is safe to use /dev/urandom except during "early boot", and this is not always true in practice. >... > > The proper way forward might be to deprecate /dev/urandom and add a > > third option GRND_UNSAFE_RANDOM to getrandom() that is documented to > > never block but might return predictable data in some cases. > > This doesn't solve anything for us. (It does help with the original > problem of device nodes possibly being absent from a minimal container > or chroot.) >... I am less worried about device nodes possibly being absent, and more worried about 3 different cases splintered over 2 completely different APIs. Ignoring any security implications, "workaround by switching from getrandom() to /dev/urandom" sounds wrong since you shouldn't be forced to a different API for that - getrandom() is what people should use, therefore it should offer all 3 options. > Ben. >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Fixing Linux getrandom() in stable
On Wed, May 09, 2018 at 11:46:00PM +0100, Ben Hutchings wrote: >... > # Security flaw and initial fix > > Recently it was discovered that getrandom() could return successfully > before the RNG was really ready to produce unpredictable data. This > issue was designated as CVE-2018-1108, and was fixed in Linux 4.17-rc2 > and various stable updates. > > We fixed CVE-2018-1108 with an update to stretch last week > (DSA-4188-1). The kernel versions in wheezy and jessie do not provide > getrandom(). > > # Regression > > The version of glibc in stretch does not provide access to getrandom(), > but some packages in stable use syscall() to call it anyway, including: > > * krb5: k5_get_os_entropy() > * libbsd: arc4_random_buf(). This is used by many other packages > including libICE, and so indirectly by gnome-session. > > Following DSA-4188-1, it turned out that the RNG did not become ready > on some systems until several minutes after boot, causing severe > regressions for GNOME/gdm (#897631, #897632) and Kerberos (#897599, > #897917). We therefore reverted the fix in yesterday's update > (DSA-4196-1). > > # Options for a new fix > > It is unlikely that any further fix will be forthcoming on the kernel > side, so I believe that we need to do one of: > > 1. Add entropy to the kernel during boot; either: >a. Improve systemd-random-seed >b. Recommend use of haveged I don't see any solution above that both always works and never results in new CVEs. As an example, what happens if I debootstrap and deploy the resulting filesytem to a large number of identical embedded systems without entropy sources? As far as I can see, any solution above would either give me boot hangs or might result in nasty security issues due to the same (known) entropy being fed to /dev/random on many machines. Similar problems for cases like live CDs and installers. > 2. For each affected userland package, either: >a. Revert to using /dev/urandom I wonder whether the current issue is just the tip of the iceberg, and usage of /dev/urandom is a gazillion CVEs waiting to be reported. In that case the CVE-2018-1108 fix only revealed a long existing vulnerability in some packages that already switched to getrandom(). /dev/urandom is documented in a very misleading way, quoting random(4): When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. If this is of concern in your application, use getrandom(2) or /dev/random instead. What is the worst case for "early boot time" here? "always"? Due to the gdm bugs mentioned above we know that there are real-life situations where gdm currently uses "random" data that might be predictable. grep tells me: daemon/gdm-x-session.c:auth_entry.data = gdm_generate_random_bytes (auth_entry.data_length, ); daemon/gdm-display-access-file.c:*cookie = gdm_generate_random_bytes (GDM_DISPLAY_ACCESS_COOKIE_SIZE, Repeat the same for every package that uses /dev/urandom. >b. Tolerate a longer wait for getrandom() to return I suspect there might be no guaranteed upper bound for the waiting time. >... > The libbsd maintainer (Guillem Jover) favours option 2a. > > One of the krb5 maintainers (Benjamin Kaduk) favours option 2b, and > also proposed that systemd could provide a wait-for-rng-ready unit to > support this. I don't see any general solution that is both correct and easy. The proper way forward might be to deprecate /dev/urandom and add a third option GRND_UNSAFE_RANDOM to getrandom() that is documented to never block but might return predictable data in some cases. It would then be up to the application to decide whether predictable data is acceptable, and what to do in entropy-starved situations. Regarding the suggested wait-for-rng-ready systemd unit for others to wait on, this only makes sense for cases where "do not start at all" is the best handling for a "no entropy" situation. > Ben. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Fixing Linux getrandom() in stable
On Wed, May 09, 2018 at 11:46:00PM +0100, Ben Hutchings wrote: >... > # Security flaw and initial fix > > Recently it was discovered that getrandom() could return successfully > before the RNG was really ready to produce unpredictable data. This > issue was designated as CVE-2018-1108, and was fixed in Linux 4.17-rc2 > and various stable updates. > > We fixed CVE-2018-1108 with an update to stretch last week > (DSA-4188-1). The kernel versions in wheezy and jessie do not provide > getrandom(). > > # Regression > > The version of glibc in stretch does not provide access to getrandom(), > but some packages in stable use syscall() to call it anyway, including: > > * krb5: k5_get_os_entropy() > * libbsd: arc4_random_buf(). This is used by many other packages > including libICE, and so indirectly by gnome-session. > > Following DSA-4188-1, it turned out that the RNG did not become ready > on some systems until several minutes after boot, causing severe > regressions for GNOME/gdm (#897631, #897632) and Kerberos (#897599, > #897917). We therefore reverted the fix in yesterday's update > (DSA-4196-1). > > # Options for a new fix > > It is unlikely that any further fix will be forthcoming on the kernel > side, so I believe that we need to do one of: > > 1. Add entropy to the kernel during boot; either: >a. Improve systemd-random-seed >b. Recommend use of haveged I don't see any solution above that both always works and never results in new CVEs. As an example, what happens if I debootstrap and deploy the resulting filesytem to a large number of identical embedded systems without entropy sources? As far as I can see, any solution above would either give me boot hangs or might result in nasty security issues due to the same (known) entropy being fed to /dev/random on many machines. Similar problems for cases like live CDs and installers. > 2. For each affected userland package, either: >a. Revert to using /dev/urandom I wonder whether the current issue is just the tip of the iceberg, and usage of /dev/urandom is a gazillion CVEs waiting to be reported. In that case the CVE-2018-1108 fix only revealed a long existing vulnerability in some packages that already switched to getrandom(). /dev/urandom is documented in a very misleading way, quoting random(4): When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. If this is of concern in your application, use getrandom(2) or /dev/random instead. What is the worst case for "early boot time" here? "always"? Due to the gdm bugs mentioned above we know that there are real-life situations where gdm currently uses "random" data that might be predictable. grep tells me: daemon/gdm-x-session.c:auth_entry.data = gdm_generate_random_bytes (auth_entry.data_length, ); daemon/gdm-display-access-file.c:*cookie = gdm_generate_random_bytes (GDM_DISPLAY_ACCESS_COOKIE_SIZE, Repeat the same for every package that uses /dev/urandom. >b. Tolerate a longer wait for getrandom() to return I suspect there might be no guaranteed upper bound for the waiting time. >... > The libbsd maintainer (Guillem Jover) favours option 2a. > > One of the krb5 maintainers (Benjamin Kaduk) favours option 2b, and > also proposed that systemd could provide a wait-for-rng-ready unit to > support this. I don't see any general solution that is both correct and easy. The proper way forward might be to deprecate /dev/urandom and add a third option GRND_UNSAFE_RANDOM to getrandom() that is documented to never block but might return predictable data in some cases. It would then be up to the application to decide whether predictable data is acceptable, and what to do in entropy-starved situations. Regarding the suggested wait-for-rng-ready systemd unit for others to wait on, this only makes sense for cases where "do not start at all" is the best handling for a "no entropy" situation. > Ben. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [PATCH v6 08/13] block: Add an explicit bio flag for bios that own their bvec
On Wed, Aug 22, 2012 at 12:22:41PM -0700, Kent Overstreet wrote:
> On Wed, Aug 22, 2012 at 08:43:52PM +0300, Adrian Bunk wrote:
> > On Wed, Aug 22, 2012 at 10:04:05AM -0700, Kent Overstreet wrote:
> > >...
> > > --- a/include/linux/blk_types.h
> > > +++ b/include/linux/blk_types.h
> > > @@ -117,6 +117,7 @@ struct bio {
> > > * BIO_POOL_IDX()
> > > */
> > > #define BIO_RESET_BITS 12
> > > +#define BIO_OWNS_VEC 12 /* bio_free() should free bvec */
> > >...
> >
> > This doesn't look right.
>
> Well, the first 12 bits are reset, so bit 12 will get preserved... I
> guess it's unusual to have a duplicated enum value like that but
> BIO_RESET_BITS is just a marker, not a real bit.
Wouldn't a BIO_RESET_MASK be better than BIO_RESET_BITS?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 08/13] block: Add an explicit bio flag for bios that own their bvec
On Wed, Aug 22, 2012 at 10:04:05AM -0700, Kent Overstreet wrote:
>...
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -117,6 +117,7 @@ struct bio {
> * BIO_POOL_IDX()
> */
> #define BIO_RESET_BITS 12
> +#define BIO_OWNS_VEC 12 /* bio_free() should free bvec */
>...
This doesn't look right.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 08/13] block: Add an explicit bio flag for bios that own their bvec
On Wed, Aug 22, 2012 at 10:04:05AM -0700, Kent Overstreet wrote:
...
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -117,6 +117,7 @@ struct bio {
* BIO_POOL_IDX()
*/
#define BIO_RESET_BITS 12
+#define BIO_OWNS_VEC 12 /* bio_free() should free bvec */
...
This doesn't look right.
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 08/13] block: Add an explicit bio flag for bios that own their bvec
On Wed, Aug 22, 2012 at 12:22:41PM -0700, Kent Overstreet wrote:
On Wed, Aug 22, 2012 at 08:43:52PM +0300, Adrian Bunk wrote:
On Wed, Aug 22, 2012 at 10:04:05AM -0700, Kent Overstreet wrote:
...
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -117,6 +117,7 @@ struct bio {
* BIO_POOL_IDX()
*/
#define BIO_RESET_BITS 12
+#define BIO_OWNS_VEC 12 /* bio_free() should free bvec */
...
This doesn't look right.
Well, the first 12 bits are reset, so bit 12 will get preserved... I
guess it's unusual to have a duplicated enum value like that but
BIO_RESET_BITS is just a marker, not a real bit.
Wouldn't a BIO_RESET_MASK be better than BIO_RESET_BITS?
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 08:58:02PM +0100, Sam Ravnborg wrote: > > > > Please name the tools that are that broken that they wouldn't apply this > > patch correctly and don't claim my patch was broken (or shut up). > > It is only one or two weeks ago we ended up with a zero size file > in the kernel tree - and I do not know why. > I just wanted to make sure we did not see this happen again. Then research first what went wrong in this case. But it is not funny when you wrongly accuse me publically of sending patches that would remove files in an incorrect way. > Sam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] m32r: use KBUILD_DEFCONFIG
With using KBUILD_DEFCONFIG we don't have to ship a second copy of m32700ut.smp_defconfig Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- arch/m32r/Makefile |2 arch/m32r/defconfig | 863 2 files changed, 2 insertions(+), 863 deletions(-) c1797789816e8d79133d63da3578705f47cedbd3 diff --git a/arch/m32r/Makefile b/arch/m32r/Makefile index 4072a07..469766b 100644 --- a/arch/m32r/Makefile +++ b/arch/m32r/Makefile @@ -5,6 +5,8 @@ # architecture-specific flags and dependencies. # +KBUILD_DEFCONFIG := m32700ut.smp_defconfig + LDFLAGS:= OBJCOPYFLAGS := -O binary -R .note -R .comment -S LDFLAGS_vmlinux:= diff --git a/arch/m32r/defconfig b/arch/m32r/defconfig deleted file mode 100644 index af3b981..000 --- a/arch/m32r/defconfig +++ /dev/null @@ -1,863 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc1 -# Wed Aug 1 17:22:35 2007 -# -CONFIG_M32R=y -CONFIG_GENERIC_ISA_DMA=y -CONFIG_ZONE_DMA=y -CONFIG_GENERIC_HARDIRQS=y -CONFIG_GENERIC_IRQ_PROBE=y -CONFIG_NO_IOPORT=y -CONFIG_NO_DMA=y -CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" - -# -# Code maturity level options -# -CONFIG_EXPERIMENTAL=y -CONFIG_LOCK_KERNEL=y -CONFIG_INIT_ENV_ARG_LIMIT=32 - -# -# General setup -# -CONFIG_LOCALVERSION="" -CONFIG_LOCALVERSION_AUTO=y -CONFIG_SWAP=y -CONFIG_SYSVIPC=y -CONFIG_SYSVIPC_SYSCTL=y -# CONFIG_POSIX_MQUEUE is not set -CONFIG_BSD_PROCESS_ACCT=y -# CONFIG_BSD_PROCESS_ACCT_V3 is not set -# CONFIG_TASKSTATS is not set -# CONFIG_USER_NS is not set -# CONFIG_AUDIT is not set -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=15 -# CONFIG_CPUSETS is not set -CONFIG_SYSFS_DEPRECATED=y -# CONFIG_RELAY is not set -# CONFIG_BLK_DEV_INITRD is not set -# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set -CONFIG_SYSCTL=y -CONFIG_EMBEDDED=y -CONFIG_SYSCTL_SYSCALL=y -# CONFIG_KALLSYMS is not set -CONFIG_HOTPLUG=y -CONFIG_PRINTK=y -CONFIG_BUG=y -CONFIG_ELF_CORE=y -CONFIG_BASE_FULL=y -# CONFIG_FUTEX is not set -CONFIG_ANON_INODES=y -# CONFIG_EPOLL is not set -CONFIG_SIGNALFD=y -CONFIG_TIMERFD=y -CONFIG_EVENTFD=y -CONFIG_SHMEM=y -CONFIG_VM_EVENT_COUNTERS=y -CONFIG_SLAB=y -# CONFIG_SLUB is not set -# CONFIG_SLOB is not set -# CONFIG_TINY_SHMEM is not set -CONFIG_BASE_SMALL=0 -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_MODULE_FORCE_UNLOAD is not set -# CONFIG_MODVERSIONS is not set -# CONFIG_MODULE_SRCVERSION_ALL is not set -CONFIG_KMOD=y -CONFIG_STOP_MACHINE=y -CONFIG_BLOCK=y -# CONFIG_LBD is not set -# CONFIG_BLK_DEV_IO_TRACE is not set -# CONFIG_LSF is not set -# CONFIG_BLK_DEV_BSG is not set - -# -# IO Schedulers -# -CONFIG_IOSCHED_NOOP=y -# CONFIG_IOSCHED_AS is not set -CONFIG_IOSCHED_DEADLINE=y -CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_AS is not set -# CONFIG_DEFAULT_DEADLINE is not set -CONFIG_DEFAULT_CFQ=y -# CONFIG_DEFAULT_NOOP is not set -CONFIG_DEFAULT_IOSCHED="cfq" - -# -# Processor type and features -# -# CONFIG_PLAT_MAPPI is not set -# CONFIG_PLAT_USRV is not set -CONFIG_PLAT_M32700UT=y -# CONFIG_PLAT_OPSPUT is not set -# CONFIG_PLAT_OAKS32R is not set -# CONFIG_PLAT_MAPPI2 is not set -# CONFIG_PLAT_MAPPI3 is not set -# CONFIG_PLAT_M32104UT is not set -CONFIG_CHIP_M32700=y -# CONFIG_CHIP_M32102 is not set -# CONFIG_CHIP_M32104 is not set -# CONFIG_CHIP_VDEC2 is not set -# CONFIG_CHIP_OPSP is not set -CONFIG_MMU=y -CONFIG_TLB_ENTRIES=32 -CONFIG_ISA_M32R2=y -CONFIG_ISA_DSP_LEVEL2=y -CONFIG_ISA_DUAL_ISSUE=y -CONFIG_BUS_CLOCK=5000 -CONFIG_TIMER_DIVIDE=128 -# CONFIG_CPU_LITTLE_ENDIAN is not set -CONFIG_MEMORY_START=0x0800 -CONFIG_MEMORY_SIZE=0x0100 -CONFIG_NOHIGHMEM=y -CONFIG_ARCH_DISCONTIGMEM_ENABLE=y -CONFIG_SELECT_MEMORY_MODEL=y -# CONFIG_FLATMEM_MANUAL is not set -CONFIG_DISCONTIGMEM_MANUAL=y -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_DISCONTIGMEM=y -CONFIG_FLAT_NODE_MEM_MAP=y -CONFIG_NEED_MULTIPLE_NODES=y -# CONFIG_SPARSEMEM_STATIC is not set -CONFIG_SPLIT_PTLOCK_CPUS=4 -# CONFIG_RESOURCES_64BIT is not set -CONFIG_ZONE_DMA_FLAG=1 -CONFIG_BOUNCE=y -CONFIG_VIRT_TO_BUS=y -CONFIG_IRAM_START=0x00f0 -CONFIG_IRAM_SIZE=0x0008 -CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set -CONFIG_GENERIC_FIND_NEXT_BIT=y -CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y -CONFIG_PREEMPT=y -CONFIG_SMP=y -# CONFIG_CHIP_M32700_TS1 is not set -CONFIG_NR_CPUS=2 -CONFIG_NODES_SHIFT=1 - -# -# Bus options (PCI, PCMCIA, EISA, MCA, ISA) -# -# CONFIG_ARCH_SUPPORTS_MSI is not set -# CONFIG_ISA is not set - -# -# PCCARD (PCMCIA/CardBus) support -# -# CONFIG_PCCARD is not set - -# -# Executable file formats -# -CONFIG_BINFMT_ELF=y -# CONFIG_BINFMT_MISC is not set - -# -# Networking -# -CONFIG_NET=y - -# -# Networking options -# -CONFIG_PACKET=y -# CONFIG_PACKET_MMAP is not set -CONFIG_UNIX=
[2.6 patch] m68k: use KBUILD_DEFCONFIG
The default defconfig should be one from arch/m68k/configs/ arch/m68k/defconfig was not exactly identical to amiga_defconfig but also considering how long they have been without any update that doesn't seem to have been on purpose. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- arch/m68k/Makefile |2 arch/m68k/defconfig | 657 2 files changed, 2 insertions(+), 657 deletions(-) f52a66f85069cc79c30b0c9520713bbba6cfc20d diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 2cba605..b15173f 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -13,6 +13,8 @@ # Copyright (C) 1994 by Hamish Macdonald # +KBUILD_DEFCONFIG := amiga_defconfig + # override top level makefile AS += -m68020 LDFLAGS := -m m68kelf diff --git a/arch/m68k/defconfig b/arch/m68k/defconfig deleted file mode 100644 index 7d935e4..000 --- a/arch/m68k/defconfig +++ /dev/null @@ -1,657 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.12-rc6-m68k -# Tue Jun 7 20:34:17 2005 -# -CONFIG_M68K=y -CONFIG_MMU=y -CONFIG_UID16=y -CONFIG_RWSEM_GENERIC_SPINLOCK=y -CONFIG_GENERIC_CALIBRATE_DELAY=y - -# -# Code maturity level options -# -CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y -CONFIG_BROKEN_ON_SMP=y -CONFIG_INIT_ENV_ARG_LIMIT=32 - -# -# General setup -# -CONFIG_LOCALVERSION="" -CONFIG_SWAP=y -CONFIG_SYSVIPC=y -# CONFIG_POSIX_MQUEUE is not set -# CONFIG_BSD_PROCESS_ACCT is not set -CONFIG_SYSCTL=y -# CONFIG_AUDIT is not set -# CONFIG_HOTPLUG is not set -CONFIG_KOBJECT_UEVENT=y -# CONFIG_IKCONFIG is not set -# CONFIG_EMBEDDED is not set -CONFIG_KALLSYMS=y -# CONFIG_KALLSYMS_EXTRA_PASS is not set -CONFIG_PRINTK=y -CONFIG_BUG=y -CONFIG_BASE_FULL=y -CONFIG_FUTEX=y -CONFIG_EPOLL=y -CONFIG_SHMEM=y -CONFIG_CC_ALIGN_FUNCTIONS=0 -CONFIG_CC_ALIGN_LABELS=0 -CONFIG_CC_ALIGN_LOOPS=0 -CONFIG_CC_ALIGN_JUMPS=0 -# CONFIG_TINY_SHMEM is not set -CONFIG_BASE_SMALL=0 - -# -# Loadable module support -# -# CONFIG_MODULES is not set - -# -# Platform dependent setup -# -# CONFIG_SUN3 is not set -CONFIG_AMIGA=y -# CONFIG_ATARI is not set -# CONFIG_MAC is not set -# CONFIG_APOLLO is not set -# CONFIG_VME is not set -# CONFIG_HP300 is not set -# CONFIG_SUN3X is not set -# CONFIG_Q40 is not set - -# -# Processor type -# -CONFIG_M68020=y -CONFIG_M68030=y -CONFIG_M68040=y -# CONFIG_M68060 is not set -CONFIG_MMU_MOTOROLA=y -# CONFIG_M68KFPU_EMU is not set -# CONFIG_ADVANCED is not set - -# -# General setup -# -CONFIG_BINFMT_ELF=y -CONFIG_BINFMT_AOUT=y -# CONFIG_BINFMT_MISC is not set -CONFIG_ZORRO=y -# CONFIG_AMIGA_PCMCIA is not set -# CONFIG_HEARTBEAT is not set -CONFIG_PROC_HARDWARE=y -# CONFIG_ZORRO_NAMES is not set - -# -# Device Drivers -# - -# -# Generic Driver Options -# -CONFIG_STANDALONE=y -CONFIG_PREVENT_FIRMWARE_BUILD=y -# CONFIG_FW_LOADER is not set - -# -# Memory Technology Devices (MTD) -# -# CONFIG_MTD is not set - -# -# Parallel port support -# -# CONFIG_PARPORT is not set - -# -# Plug and Play support -# - -# -# Block devices -# -CONFIG_AMIGA_FLOPPY=y -# CONFIG_AMIGA_Z2RAM is not set -# CONFIG_BLK_DEV_COW_COMMON is not set -# CONFIG_BLK_DEV_LOOP is not set -# CONFIG_BLK_DEV_NBD is not set -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_COUNT=16 -CONFIG_BLK_DEV_RAM_SIZE=4096 -CONFIG_BLK_DEV_INITRD=y -CONFIG_INITRAMFS_SOURCE="" -CONFIG_CDROM_PKTCDVD=y -CONFIG_CDROM_PKTCDVD_BUFFERS=8 -# CONFIG_CDROM_PKTCDVD_WCACHE is not set - -# -# IO Schedulers -# -CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y -CONFIG_IOSCHED_DEADLINE=y -CONFIG_IOSCHED_CFQ=y -# CONFIG_ATA_OVER_ETH is not set - -# -# ATA/ATAPI/MFM/RLL support -# -# CONFIG_IDE is not set - -# -# SCSI device support -# -CONFIG_SCSI=y -CONFIG_SCSI_PROC_FS=y - -# -# SCSI support type (disk, tape, CD-ROM) -# -CONFIG_BLK_DEV_SD=y -CONFIG_CHR_DEV_ST=y -# CONFIG_CHR_DEV_OSST is not set -CONFIG_BLK_DEV_SR=y -# CONFIG_BLK_DEV_SR_VENDOR is not set -# CONFIG_CHR_DEV_SG is not set - -# -# Some SCSI devices (e.g. CD jukebox) support multiple LUNs -# -# CONFIG_SCSI_MULTI_LUN is not set -CONFIG_SCSI_CONSTANTS=y -# CONFIG_SCSI_LOGGING is not set - -# -# SCSI Transport Attributes -# -# CONFIG_SCSI_SPI_ATTRS is not set -# CONFIG_SCSI_FC_ATTRS is not set -# CONFIG_SCSI_ISCSI_ATTRS is not set - -# -# SCSI low-level drivers -# -# CONFIG_SCSI_SATA is not set -# CONFIG_SCSI_DEBUG is not set -CONFIG_A3000_SCSI=y -CONFIG_A2091_SCSI=y -CONFIG_GVP11_SCSI=y -# CONFIG_CYBERSTORM_SCSI is not set -# CONFIG_CYBERSTORMII_SCSI is not set -# CONFIG_BLZ2060_SCSI is not set -# CONFIG_BLZ1230_SCSI is not set -# CONFIG_FASTLANE_SCSI is not set -# CONFIG_OKTAGON_SCSI is not set - -# -# Multi-device support (RAID and LVM) -# -# CONFIG_MD is not set - -# -# Fusion MPT device support -# - -# -# IEEE 1394 (FireWire) support -# - -# -# I2O device support -# - -# -# Networking support -# -CONFIG_NET=y - -# -# Networking options -# -CONFIG_PACKET=y -# CONFIG_PACKET_MMAP is not set -CONFIG_UNIX=y -# CONFIG_NET_KEY
[2.6 patch] mips: use KBUILD_DEFCONFIG
With KBUILD_DEFCONFIG we don't have to ship a second copy of ip22_defconfig Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- arch/mips/Makefile |2 arch/mips/defconfig | 1158 2 files changed, 2 insertions(+), 1158 deletions(-) 57da2fa4b7e8c035c8317e8796ca6d2ea17c1d1f diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 001c017..93ef27b 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -12,6 +12,8 @@ # for "archclean" cleaning up for this architecture. # +KBUILD_DEFCONFIG := ip22_defconfig + cflags-y := # diff --git a/arch/mips/defconfig b/arch/mips/defconfig deleted file mode 100644 index 4f5e56c..000 --- a/arch/mips/defconfig +++ /dev/null @@ -1,1158 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc2 -# Tue Aug 7 12:39:49 2007 -# -CONFIG_MIPS=y - -# -# Machine selection -# -CONFIG_ZONE_DMA=y -# CONFIG_MACH_ALCHEMY is not set -# CONFIG_BASLER_EXCITE is not set -# CONFIG_MIPS_COBALT is not set -# CONFIG_MACH_DECSTATION is not set -# CONFIG_MACH_JAZZ is not set -# CONFIG_LEMOTE_FULONG is not set -# CONFIG_MIPS_ATLAS is not set -# CONFIG_MIPS_MALTA is not set -# CONFIG_MIPS_SEAD is not set -# CONFIG_MIPS_SIM is not set -# CONFIG_MARKEINS is not set -# CONFIG_MACH_VR41XX is not set -# CONFIG_PNX8550_JBS is not set -# CONFIG_PNX8550_STB810 is not set -# CONFIG_PMC_MSP is not set -# CONFIG_PMC_YOSEMITE is not set -CONFIG_SGI_IP22=y -# CONFIG_SGI_IP27 is not set -# CONFIG_SGI_IP32 is not set -# CONFIG_SIBYTE_CRHINE is not set -# CONFIG_SIBYTE_CARMEL is not set -# CONFIG_SIBYTE_CRHONE is not set -# CONFIG_SIBYTE_RHONE is not set -# CONFIG_SIBYTE_SWARM is not set -# CONFIG_SIBYTE_LITTLESUR is not set -# CONFIG_SIBYTE_SENTOSA is not set -# CONFIG_SIBYTE_BIGSUR is not set -# CONFIG_SNI_RM is not set -# CONFIG_TOSHIBA_JMR3927 is not set -# CONFIG_TOSHIBA_RBTX4927 is not set -# CONFIG_TOSHIBA_RBTX4938 is not set -# CONFIG_WR_PPMC is not set -CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set -CONFIG_GENERIC_FIND_NEXT_BIT=y -CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_GENERIC_TIME=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y -# CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ is not set -CONFIG_ARC=y -CONFIG_DMA_NONCOHERENT=y -CONFIG_DMA_NEED_PCI_MAP_STATE=y -CONFIG_EARLY_PRINTK=y -CONFIG_SYS_HAS_EARLY_PRINTK=y -# CONFIG_NO_IOPORT is not set -CONFIG_GENERIC_ISA_DMA_SUPPORT_BROKEN=y -CONFIG_CPU_BIG_ENDIAN=y -# CONFIG_CPU_LITTLE_ENDIAN is not set -CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y -CONFIG_IRQ_CPU=y -CONFIG_SWAP_IO_SPACE=y -CONFIG_ARC32=y -CONFIG_BOOT_ELF32=y -CONFIG_MIPS_L1_CACHE_SHIFT=5 -CONFIG_ARC_CONSOLE=y -CONFIG_ARC_PROMLIB=y - -# -# CPU selection -# -# CONFIG_CPU_LOONGSON2 is not set -# CONFIG_CPU_MIPS32_R1 is not set -# CONFIG_CPU_MIPS32_R2 is not set -# CONFIG_CPU_MIPS64_R1 is not set -# CONFIG_CPU_MIPS64_R2 is not set -# CONFIG_CPU_R3000 is not set -# CONFIG_CPU_TX39XX is not set -# CONFIG_CPU_VR41XX is not set -# CONFIG_CPU_R4300 is not set -# CONFIG_CPU_R4X00 is not set -# CONFIG_CPU_TX49XX is not set -CONFIG_CPU_R5000=y -# CONFIG_CPU_R5432 is not set -# CONFIG_CPU_R6000 is not set -# CONFIG_CPU_NEVADA is not set -# CONFIG_CPU_R8000 is not set -# CONFIG_CPU_R1 is not set -# CONFIG_CPU_RM7000 is not set -# CONFIG_CPU_RM9000 is not set -# CONFIG_CPU_SB1 is not set -CONFIG_SYS_HAS_CPU_R4X00=y -CONFIG_SYS_HAS_CPU_R5000=y -CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y -CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y - -# -# Kernel type -# -CONFIG_32BIT=y -# CONFIG_64BIT is not set -CONFIG_PAGE_SIZE_4KB=y -# CONFIG_PAGE_SIZE_8KB is not set -# CONFIG_PAGE_SIZE_16KB is not set -# CONFIG_PAGE_SIZE_64KB is not set -CONFIG_BOARD_SCACHE=y -CONFIG_IP22_CPU_SCACHE=y -CONFIG_MIPS_MT_DISABLED=y -# CONFIG_MIPS_MT_SMP is not set -# CONFIG_MIPS_MT_SMTC is not set -CONFIG_CPU_HAS_LLSC=y -CONFIG_CPU_HAS_SYNC=y -CONFIG_GENERIC_HARDIRQS=y -CONFIG_GENERIC_IRQ_PROBE=y -CONFIG_ARCH_FLATMEM_ENABLE=y -CONFIG_SELECT_MEMORY_MODEL=y -CONFIG_FLATMEM_MANUAL=y -# CONFIG_DISCONTIGMEM_MANUAL is not set -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_FLATMEM=y -CONFIG_FLAT_NODE_MEM_MAP=y -# CONFIG_SPARSEMEM_STATIC is not set -CONFIG_SPLIT_PTLOCK_CPUS=4 -# CONFIG_RESOURCES_64BIT is not set -CONFIG_ZONE_DMA_FLAG=1 -CONFIG_BOUNCE=y -CONFIG_VIRT_TO_BUS=y -# CONFIG_HZ_48 is not set -# CONFIG_HZ_100 is not set -# CONFIG_HZ_128 is not set -# CONFIG_HZ_250 is not set -# CONFIG_HZ_256 is not set -CONFIG_HZ_1000=y -# CONFIG_HZ_1024 is not set -CONFIG_SYS_SUPPORTS_ARBIT_HZ=y -CONFIG_HZ=1000 -# CONFIG_PREEMPT_NONE is not set -CONFIG_PREEMPT_VOLUNTARY=y -# CONFIG_PREEMPT is not set -# CONFIG_KEXEC is not set -CONFIG_SECCOMP=y -CONFIG_LOCKDEP_SUPPORT=y -CONFIG_STACKTRACE_SUPPORT=y -CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" - -# -# General setup -# -CONFIG_EXPERIMENTAL
Re: [2.6 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 08:44:53PM +0100, Sam Ravnborg wrote: > On Tue, Feb 26, 2008 at 07:04:02PM +0100, Jesper Nilsson wrote: > > On Tue, Feb 26, 2008 at 07:47:03PM +0200, Adrian Bunk wrote: > > > This patch moves the cris defconfigs to arch/cris/configs/ where they > > > belong. > > > > > > As a side effect they can now be used directly through e.g. > > > make ARCH=cris artpec_3_defconfig > > > > > > The default defconfig is set through KBUILD_DEFCONFIG. > > > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > > > > Patch updated after I discovered an additional defconfig in > > > arch/cris/arch-v10/defconfig > > > > That could probably have been nuked, it's ancient. > > > > I'll put this in my queue. Thanks! > If you blindly apply this patch then make sure you do not end > up with zero size files. They are disliked by the kerne and > make distclean will delete them - and git becomes unhappy. At least GNU patch will correctly remove the files with my patch. Please name the tools that are that broken that they wouldn't apply this patch correctly and don't claim my patch was broken (or shut up). > Sam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
On Tue, Feb 26, 2008 at 11:48:29PM +0530, Kamalesh Babulal wrote:
> Adrian Bunk wrote:
> > On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
> >> Hi,
> >>
> >> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config
> >> option,
> >> the .config has been attached.
> >> ...
> >
> > Builds fine here.
> >
> > Local problem (e.g. disk full) on your machine?
> >
> > cu
> > Adrian
> >
> Hi Adrain,
Hi Kamalseh, ;)
> It Builds fine on another powerpc box with the same .config file, the problem
> seems to be with the gcc
> on that box, the reported build failure might have been the side effect of
> the same.
>
>
> drivers/md/raid6int8.c: In function `raid6_int8_gen_syndrome':
> drivers/md/raid6int8.c:185: error: unable to find a register to spill in
> class `FLOAT_REGS'
> drivers/md/raid6int8.c:185: error: this is the insn:
> (insn:HI 619 799 638 4 drivers/md/raid6int8.c:168 (set (mem:DI (plus:DI
> (reg/v/f:DI 122 [ p ])
> (reg/v:DI 66 ctr [orig:124 d ] [124])) [0 S8 A64])
> (reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
> (expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
> (nil)))
> drivers/md/raid6int8.c:185: confused by earlier errors, bailing out
> make[2]: *** [drivers/md/raid6int8.o] Error 1
> make[1]: *** [drivers/md] Error 2
> make: *** [drivers] Error 2
>
> # gcc --version
> gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
this means your quite old vendor gcc has a bug.
> Thanks & Regards,
> Kamalesh Babulal,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
h8300 drivers/serial/sh-sci.c compile error
Commit e108b2ca2349f510ce7d7f910eda89f71d710d84 broke the compilation of drivers/serial/sh-sci.c on h8300: <-- snip --> ... CC drivers/serial/sh-sci.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/serial/sh-sci.c:57:21: error: asm/sci.h: No such file or directory ... make[3]: *** [drivers/serial/sh-sci.o] Error 1 <-- snip --> cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.25 patch] drivers/crypto/hifn_795x.c: fix 64bit division
On Tue, Feb 26, 2008 at 01:21:00PM +0100, Martin Michlmayr wrote: > With 2.6.25-rc3 and a config file with > > CONFIG_CRYPTO_DEV_HIFN_795X=m > CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y > > I get the following build error on at least ARM and MIPS: > > Building modules, stage 2. > MODPOST 759 modules > ERROR: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined! Fix below. > Martin Michlmayr cu Adrian <-- snip --> Using ndelay() with a 64bit variable as parameter can result in build errors like the following on some 32bit systems when it results in a 64bit division: <-- snip --> ... MODPOST 759 modules ERROR: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined! <-- snip --> Reported by Martin Michlmayr. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- 40b45041ddc587c20b872a86a6a36952c28b02c7 diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c index 3110bf7..b1541c6 100644 --- a/drivers/crypto/hifn_795x.c +++ b/drivers/crypto/hifn_795x.c @@ -807,7 +807,7 @@ static int hifn_rng_data_present(struct hwrng *rng, int wait) return 1; if (!wait) return 0; - ndelay(nsec); + ndelay((u32)nsec); return 1; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote: > Hi, > > The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option, > the .config has been attached. >... Builds fine here. Local problem (e.g. disk full) on your machine? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Compress kernel modules on installation.
On Tue, Feb 26, 2008 at 11:22:03AM +0100, Willy Tarreau wrote: > On Tue, Feb 26, 2008 at 11:14:55AM +0200, Adrian Bunk wrote: > > On Mon, Feb 25, 2008 at 11:21:38PM +0100, Willy Tarreau wrote: >... > > > Have you tried keeping the module names intact (.ko, not .ko.gz) ? > > > It's what I was doing with modutils in 2.4 and what I'm still doing > > > with module-init-tools in 2.6. While I don't particularly use mkinitrd, > > > I think that keeping the name intact is preferable and should help. > > > > How would you see if, and if yes with what program, a module was > > compressed if the name is kept intact? > > depmod/modinfo/insmod/modprobe already know it. And quite honnestly, > I don't know about any other program which really needs to process > those files once installed. Well, maybe ksymoops, but I'd have to > check, as I don't recall having ever been annoyed with this. >... depmod/modinfo/insmod/modprobe know only if you compile module-init-tools with zlib support. And what about the busybox versions? A different name would e.g.: - easily allow proper error handling if the userspace modules program doesn't support the compression used - better scale to support additional compressions - give the user a hint what is happening and what might be the problem when anythig goes wrong > Regards, > Willy cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is "pci_find_subsys" safe to remove?
On Mon, Feb 25, 2008 at 05:15:25PM -0500, Robert P. J. Day wrote: > > it's not just that it falls under the category of PCI "legacy" but, > if you look in drivers/pci/search.c near the bottom: > > ... > #ifdef CONFIG_PCI_LEGACY > EXPORT_SYMBOL(pci_find_device); > EXPORT_SYMBOL(pci_find_slot); > #endif /* CONFIG_PCI_LEGACY */ > ... > > that symbol is not being exported even *if* you select PCI_LEGACY. > i'm guessing that's an oversight but it would certainly suggest that > no one can possibly be using it, no? It's used by pci_find_device(). > rday cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Compress kernel modules on installation.
On Mon, Feb 25, 2008 at 11:21:38PM +0100, Willy Tarreau wrote: > On Mon, Feb 25, 2008 at 09:42:09PM +, Steve Brokenshire wrote: > > Hi, > > > > (I've sent this to the linux-kbuild and linux-kernel lists as this > > patch modifies the Makefile.modinst file. I also don't subscribe to the > > linux-kbuild and linux-kernel mailing lists so can I have any replies > > CC'ed to me please) > > > > This patch allows kernel modules to be compressed when 'make > > modules_install' is run after being copied to > > the /lib/module//<...> directory which is useful if you have > > module-init-tools installed with --enable-zlib. This patch adds an > > option (MODULE_COMPRESS) to the kernel configuration file (specifically > > init/Kconfig) so that the kernel modules will compressed if > > MODULE_COMPRESS is set. > > > > When MODULE_COMPRESS is set the output of 'make modules_install' will > > go as the following: > > > > INSTALL drivers/fs/xfs/xfs.ko > > COMPRESS drivers/fs/xfs/xfs.ko > > INSTALL drivers/fs/fat/fat.ko > > COMPRESS drivers/fs/fat/fat.ko > > ... > > > > I've tested my patch on kernel versions 2.6.24.2, 2.6.24-git12, 2.6.23.14 > > and > > 2.6.19 and they compile, install and compress into the respective > > module directories without any errors. > > > > I've also tested this with the uvcvideo (linux-uvc) kernel module (from > > the SVN branch and with kernel versions 2.6.24.2, 2.6.24-git12, 2.6.23.14 > > and > > 2.6.19) as that uses Kbuild properly when installing the module and > > after installing the uvcvideo the module is then compressed. > > Unfortunately, I couldn't find any other kernel modules which used the > > Kbuild system for installing their kernel modules. :( > > > > I've included include/config/auto.conf in Makefile.modinst so that it > > can check if MODULE_COMPRESS is set when installing the kernel modules. > > > > Unfortunately when I ran mkinitrd (CentOS version) to create the initrd > > image to go with the kernel, I get errors saying that certain kernel > > modules don't exist despite the fact they do actually exist. When I > > pass --allow-missing to mkinitrd, it seems to go fine but when booting > > up with the system with the new initrd image I get error messages > > saying that the modules don't exist. > > > > A workaround is to compile the modules, don't have MODULE_COMPRESS set > > in .config, install the modules, run mkinitrd and copy it to /boot, set > > MODULE_COMPRESS in .config and then install the modules again but > > compressed. > > > > That's about it really. The only showstopper I feel is mkinitrd not > > working properly with the compressed kernel modules. > > Have you tried keeping the module names intact (.ko, not .ko.gz) ? > It's what I was doing with modutils in 2.4 and what I'm still doing > with module-init-tools in 2.6. While I don't particularly use mkinitrd, > I think that keeping the name intact is preferable and should help. How would you see if, and if yes with what program, a module was compressed if the name is kept intact? I'd assume stuff like mkinitrd simply also needs to gain knowledge about compressed modules. > Regards, > Willy cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Compress kernel modules on installation.
On Mon, Feb 25, 2008 at 11:21:38PM +0100, Willy Tarreau wrote: On Mon, Feb 25, 2008 at 09:42:09PM +, Steve Brokenshire wrote: Hi, (I've sent this to the linux-kbuild and linux-kernel lists as this patch modifies the Makefile.modinst file. I also don't subscribe to the linux-kbuild and linux-kernel mailing lists so can I have any replies CC'ed to me please) This patch allows kernel modules to be compressed when 'make modules_install' is run after being copied to the /lib/module/version/... directory which is useful if you have module-init-tools installed with --enable-zlib. This patch adds an option (MODULE_COMPRESS) to the kernel configuration file (specifically init/Kconfig) so that the kernel modules will compressed if MODULE_COMPRESS is set. When MODULE_COMPRESS is set the output of 'make modules_install' will go as the following: INSTALL drivers/fs/xfs/xfs.ko COMPRESS drivers/fs/xfs/xfs.ko INSTALL drivers/fs/fat/fat.ko COMPRESS drivers/fs/fat/fat.ko ... I've tested my patch on kernel versions 2.6.24.2, 2.6.24-git12, 2.6.23.14 and 2.6.19 and they compile, install and compress into the respective module directories without any errors. I've also tested this with the uvcvideo (linux-uvc) kernel module (from the SVN branch and with kernel versions 2.6.24.2, 2.6.24-git12, 2.6.23.14 and 2.6.19) as that uses Kbuild properly when installing the module and after installing the uvcvideo the module is then compressed. Unfortunately, I couldn't find any other kernel modules which used the Kbuild system for installing their kernel modules. :( I've included include/config/auto.conf in Makefile.modinst so that it can check if MODULE_COMPRESS is set when installing the kernel modules. Unfortunately when I ran mkinitrd (CentOS version) to create the initrd image to go with the kernel, I get errors saying that certain kernel modules don't exist despite the fact they do actually exist. When I pass --allow-missing to mkinitrd, it seems to go fine but when booting up with the system with the new initrd image I get error messages saying that the modules don't exist. A workaround is to compile the modules, don't have MODULE_COMPRESS set in .config, install the modules, run mkinitrd and copy it to /boot, set MODULE_COMPRESS in .config and then install the modules again but compressed. That's about it really. The only showstopper I feel is mkinitrd not working properly with the compressed kernel modules. Have you tried keeping the module names intact (.ko, not .ko.gz) ? It's what I was doing with modutils in 2.4 and what I'm still doing with module-init-tools in 2.6. While I don't particularly use mkinitrd, I think that keeping the name intact is preferable and should help. How would you see if, and if yes with what program, a module was compressed if the name is kept intact? I'd assume stuff like mkinitrd simply also needs to gain knowledge about compressed modules. Regards, Willy cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is pci_find_subsys safe to remove?
On Mon, Feb 25, 2008 at 05:15:25PM -0500, Robert P. J. Day wrote: it's not just that it falls under the category of PCI legacy but, if you look in drivers/pci/search.c near the bottom: ... #ifdef CONFIG_PCI_LEGACY EXPORT_SYMBOL(pci_find_device); EXPORT_SYMBOL(pci_find_slot); #endif /* CONFIG_PCI_LEGACY */ ... that symbol is not being exported even *if* you select PCI_LEGACY. i'm guessing that's an oversight but it would certainly suggest that no one can possibly be using it, no? It's used by pci_find_device(). rday cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Compress kernel modules on installation.
On Tue, Feb 26, 2008 at 11:22:03AM +0100, Willy Tarreau wrote: On Tue, Feb 26, 2008 at 11:14:55AM +0200, Adrian Bunk wrote: On Mon, Feb 25, 2008 at 11:21:38PM +0100, Willy Tarreau wrote: ... Have you tried keeping the module names intact (.ko, not .ko.gz) ? It's what I was doing with modutils in 2.4 and what I'm still doing with module-init-tools in 2.6. While I don't particularly use mkinitrd, I think that keeping the name intact is preferable and should help. How would you see if, and if yes with what program, a module was compressed if the name is kept intact? depmod/modinfo/insmod/modprobe already know it. And quite honnestly, I don't know about any other program which really needs to process those files once installed. Well, maybe ksymoops, but I'd have to check, as I don't recall having ever been annoyed with this. ... depmod/modinfo/insmod/modprobe know only if you compile module-init-tools with zlib support. And what about the busybox versions? A different name would e.g.: - easily allow proper error handling if the userspace modules program doesn't support the compression used - better scale to support additional compressions - give the user a hint what is happening and what might be the problem when anythig goes wrong Regards, Willy cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote: Hi, The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option, the .config has been attached. ... Builds fine here. Local problem (e.g. disk full) on your machine? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.25 patch] drivers/crypto/hifn_795x.c: fix 64bit division
On Tue, Feb 26, 2008 at 01:21:00PM +0100, Martin Michlmayr wrote: With 2.6.25-rc3 and a config file with CONFIG_CRYPTO_DEV_HIFN_795X=m CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y I get the following build error on at least ARM and MIPS: Building modules, stage 2. MODPOST 759 modules ERROR: __divdi3 [drivers/crypto/hifn_795x.ko] undefined! Fix below. Martin Michlmayr cu Adrian -- snip -- Using ndelay() with a 64bit variable as parameter can result in build errors like the following on some 32bit systems when it results in a 64bit division: -- snip -- ... MODPOST 759 modules ERROR: __divdi3 [drivers/crypto/hifn_795x.ko] undefined! -- snip -- Reported by Martin Michlmayr. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 40b45041ddc587c20b872a86a6a36952c28b02c7 diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c index 3110bf7..b1541c6 100644 --- a/drivers/crypto/hifn_795x.c +++ b/drivers/crypto/hifn_795x.c @@ -807,7 +807,7 @@ static int hifn_rng_data_present(struct hwrng *rng, int wait) return 1; if (!wait) return 0; - ndelay(nsec); + ndelay((u32)nsec); return 1; } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
h8300 drivers/serial/sh-sci.c compile error
Commit e108b2ca2349f510ce7d7f910eda89f71d710d84 broke the compilation of drivers/serial/sh-sci.c on h8300: -- snip -- ... CC drivers/serial/sh-sci.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/serial/sh-sci.c:57:21: error: asm/sci.h: No such file or directory ... make[3]: *** [drivers/serial/sh-sci.o] Error 1 -- snip -- cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
On Tue, Feb 26, 2008 at 11:48:29PM +0530, Kamalesh Babulal wrote:
Adrian Bunk wrote:
On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
Hi,
The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config
option,
the .config has been attached.
...
Builds fine here.
Local problem (e.g. disk full) on your machine?
cu
Adrian
Hi Adrain,
Hi Kamalseh, ;)
It Builds fine on another powerpc box with the same .config file, the problem
seems to be with the gcc
on that box, the reported build failure might have been the side effect of
the same.
drivers/md/raid6int8.c: In function `raid6_int8_gen_syndrome':
drivers/md/raid6int8.c:185: error: unable to find a register to spill in
class `FLOAT_REGS'
drivers/md/raid6int8.c:185: error: this is the insn:
(insn:HI 619 799 638 4 drivers/md/raid6int8.c:168 (set (mem:DI (plus:DI
(reg/v/f:DI 122 [ p ])
(reg/v:DI 66 ctr [orig:124 d ] [124])) [0 S8 A64])
(reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
(expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
(nil)))
drivers/md/raid6int8.c:185: confused by earlier errors, bailing out
make[2]: *** [drivers/md/raid6int8.o] Error 1
make[1]: *** [drivers/md] Error 2
make: *** [drivers] Error 2
# gcc --version
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
this means your quite old vendor gcc has a bug.
Thanks Regards,
Kamalesh Babulal,
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 08:44:53PM +0100, Sam Ravnborg wrote: On Tue, Feb 26, 2008 at 07:04:02PM +0100, Jesper Nilsson wrote: On Tue, Feb 26, 2008 at 07:47:03PM +0200, Adrian Bunk wrote: This patch moves the cris defconfigs to arch/cris/configs/ where they belong. As a side effect they can now be used directly through e.g. make ARCH=cris artpec_3_defconfig The default defconfig is set through KBUILD_DEFCONFIG. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Patch updated after I discovered an additional defconfig in arch/cris/arch-v10/defconfig That could probably have been nuked, it's ancient. I'll put this in my queue. Thanks! If you blindly apply this patch then make sure you do not end up with zero size files. They are disliked by the kerne and make distclean will delete them - and git becomes unhappy. At least GNU patch will correctly remove the files with my patch. Please name the tools that are that broken that they wouldn't apply this patch correctly and don't claim my patch was broken (or shut up). Sam cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mips: use KBUILD_DEFCONFIG
With KBUILD_DEFCONFIG we don't have to ship a second copy of ip22_defconfig Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- arch/mips/Makefile |2 arch/mips/defconfig | 1158 2 files changed, 2 insertions(+), 1158 deletions(-) 57da2fa4b7e8c035c8317e8796ca6d2ea17c1d1f diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 001c017..93ef27b 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -12,6 +12,8 @@ # for archclean cleaning up for this architecture. # +KBUILD_DEFCONFIG := ip22_defconfig + cflags-y := # diff --git a/arch/mips/defconfig b/arch/mips/defconfig deleted file mode 100644 index 4f5e56c..000 --- a/arch/mips/defconfig +++ /dev/null @@ -1,1158 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc2 -# Tue Aug 7 12:39:49 2007 -# -CONFIG_MIPS=y - -# -# Machine selection -# -CONFIG_ZONE_DMA=y -# CONFIG_MACH_ALCHEMY is not set -# CONFIG_BASLER_EXCITE is not set -# CONFIG_MIPS_COBALT is not set -# CONFIG_MACH_DECSTATION is not set -# CONFIG_MACH_JAZZ is not set -# CONFIG_LEMOTE_FULONG is not set -# CONFIG_MIPS_ATLAS is not set -# CONFIG_MIPS_MALTA is not set -# CONFIG_MIPS_SEAD is not set -# CONFIG_MIPS_SIM is not set -# CONFIG_MARKEINS is not set -# CONFIG_MACH_VR41XX is not set -# CONFIG_PNX8550_JBS is not set -# CONFIG_PNX8550_STB810 is not set -# CONFIG_PMC_MSP is not set -# CONFIG_PMC_YOSEMITE is not set -CONFIG_SGI_IP22=y -# CONFIG_SGI_IP27 is not set -# CONFIG_SGI_IP32 is not set -# CONFIG_SIBYTE_CRHINE is not set -# CONFIG_SIBYTE_CARMEL is not set -# CONFIG_SIBYTE_CRHONE is not set -# CONFIG_SIBYTE_RHONE is not set -# CONFIG_SIBYTE_SWARM is not set -# CONFIG_SIBYTE_LITTLESUR is not set -# CONFIG_SIBYTE_SENTOSA is not set -# CONFIG_SIBYTE_BIGSUR is not set -# CONFIG_SNI_RM is not set -# CONFIG_TOSHIBA_JMR3927 is not set -# CONFIG_TOSHIBA_RBTX4927 is not set -# CONFIG_TOSHIBA_RBTX4938 is not set -# CONFIG_WR_PPMC is not set -CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set -CONFIG_GENERIC_FIND_NEXT_BIT=y -CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_GENERIC_TIME=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y -# CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ is not set -CONFIG_ARC=y -CONFIG_DMA_NONCOHERENT=y -CONFIG_DMA_NEED_PCI_MAP_STATE=y -CONFIG_EARLY_PRINTK=y -CONFIG_SYS_HAS_EARLY_PRINTK=y -# CONFIG_NO_IOPORT is not set -CONFIG_GENERIC_ISA_DMA_SUPPORT_BROKEN=y -CONFIG_CPU_BIG_ENDIAN=y -# CONFIG_CPU_LITTLE_ENDIAN is not set -CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y -CONFIG_IRQ_CPU=y -CONFIG_SWAP_IO_SPACE=y -CONFIG_ARC32=y -CONFIG_BOOT_ELF32=y -CONFIG_MIPS_L1_CACHE_SHIFT=5 -CONFIG_ARC_CONSOLE=y -CONFIG_ARC_PROMLIB=y - -# -# CPU selection -# -# CONFIG_CPU_LOONGSON2 is not set -# CONFIG_CPU_MIPS32_R1 is not set -# CONFIG_CPU_MIPS32_R2 is not set -# CONFIG_CPU_MIPS64_R1 is not set -# CONFIG_CPU_MIPS64_R2 is not set -# CONFIG_CPU_R3000 is not set -# CONFIG_CPU_TX39XX is not set -# CONFIG_CPU_VR41XX is not set -# CONFIG_CPU_R4300 is not set -# CONFIG_CPU_R4X00 is not set -# CONFIG_CPU_TX49XX is not set -CONFIG_CPU_R5000=y -# CONFIG_CPU_R5432 is not set -# CONFIG_CPU_R6000 is not set -# CONFIG_CPU_NEVADA is not set -# CONFIG_CPU_R8000 is not set -# CONFIG_CPU_R1 is not set -# CONFIG_CPU_RM7000 is not set -# CONFIG_CPU_RM9000 is not set -# CONFIG_CPU_SB1 is not set -CONFIG_SYS_HAS_CPU_R4X00=y -CONFIG_SYS_HAS_CPU_R5000=y -CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y -CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y - -# -# Kernel type -# -CONFIG_32BIT=y -# CONFIG_64BIT is not set -CONFIG_PAGE_SIZE_4KB=y -# CONFIG_PAGE_SIZE_8KB is not set -# CONFIG_PAGE_SIZE_16KB is not set -# CONFIG_PAGE_SIZE_64KB is not set -CONFIG_BOARD_SCACHE=y -CONFIG_IP22_CPU_SCACHE=y -CONFIG_MIPS_MT_DISABLED=y -# CONFIG_MIPS_MT_SMP is not set -# CONFIG_MIPS_MT_SMTC is not set -CONFIG_CPU_HAS_LLSC=y -CONFIG_CPU_HAS_SYNC=y -CONFIG_GENERIC_HARDIRQS=y -CONFIG_GENERIC_IRQ_PROBE=y -CONFIG_ARCH_FLATMEM_ENABLE=y -CONFIG_SELECT_MEMORY_MODEL=y -CONFIG_FLATMEM_MANUAL=y -# CONFIG_DISCONTIGMEM_MANUAL is not set -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_FLATMEM=y -CONFIG_FLAT_NODE_MEM_MAP=y -# CONFIG_SPARSEMEM_STATIC is not set -CONFIG_SPLIT_PTLOCK_CPUS=4 -# CONFIG_RESOURCES_64BIT is not set -CONFIG_ZONE_DMA_FLAG=1 -CONFIG_BOUNCE=y -CONFIG_VIRT_TO_BUS=y -# CONFIG_HZ_48 is not set -# CONFIG_HZ_100 is not set -# CONFIG_HZ_128 is not set -# CONFIG_HZ_250 is not set -# CONFIG_HZ_256 is not set -CONFIG_HZ_1000=y -# CONFIG_HZ_1024 is not set -CONFIG_SYS_SUPPORTS_ARBIT_HZ=y -CONFIG_HZ=1000 -# CONFIG_PREEMPT_NONE is not set -CONFIG_PREEMPT_VOLUNTARY=y -# CONFIG_PREEMPT is not set -# CONFIG_KEXEC is not set -CONFIG_SECCOMP=y -CONFIG_LOCKDEP_SUPPORT=y -CONFIG_STACKTRACE_SUPPORT=y -CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config - -# -# General setup -# -CONFIG_EXPERIMENTAL=y -CONFIG_BROKEN_ON_SMP=y
[2.6 patch] m68k: use KBUILD_DEFCONFIG
The default defconfig should be one from arch/m68k/configs/ arch/m68k/defconfig was not exactly identical to amiga_defconfig but also considering how long they have been without any update that doesn't seem to have been on purpose. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- arch/m68k/Makefile |2 arch/m68k/defconfig | 657 2 files changed, 2 insertions(+), 657 deletions(-) f52a66f85069cc79c30b0c9520713bbba6cfc20d diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 2cba605..b15173f 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -13,6 +13,8 @@ # Copyright (C) 1994 by Hamish Macdonald # +KBUILD_DEFCONFIG := amiga_defconfig + # override top level makefile AS += -m68020 LDFLAGS := -m m68kelf diff --git a/arch/m68k/defconfig b/arch/m68k/defconfig deleted file mode 100644 index 7d935e4..000 --- a/arch/m68k/defconfig +++ /dev/null @@ -1,657 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.12-rc6-m68k -# Tue Jun 7 20:34:17 2005 -# -CONFIG_M68K=y -CONFIG_MMU=y -CONFIG_UID16=y -CONFIG_RWSEM_GENERIC_SPINLOCK=y -CONFIG_GENERIC_CALIBRATE_DELAY=y - -# -# Code maturity level options -# -CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y -CONFIG_BROKEN_ON_SMP=y -CONFIG_INIT_ENV_ARG_LIMIT=32 - -# -# General setup -# -CONFIG_LOCALVERSION= -CONFIG_SWAP=y -CONFIG_SYSVIPC=y -# CONFIG_POSIX_MQUEUE is not set -# CONFIG_BSD_PROCESS_ACCT is not set -CONFIG_SYSCTL=y -# CONFIG_AUDIT is not set -# CONFIG_HOTPLUG is not set -CONFIG_KOBJECT_UEVENT=y -# CONFIG_IKCONFIG is not set -# CONFIG_EMBEDDED is not set -CONFIG_KALLSYMS=y -# CONFIG_KALLSYMS_EXTRA_PASS is not set -CONFIG_PRINTK=y -CONFIG_BUG=y -CONFIG_BASE_FULL=y -CONFIG_FUTEX=y -CONFIG_EPOLL=y -CONFIG_SHMEM=y -CONFIG_CC_ALIGN_FUNCTIONS=0 -CONFIG_CC_ALIGN_LABELS=0 -CONFIG_CC_ALIGN_LOOPS=0 -CONFIG_CC_ALIGN_JUMPS=0 -# CONFIG_TINY_SHMEM is not set -CONFIG_BASE_SMALL=0 - -# -# Loadable module support -# -# CONFIG_MODULES is not set - -# -# Platform dependent setup -# -# CONFIG_SUN3 is not set -CONFIG_AMIGA=y -# CONFIG_ATARI is not set -# CONFIG_MAC is not set -# CONFIG_APOLLO is not set -# CONFIG_VME is not set -# CONFIG_HP300 is not set -# CONFIG_SUN3X is not set -# CONFIG_Q40 is not set - -# -# Processor type -# -CONFIG_M68020=y -CONFIG_M68030=y -CONFIG_M68040=y -# CONFIG_M68060 is not set -CONFIG_MMU_MOTOROLA=y -# CONFIG_M68KFPU_EMU is not set -# CONFIG_ADVANCED is not set - -# -# General setup -# -CONFIG_BINFMT_ELF=y -CONFIG_BINFMT_AOUT=y -# CONFIG_BINFMT_MISC is not set -CONFIG_ZORRO=y -# CONFIG_AMIGA_PCMCIA is not set -# CONFIG_HEARTBEAT is not set -CONFIG_PROC_HARDWARE=y -# CONFIG_ZORRO_NAMES is not set - -# -# Device Drivers -# - -# -# Generic Driver Options -# -CONFIG_STANDALONE=y -CONFIG_PREVENT_FIRMWARE_BUILD=y -# CONFIG_FW_LOADER is not set - -# -# Memory Technology Devices (MTD) -# -# CONFIG_MTD is not set - -# -# Parallel port support -# -# CONFIG_PARPORT is not set - -# -# Plug and Play support -# - -# -# Block devices -# -CONFIG_AMIGA_FLOPPY=y -# CONFIG_AMIGA_Z2RAM is not set -# CONFIG_BLK_DEV_COW_COMMON is not set -# CONFIG_BLK_DEV_LOOP is not set -# CONFIG_BLK_DEV_NBD is not set -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_COUNT=16 -CONFIG_BLK_DEV_RAM_SIZE=4096 -CONFIG_BLK_DEV_INITRD=y -CONFIG_INITRAMFS_SOURCE= -CONFIG_CDROM_PKTCDVD=y -CONFIG_CDROM_PKTCDVD_BUFFERS=8 -# CONFIG_CDROM_PKTCDVD_WCACHE is not set - -# -# IO Schedulers -# -CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y -CONFIG_IOSCHED_DEADLINE=y -CONFIG_IOSCHED_CFQ=y -# CONFIG_ATA_OVER_ETH is not set - -# -# ATA/ATAPI/MFM/RLL support -# -# CONFIG_IDE is not set - -# -# SCSI device support -# -CONFIG_SCSI=y -CONFIG_SCSI_PROC_FS=y - -# -# SCSI support type (disk, tape, CD-ROM) -# -CONFIG_BLK_DEV_SD=y -CONFIG_CHR_DEV_ST=y -# CONFIG_CHR_DEV_OSST is not set -CONFIG_BLK_DEV_SR=y -# CONFIG_BLK_DEV_SR_VENDOR is not set -# CONFIG_CHR_DEV_SG is not set - -# -# Some SCSI devices (e.g. CD jukebox) support multiple LUNs -# -# CONFIG_SCSI_MULTI_LUN is not set -CONFIG_SCSI_CONSTANTS=y -# CONFIG_SCSI_LOGGING is not set - -# -# SCSI Transport Attributes -# -# CONFIG_SCSI_SPI_ATTRS is not set -# CONFIG_SCSI_FC_ATTRS is not set -# CONFIG_SCSI_ISCSI_ATTRS is not set - -# -# SCSI low-level drivers -# -# CONFIG_SCSI_SATA is not set -# CONFIG_SCSI_DEBUG is not set -CONFIG_A3000_SCSI=y -CONFIG_A2091_SCSI=y -CONFIG_GVP11_SCSI=y -# CONFIG_CYBERSTORM_SCSI is not set -# CONFIG_CYBERSTORMII_SCSI is not set -# CONFIG_BLZ2060_SCSI is not set -# CONFIG_BLZ1230_SCSI is not set -# CONFIG_FASTLANE_SCSI is not set -# CONFIG_OKTAGON_SCSI is not set - -# -# Multi-device support (RAID and LVM) -# -# CONFIG_MD is not set - -# -# Fusion MPT device support -# - -# -# IEEE 1394 (FireWire) support -# - -# -# I2O device support -# - -# -# Networking support -# -CONFIG_NET=y - -# -# Networking options -# -CONFIG_PACKET=y -# CONFIG_PACKET_MMAP is not set -CONFIG_UNIX=y -# CONFIG_NET_KEY is not set -CONFIG_INET=y
[2.6 patch] m32r: use KBUILD_DEFCONFIG
With using KBUILD_DEFCONFIG we don't have to ship a second copy of m32700ut.smp_defconfig Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- arch/m32r/Makefile |2 arch/m32r/defconfig | 863 2 files changed, 2 insertions(+), 863 deletions(-) c1797789816e8d79133d63da3578705f47cedbd3 diff --git a/arch/m32r/Makefile b/arch/m32r/Makefile index 4072a07..469766b 100644 --- a/arch/m32r/Makefile +++ b/arch/m32r/Makefile @@ -5,6 +5,8 @@ # architecture-specific flags and dependencies. # +KBUILD_DEFCONFIG := m32700ut.smp_defconfig + LDFLAGS:= OBJCOPYFLAGS := -O binary -R .note -R .comment -S LDFLAGS_vmlinux:= diff --git a/arch/m32r/defconfig b/arch/m32r/defconfig deleted file mode 100644 index af3b981..000 --- a/arch/m32r/defconfig +++ /dev/null @@ -1,863 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc1 -# Wed Aug 1 17:22:35 2007 -# -CONFIG_M32R=y -CONFIG_GENERIC_ISA_DMA=y -CONFIG_ZONE_DMA=y -CONFIG_GENERIC_HARDIRQS=y -CONFIG_GENERIC_IRQ_PROBE=y -CONFIG_NO_IOPORT=y -CONFIG_NO_DMA=y -CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config - -# -# Code maturity level options -# -CONFIG_EXPERIMENTAL=y -CONFIG_LOCK_KERNEL=y -CONFIG_INIT_ENV_ARG_LIMIT=32 - -# -# General setup -# -CONFIG_LOCALVERSION= -CONFIG_LOCALVERSION_AUTO=y -CONFIG_SWAP=y -CONFIG_SYSVIPC=y -CONFIG_SYSVIPC_SYSCTL=y -# CONFIG_POSIX_MQUEUE is not set -CONFIG_BSD_PROCESS_ACCT=y -# CONFIG_BSD_PROCESS_ACCT_V3 is not set -# CONFIG_TASKSTATS is not set -# CONFIG_USER_NS is not set -# CONFIG_AUDIT is not set -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=15 -# CONFIG_CPUSETS is not set -CONFIG_SYSFS_DEPRECATED=y -# CONFIG_RELAY is not set -# CONFIG_BLK_DEV_INITRD is not set -# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set -CONFIG_SYSCTL=y -CONFIG_EMBEDDED=y -CONFIG_SYSCTL_SYSCALL=y -# CONFIG_KALLSYMS is not set -CONFIG_HOTPLUG=y -CONFIG_PRINTK=y -CONFIG_BUG=y -CONFIG_ELF_CORE=y -CONFIG_BASE_FULL=y -# CONFIG_FUTEX is not set -CONFIG_ANON_INODES=y -# CONFIG_EPOLL is not set -CONFIG_SIGNALFD=y -CONFIG_TIMERFD=y -CONFIG_EVENTFD=y -CONFIG_SHMEM=y -CONFIG_VM_EVENT_COUNTERS=y -CONFIG_SLAB=y -# CONFIG_SLUB is not set -# CONFIG_SLOB is not set -# CONFIG_TINY_SHMEM is not set -CONFIG_BASE_SMALL=0 -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_MODULE_FORCE_UNLOAD is not set -# CONFIG_MODVERSIONS is not set -# CONFIG_MODULE_SRCVERSION_ALL is not set -CONFIG_KMOD=y -CONFIG_STOP_MACHINE=y -CONFIG_BLOCK=y -# CONFIG_LBD is not set -# CONFIG_BLK_DEV_IO_TRACE is not set -# CONFIG_LSF is not set -# CONFIG_BLK_DEV_BSG is not set - -# -# IO Schedulers -# -CONFIG_IOSCHED_NOOP=y -# CONFIG_IOSCHED_AS is not set -CONFIG_IOSCHED_DEADLINE=y -CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_AS is not set -# CONFIG_DEFAULT_DEADLINE is not set -CONFIG_DEFAULT_CFQ=y -# CONFIG_DEFAULT_NOOP is not set -CONFIG_DEFAULT_IOSCHED=cfq - -# -# Processor type and features -# -# CONFIG_PLAT_MAPPI is not set -# CONFIG_PLAT_USRV is not set -CONFIG_PLAT_M32700UT=y -# CONFIG_PLAT_OPSPUT is not set -# CONFIG_PLAT_OAKS32R is not set -# CONFIG_PLAT_MAPPI2 is not set -# CONFIG_PLAT_MAPPI3 is not set -# CONFIG_PLAT_M32104UT is not set -CONFIG_CHIP_M32700=y -# CONFIG_CHIP_M32102 is not set -# CONFIG_CHIP_M32104 is not set -# CONFIG_CHIP_VDEC2 is not set -# CONFIG_CHIP_OPSP is not set -CONFIG_MMU=y -CONFIG_TLB_ENTRIES=32 -CONFIG_ISA_M32R2=y -CONFIG_ISA_DSP_LEVEL2=y -CONFIG_ISA_DUAL_ISSUE=y -CONFIG_BUS_CLOCK=5000 -CONFIG_TIMER_DIVIDE=128 -# CONFIG_CPU_LITTLE_ENDIAN is not set -CONFIG_MEMORY_START=0x0800 -CONFIG_MEMORY_SIZE=0x0100 -CONFIG_NOHIGHMEM=y -CONFIG_ARCH_DISCONTIGMEM_ENABLE=y -CONFIG_SELECT_MEMORY_MODEL=y -# CONFIG_FLATMEM_MANUAL is not set -CONFIG_DISCONTIGMEM_MANUAL=y -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_DISCONTIGMEM=y -CONFIG_FLAT_NODE_MEM_MAP=y -CONFIG_NEED_MULTIPLE_NODES=y -# CONFIG_SPARSEMEM_STATIC is not set -CONFIG_SPLIT_PTLOCK_CPUS=4 -# CONFIG_RESOURCES_64BIT is not set -CONFIG_ZONE_DMA_FLAG=1 -CONFIG_BOUNCE=y -CONFIG_VIRT_TO_BUS=y -CONFIG_IRAM_START=0x00f0 -CONFIG_IRAM_SIZE=0x0008 -CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set -CONFIG_GENERIC_FIND_NEXT_BIT=y -CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y -CONFIG_PREEMPT=y -CONFIG_SMP=y -# CONFIG_CHIP_M32700_TS1 is not set -CONFIG_NR_CPUS=2 -CONFIG_NODES_SHIFT=1 - -# -# Bus options (PCI, PCMCIA, EISA, MCA, ISA) -# -# CONFIG_ARCH_SUPPORTS_MSI is not set -# CONFIG_ISA is not set - -# -# PCCARD (PCMCIA/CardBus) support -# -# CONFIG_PCCARD is not set - -# -# Executable file formats -# -CONFIG_BINFMT_ELF=y -# CONFIG_BINFMT_MISC is not set - -# -# Networking -# -CONFIG_NET=y - -# -# Networking options -# -CONFIG_PACKET=y -# CONFIG_PACKET_MMAP is not set -CONFIG_UNIX=y -CONFIG_XFRM=y -# CONFIG_XFRM_USER is not set
Re: [2.6 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 08:58:02PM +0100, Sam Ravnborg wrote: Please name the tools that are that broken that they wouldn't apply this patch correctly and don't claim my patch was broken (or shut up). It is only one or two weeks ago we ended up with a zero size file in the kernel tree - and I do not know why. I just wanted to make sure we did not see this happen again. Then research first what went wrong in this case. But it is not funny when you wrongly accuse me publically of sending patches that would remove files in an incorrect way. Sam cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.
On Mon, Feb 25, 2008 at 02:48:35PM -0500, Alan Cox wrote: > On Mon, Feb 25, 2008 at 09:27:10PM +0200, Adrian Bunk wrote: > > > As I understand it if Vladis wants to submit his own change to the symbol > > > thats up to him, and he'll be liable for any fallout with the FSF, or > > > harm to Linux resulting, so long he's the one who signs it off. > > > > Why isn't anyone distributing it liable if it is not legally correct? > > They may well be, but they all get to sue Vladis in turn Being able to sue someone who has so many lawsuits that there's anyway no money left for me sounds like a bad compensation for serving a few years in jail... [1] > Alan cu Adrian [1] OK, realistically that's not enough for a jail sentence -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.
On Mon, Feb 25, 2008 at 06:19:57PM +, Alan Cox wrote: > > The reason I added GPL is not because of some idea that this is all > > "chummy" with the kernel. But because I derived the mcount code from > > glibc's version of mcount. Now you may argue that glibc is under LGPL > > and a non-GPL export is fine. But I've been advised that if I ever take > > code from someone else, to always export it with GPL. > > As I understand it if Vladis wants to submit his own change to the symbol > thats up to him, and he'll be liable for any fallout with the FSF, or > harm to Linux resulting, so long he's the one who signs it off. >... Why isn't anyone distributing it liable if it is not legally correct? > Alan cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 02:45:49PM +0100, Ingo Molnar wrote: >... > > > I've seen architectures that were build-tested for the _first time_ > > > at around 2.6.24-rc8... > > > > That can't be true. > > > > Can you name what architectures you think of and why you think noone > > tried to compile them before? > > sorry, s/build-tested/boot-tested. That's quite a difference. > there's been only 6 commits to arch/v850 between v2.6.23 and v2.6.24. > None of them seems to suggest that anyone ever tested v850 in the last > year or so. Even longer, see http://lkml.org/lkml/2008/2/13/539 It's the only port we have that is completely unmaintained and broken for ages. But the fact that the v850 port does not even compile is known for a long time, and nothing about this fact changed around 2.6.24-rc8. > Ingo >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 01:57:07PM +0100, Ingo Molnar wrote: > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > the existing 32-bit and 64-bit defconfigs should be enough for that. > > > For better/full coverage, randconfig should be used. > > > > The two big problems with randconfigs are: > > - either you build each .config both with and without your patch or you > > have to manually check which of the failures are caused by your patch > > - you require at least an order of magnitude more builds for having the > > same amount of common configurations covered > > > > And any solution that only works on x86 (e.g. based on the expectation > > that all randconfig configurations normally build) is of zero value > > for me since x86 is only one out of 23 architectures. > > so if an arguably sane testing method "only" works on x86 then the right > solution is to fix the other architectures to be sanely testable too. If you want to fix them I won't stop you... Until they are fixed I'm staying at using the defconfigs. But then there's still the other problem that at least I simply don't want to wait two weeks for having the test compiles of a patch finish. > I've seen architectures that were build-tested for the _first time_ at > around 2.6.24-rc8... That can't be true. Can you name what architectures you think of and why you think noone tried to compile them before? > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 12:50:22PM +0100, Ingo Molnar wrote: > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > What i do against build breakage is randconfig testing. That catches > > > far more build breakage than a few limited number of defconfigs > > > would ever. > > > > How do you test whether a x86 merge might break the compilation of > > e.g. some ARM platform without using any defconfig? > > yes, we do test that too. (we added this recently) Really "without using any defconfig"? > > And building all defconfigs is the trivial way of having most > > reasonable configurations covered with only one day of compile time. > > the existing 32-bit and 64-bit defconfigs should be enough for that. For > better/full coverage, randconfig should be used. The two big problems with randconfigs are: - either you build each .config both with and without your patch or you have to manually check which of the failures are caused by your patch - you require at least an order of magnitude more builds for having the same amount of common configurations covered And any solution that only works on x86 (e.g. based on the expectation that all randconfig configurations normally build) is of zero value for me since x86 is only one out of 23 architectures. > > > More defconfigs would just be a constant maintenance drag, they are > > > rather pointless on PC hardware anyway (we'd have to have at least a > > > few hundred of them for it to be meaningful as a "default config") > > > and it does not really solve the problem either. > > > > My goal was "one per subarchitecture" which is not such a big number. > > at least on x86 subarchitectures are not at all that important (they are > a rather inflexible build-time concept), and as you have seen it in this > thread, we are working on reducing their count. 99% of the real hardware > is covered under the generic subarchitecture. > > they are more important on other (mostly embedded) platforms, with ARM > having 75 defconfigs. In my workflow defconfigs are an important part of testing my patches. But that noone cares whether I break other x86 subarchitectures is not really a problem for me. > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 12:27:34PM +0100, Florian Fainelli wrote: > Le lundi 25 février 2008, Adrian Bunk a écrit : > > Booting it might fine, but CLOCK_TICK_RATE will be wrong... > > PIT_TICK_RATE is overriden specificaly for R321x in include/asm-x86/timex.h, > just like for AMD Elan. Not when you try CONFIG_X86_GENERICARCH=y as Ingo suggested. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 12:17:07PM +0100, Ingo Molnar wrote: > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > What I want is that e.g. after fiddling with kernel headers I want an > > easy way of having much compile coverage. And my script that builds > > all defconfig's is trivial (although it takes a day to finish). > > no, i think you misunderstood me. I do allyesconfig testing to make sure > the kernel is still generic enough on PC hardware - not to catch build > breakage. > > What i do against build breakage is randconfig testing. That catches far > more build breakage than a few limited number of defconfigs would ever. How do you test whether a x86 merge might break the compilation of e.g. some ARM platform without using any defconfig? And building all defconfigs is the trivial way of having most reasonable configurations covered with only one day of compile time. > More defconfigs would just be a constant maintenance drag, they are > rather pointless on PC hardware anyway (we'd have to have at least a few > hundred of them for it to be meaningful as a "default config") and it > does not really solve the problem either. My goal was "one per subarchitecture" which is not such a big number. At least for the patches I'm sending more defconfigs reduce the probability of me introducing bugs (and I might e.g. again work a bit on improving our headers mess in the future). > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 11:51:10AM +0100, Ingo Molnar wrote: > > * Florian Fainelli <[EMAIL PROTECTED]> wrote: > > > > In fact for rdc321x that should be rather easy to do right now: > > > wdt.c could/should become a regular watchdog driver, and do we > > > really need those GPIO specials in include/asm-x86/mach-rdc321x/ ? I > > > believe it should be possible to boot CONFIG_X86_GENERICARCH on a > > > rdc321x. Am i missing any particular complication? > > > > The GPIO calls will be moving later when I have finished the gpiolib > > integration for RDC just like what is currently done for ARM. You are > > right for the watchdog driver, I will move it right now. > > ok, great! Btw., do you think you could achieve your board to boot fine > with CONFIG_X86_GENERICARCH=y and CONFIG_M486=y? Booting it might fine, but CLOCK_TICK_RATE will be wrong... > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 11:14:33AM +0100, Ingo Molnar wrote: > > * Florian Fainelli <[EMAIL PROTECTED]> wrote: > > > This patch adds the default kernel configuration for the RDC R-321x > > SoC. > > hm, i'm not sure. Right now we just have a 32-bit defconfig and a 64-bit > defconfig - but there are about 8 subarchitectures in arch/x86. Given > the amount of variety in PC hardware, i doubt it makes sense to start > collecting defconfigs for hardware variants - we'd end up having > hundreds or thousands of them. Even ARM has only 75 defconfigs. What I want is at least one defconfig per subarchitecture for compile tests. And especially considering the original purpose "configuration users can use as a starting point for configuring their kernel" I even wouldn't mind if we had a few dozen x86 defconfigs. > what i do is i regularly test whether "make allyesconfig" boots all the > way up to general user-space in regular whitebox PC hardware. For > example the attached config is such a config, i successfully booted it > on 2.6.25-rc3 on a stock PC. You are testing something completely different here. What I want is that e.g. after fiddling with kernel headers I want an easy way of having much compile coverage. And my script that builds all defconfig's is trivial (although it takes a day to finish). > This way we can ensure that the (near-) totality of the config space is > bootable on regular PCs, and the subarch support is basically just > bootstrap and quirks differences. You miss our headers mess. You remember how your big x86 merge this merge window broke 8 or 9 other architectures? Change one file under include/ and watch how many configurations no longer build. Or other subtle differences between the subarchs that have in the past led to compile errors. I do consider them useful for the way I'm doing kernel tests, and even if you don't consider them that useful can we agree that adding a defconfig is neither a big deal for the subarchitecture maintainer nor imposes any maintainance work on you as maintainer (except for sometimes applying patches adding/updating them)? > Longer term we should get rid of the > subarchitecture distinction altogether and turn them into regular > quirks/callbacks/drivers. >... Generally agreed (with my biggest worry being whether changing CLOCK_TICK_RATE from a compile time constant to a runtime variable has any performance effects). > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 11:14:33AM +0100, Ingo Molnar wrote: * Florian Fainelli [EMAIL PROTECTED] wrote: This patch adds the default kernel configuration for the RDC R-321x SoC. hm, i'm not sure. Right now we just have a 32-bit defconfig and a 64-bit defconfig - but there are about 8 subarchitectures in arch/x86. Given the amount of variety in PC hardware, i doubt it makes sense to start collecting defconfigs for hardware variants - we'd end up having hundreds or thousands of them. Even ARM has only 75 defconfigs. What I want is at least one defconfig per subarchitecture for compile tests. And especially considering the original purpose configuration users can use as a starting point for configuring their kernel I even wouldn't mind if we had a few dozen x86 defconfigs. what i do is i regularly test whether make allyesconfig boots all the way up to general user-space in regular whitebox PC hardware. For example the attached config is such a config, i successfully booted it on 2.6.25-rc3 on a stock PC. You are testing something completely different here. What I want is that e.g. after fiddling with kernel headers I want an easy way of having much compile coverage. And my script that builds all defconfig's is trivial (although it takes a day to finish). This way we can ensure that the (near-) totality of the config space is bootable on regular PCs, and the subarch support is basically just bootstrap and quirks differences. You miss our headers mess. You remember how your big x86 merge this merge window broke 8 or 9 other architectures? Change one file under include/ and watch how many configurations no longer build. Or other subtle differences between the subarchs that have in the past led to compile errors. I do consider them useful for the way I'm doing kernel tests, and even if you don't consider them that useful can we agree that adding a defconfig is neither a big deal for the subarchitecture maintainer nor imposes any maintainance work on you as maintainer (except for sometimes applying patches adding/updating them)? Longer term we should get rid of the subarchitecture distinction altogether and turn them into regular quirks/callbacks/drivers. ... Generally agreed (with my biggest worry being whether changing CLOCK_TICK_RATE from a compile time constant to a runtime variable has any performance effects). Ingo cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 11:51:10AM +0100, Ingo Molnar wrote: * Florian Fainelli [EMAIL PROTECTED] wrote: In fact for rdc321x that should be rather easy to do right now: wdt.c could/should become a regular watchdog driver, and do we really need those GPIO specials in include/asm-x86/mach-rdc321x/ ? I believe it should be possible to boot CONFIG_X86_GENERICARCH on a rdc321x. Am i missing any particular complication? The GPIO calls will be moving later when I have finished the gpiolib integration for RDC just like what is currently done for ARM. You are right for the watchdog driver, I will move it right now. ok, great! Btw., do you think you could achieve your board to boot fine with CONFIG_X86_GENERICARCH=y and CONFIG_M486=y? Booting it might fine, but CLOCK_TICK_RATE will be wrong... Ingo cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 12:17:07PM +0100, Ingo Molnar wrote: * Adrian Bunk [EMAIL PROTECTED] wrote: What I want is that e.g. after fiddling with kernel headers I want an easy way of having much compile coverage. And my script that builds all defconfig's is trivial (although it takes a day to finish). no, i think you misunderstood me. I do allyesconfig testing to make sure the kernel is still generic enough on PC hardware - not to catch build breakage. What i do against build breakage is randconfig testing. That catches far more build breakage than a few limited number of defconfigs would ever. How do you test whether a x86 merge might break the compilation of e.g. some ARM platform without using any defconfig? And building all defconfigs is the trivial way of having most reasonable configurations covered with only one day of compile time. More defconfigs would just be a constant maintenance drag, they are rather pointless on PC hardware anyway (we'd have to have at least a few hundred of them for it to be meaningful as a default config) and it does not really solve the problem either. My goal was one per subarchitecture which is not such a big number. At least for the patches I'm sending more defconfigs reduce the probability of me introducing bugs (and I might e.g. again work a bit on improving our headers mess in the future). Ingo cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 12:27:34PM +0100, Florian Fainelli wrote: Le lundi 25 février 2008, Adrian Bunk a écrit : Booting it might fine, but CLOCK_TICK_RATE will be wrong... PIT_TICK_RATE is overriden specificaly for R321x in include/asm-x86/timex.h, just like for AMD Elan. Not when you try CONFIG_X86_GENERICARCH=y as Ingo suggested. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 12:50:22PM +0100, Ingo Molnar wrote: * Adrian Bunk [EMAIL PROTECTED] wrote: What i do against build breakage is randconfig testing. That catches far more build breakage than a few limited number of defconfigs would ever. How do you test whether a x86 merge might break the compilation of e.g. some ARM platform without using any defconfig? yes, we do test that too. (we added this recently) Really without using any defconfig? And building all defconfigs is the trivial way of having most reasonable configurations covered with only one day of compile time. the existing 32-bit and 64-bit defconfigs should be enough for that. For better/full coverage, randconfig should be used. The two big problems with randconfigs are: - either you build each .config both with and without your patch or you have to manually check which of the failures are caused by your patch - you require at least an order of magnitude more builds for having the same amount of common configurations covered And any solution that only works on x86 (e.g. based on the expectation that all randconfig configurations normally build) is of zero value for me since x86 is only one out of 23 architectures. More defconfigs would just be a constant maintenance drag, they are rather pointless on PC hardware anyway (we'd have to have at least a few hundred of them for it to be meaningful as a default config) and it does not really solve the problem either. My goal was one per subarchitecture which is not such a big number. at least on x86 subarchitectures are not at all that important (they are a rather inflexible build-time concept), and as you have seen it in this thread, we are working on reducing their count. 99% of the real hardware is covered under the generic subarchitecture. they are more important on other (mostly embedded) platforms, with ARM having 75 defconfigs. In my workflow defconfigs are an important part of testing my patches. But that noone cares whether I break other x86 subarchitectures is not really a problem for me. Ingo cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 01:57:07PM +0100, Ingo Molnar wrote: * Adrian Bunk [EMAIL PROTECTED] wrote: the existing 32-bit and 64-bit defconfigs should be enough for that. For better/full coverage, randconfig should be used. The two big problems with randconfigs are: - either you build each .config both with and without your patch or you have to manually check which of the failures are caused by your patch - you require at least an order of magnitude more builds for having the same amount of common configurations covered And any solution that only works on x86 (e.g. based on the expectation that all randconfig configurations normally build) is of zero value for me since x86 is only one out of 23 architectures. so if an arguably sane testing method only works on x86 then the right solution is to fix the other architectures to be sanely testable too. If you want to fix them I won't stop you... Until they are fixed I'm staying at using the defconfigs. But then there's still the other problem that at least I simply don't want to wait two weeks for having the test compiles of a patch finish. I've seen architectures that were build-tested for the _first time_ at around 2.6.24-rc8... That can't be true. Can you name what architectures you think of and why you think noone tried to compile them before? Ingo cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 02:45:49PM +0100, Ingo Molnar wrote: ... I've seen architectures that were build-tested for the _first time_ at around 2.6.24-rc8... That can't be true. Can you name what architectures you think of and why you think noone tried to compile them before? sorry, s/build-tested/boot-tested. That's quite a difference. there's been only 6 commits to arch/v850 between v2.6.23 and v2.6.24. None of them seems to suggest that anyone ever tested v850 in the last year or so. Even longer, see http://lkml.org/lkml/2008/2/13/539 It's the only port we have that is completely unmaintained and broken for ages. But the fact that the v850 port does not even compile is known for a long time, and nothing about this fact changed around 2.6.24-rc8. Ingo ... cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.
On Mon, Feb 25, 2008 at 06:19:57PM +, Alan Cox wrote: The reason I added GPL is not because of some idea that this is all chummy with the kernel. But because I derived the mcount code from glibc's version of mcount. Now you may argue that glibc is under LGPL and a non-GPL export is fine. But I've been advised that if I ever take code from someone else, to always export it with GPL. As I understand it if Vladis wants to submit his own change to the symbol thats up to him, and he'll be liable for any fallout with the FSF, or harm to Linux resulting, so long he's the one who signs it off. ... Why isn't anyone distributing it liable if it is not legally correct? Alan cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.
On Mon, Feb 25, 2008 at 02:48:35PM -0500, Alan Cox wrote: On Mon, Feb 25, 2008 at 09:27:10PM +0200, Adrian Bunk wrote: As I understand it if Vladis wants to submit his own change to the symbol thats up to him, and he'll be liable for any fallout with the FSF, or harm to Linux resulting, so long he's the one who signs it off. Why isn't anyone distributing it liable if it is not legally correct? They may well be, but they all get to sue Vladis in turn Being able to sue someone who has so many lawsuits that there's anyway no money left for me sounds like a bad compensation for serving a few years in jail... [1] Alan cu Adrian [1] OK, realistically that's not enough for a jail sentence -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/vmstat.c: proper externs
This patch adds proper extern declarations for five variables in
include/linux/vmstat.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/proc/proc_misc.c|4
include/linux/vmstat.h |6 ++
kernel/sysctl.c|2 +-
mm/vmstat.c|1 +
4 files changed, 8 insertions(+), 5 deletions(-)
b2c1dc15728c7470d3ea5aad9c1227131eb5fc3f diff --git a/fs/proc/proc_misc.c
b/fs/proc/proc_misc.c
index 468805d..622d35b 100644
--- a/fs/proc/proc_misc.c
+++ b/fs/proc/proc_misc.c
@@ -222,7 +222,6 @@ static int meminfo_read_proc(char *page, char **start,
off_t off,
#undef K
}
-extern const struct seq_operations fragmentation_op;
static int fragmentation_open(struct inode *inode, struct file *file)
{
(void)inode;
@@ -236,7 +235,6 @@ static const struct file_operations
fragmentation_file_operations = {
.release= seq_release,
};
-extern const struct seq_operations pagetypeinfo_op;
static int pagetypeinfo_open(struct inode *inode, struct file *file)
{
return seq_open(file, _op);
@@ -249,7 +247,6 @@ static const struct file_operations pagetypeinfo_file_ops =
{
.release= seq_release,
};
-extern const struct seq_operations zoneinfo_op;
static int zoneinfo_open(struct inode *inode, struct file *file)
{
return seq_open(file, _op);
@@ -346,7 +343,6 @@ static const struct file_operations proc_devinfo_operations
= {
.release= seq_release,
};
-extern const struct seq_operations vmstat_op;
static int vmstat_open(struct inode *inode, struct file *file)
{
return seq_open(file, _op);
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 75370ec..0970628 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -40,6 +40,12 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
NR_VM_EVENT_ITEMS
};
+extern const struct seq_operations fragmentation_op;
+extern const struct seq_operations pagetypeinfo_op;
+extern const struct seq_operations zoneinfo_op;
+extern const struct seq_operations vmstat_op;
+extern int sysctl_stat_interval;
+
#ifdef CONFIG_VM_EVENT_COUNTERS
/*
* Light weight per cpu counter implementation.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ffb687c..d78773d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,7 +77,6 @@ extern int sysctl_drop_caches;
extern int percpu_pagelist_fraction;
extern int compat_log;
extern int maps_protect;
-extern int sysctl_stat_interval;
extern int latencytop_enabled;
/* Constants used for minimum and maximum */
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 422d960..81a6d5f 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_VM_EVENT_COUNTERS
DEFINE_PER_CPU(struct vm_event_state, vm_event_states) = {{0}};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/hugetlb.c: fix duplicate variable
It's confusing that set_max_huge_pages() contained two different
variables named "ret", and although the code works correctly this should
be fixed.
The inner of the two variables can simply be removed.
Spotted by sparse.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
mm/hugetlb.c |1 -
1 file changed, 1 deletion(-)
--- linux-2.6/mm/hugetlb.c.old 2008-02-24 23:17:52.0 +0200
+++ linux-2.6/mm/hugetlb.c 2008-02-24 23:26:07.0 +0200
@@ -518,45 +518,44 @@
static unsigned long set_max_huge_pages(unsigned long count)
{
unsigned long min_count, ret;
/*
* Increase the pool size
* First take pages out of surplus state. Then make up the
* remaining difference by allocating fresh huge pages.
*
* We might race with alloc_buddy_huge_page() here and be unable
* to convert a surplus huge page to a normal huge page. That is
* not critical, though, it just means the overall size of the
* pool might be one hugepage larger than it needs to be, but
* within all the constraints specified by the sysctls.
*/
spin_lock(_lock);
while (surplus_huge_pages && count > persistent_huge_pages) {
if (!adjust_pool_surplus(-1))
break;
}
while (count > persistent_huge_pages) {
- int ret;
/*
* If this allocation races such that we no longer need the
* page, free_huge_page will handle it by freeing the page
* and reducing the surplus.
*/
spin_unlock(_lock);
ret = alloc_fresh_huge_page();
spin_lock(_lock);
if (!ret)
goto out;
}
/*
* Decrease the pool size
* First return free pages to the buddy allocator (being careful
* to keep enough around to satisfy reservations). Then place
* pages into surplus state as needed so the pool will shrink
* to the desired size as pages become free.
*
* By placing pages into the surplus state independent of the
* overcommit value, we are allowing the surplus pool size to
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/oom_kill.c: proper externs
This patch adds proper extern declarations for three variables in
include/linux/oom.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/oom.h |4
kernel/sysctl.c |4 +---
2 files changed, 5 insertions(+), 3 deletions(-)
5ac59cd3de28fdad038576ebef6a2ac41c5d7c69 diff --git a/include/linux/oom.h
b/include/linux/oom.h
index 3852436..f76bf07 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -23,6 +23,10 @@ enum oom_constraint {
CONSTRAINT_MEMORY_POLICY,
};
+extern int sysctl_panic_on_oom;
+extern int sysctl_oom_kill_allocating_task;
+extern int sysctl_oom_dump_tasks;
+
extern int try_set_zone_oom(struct zonelist *zonelist);
extern void clear_zonelist_oom(struct zonelist *zonelist);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8b7e954..ffb687c 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -64,9 +65,6 @@ extern int C_A_D;
extern int print_fatal_signals;
extern int sysctl_overcommit_memory;
extern int sysctl_overcommit_ratio;
-extern int sysctl_panic_on_oom;
-extern int sysctl_oom_kill_allocating_task;
-extern int sysctl_oom_dump_tasks;
extern int max_threads;
extern int core_uses_pid;
extern int suid_dumpable;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/page_alloc.c: cleanups
This patch contains the following cleanups:
- make the following needlessly global variables static:
- required_kernelcore
- zone_movable_pfn[]
- make the following needlessly global functions static:
- move_freepages()
- move_freepages_block()
- setup_pageset()
- find_usable_zone_for_movable()
- adjust_zone_range_for_zone_movable()
- __absent_pages_in_range()
- find_min_pfn_for_node()
- find_zone_movable_pfns_for_nodes()
- #if 0 the following no longer used global function:
- free_cold_page()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/gfp.h |1 -
mm/page_alloc.c | 29 -
2 files changed, 16 insertions(+), 14 deletions(-)
cf9b9e8ae11df98bf68e5fd2f95fd8f8a429cea3 diff --git a/include/linux/gfp.h
b/include/linux/gfp.h
index 164be9d..2b8148c 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -220,7 +220,6 @@ extern unsigned long get_zeroed_page(gfp_t gfp_mask);
extern void __free_pages(struct page *page, unsigned int order);
extern void free_pages(unsigned long addr, unsigned int order);
extern void free_hot_page(struct page *page);
-extern void free_cold_page(struct page *page);
#define __free_page(page) __free_pages((page), 0)
#define free_page(addr) free_pages((addr),0)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 75b9793..6710b45 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -151,9 +151,9 @@ static unsigned long __meminitdata dma_reserve;
static unsigned long __meminitdata node_boundary_start_pfn[MAX_NUMNODES];
static unsigned long __meminitdata node_boundary_end_pfn[MAX_NUMNODES];
#endif /* CONFIG_MEMORY_HOTPLUG_RESERVE */
- unsigned long __initdata required_kernelcore;
+ static unsigned long __initdata required_kernelcore;
static unsigned long __initdata required_movablecore;
- unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
+ static unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
/* movable_zone is the "real" zone pages in ZONE_MOVABLE are taken from */
int movable_zone;
@@ -688,9 +688,9 @@ static int fallbacks[MIGRATE_TYPES][MIGRATE_TYPES-1] = {
* Note that start_page and end_pages are not aligned on a pageblock
* boundary. If alignment is required, use move_freepages_block()
*/
-int move_freepages(struct zone *zone,
- struct page *start_page, struct page *end_page,
- int migratetype)
+static int move_freepages(struct zone *zone,
+ struct page *start_page, struct page *end_page,
+ int migratetype)
{
struct page *page;
unsigned long order;
@@ -729,7 +729,8 @@ int move_freepages(struct zone *zone,
return pages_moved;
}
-int move_freepages_block(struct zone *zone, struct page *page, int migratetype)
+static int move_freepages_block(struct zone *zone, struct page *page,
+ int migratetype)
{
unsigned long start_pfn, end_pfn;
struct page *start_page, *end_page;
@@ -1013,11 +1014,13 @@ void free_hot_page(struct page *page)
{
free_hot_cold_page(page, 0);
}
-
+
+#if 0
void free_cold_page(struct page *page)
{
free_hot_cold_page(page, 1);
}
+#endif /* 0 */
/*
* split_page takes a non-compound higher-order page, and splits it into
@@ -2597,7 +2600,7 @@ static int zone_batchsize(struct zone *zone)
return batch;
}
-inline void setup_pageset(struct per_cpu_pageset *p, unsigned long batch)
+static void setup_pageset(struct per_cpu_pageset *p, unsigned long batch)
{
struct per_cpu_pages *pcp;
@@ -3026,7 +3029,7 @@ void __meminit get_pfn_range_for_nid(unsigned int nid,
* assumption is made that zones within a node are ordered in monotonic
* increasing memory addresses so that the "highest" populated zone is used
*/
-void __init find_usable_zone_for_movable(void)
+static void __init find_usable_zone_for_movable(void)
{
int zone_index;
for (zone_index = MAX_NR_ZONES - 1; zone_index >= 0; zone_index--) {
@@ -3052,7 +3055,7 @@ void __init find_usable_zone_for_movable(void)
* highest usable zone for ZONE_MOVABLE. This preserves the assumption that
* zones within a node are in order of monotonic increases memory addresses
*/
-void __meminit adjust_zone_range_for_zone_movable(int nid,
+static void __meminit adjust_zone_range_for_zone_movable(int nid,
unsigned long zone_type,
unsigned long node_start_pfn,
unsigned long node_end_pfn,
@@ -3113,7 +3116,7 @@ static unsigned long __meminit
zone_spanned_pages_in_node(int nid,
* Return the number of holes in a range on a node. If nid is MAX_NUMNODES,
* then all holes in the requested range will be accounted for.
*/
-unsigned long __meminit __absent_pages_in_range(int nid,
+static unsigned long __meminit __
[2.6 patch] forgotten bits of Sangoma drivers removal
Robert P. J. Day spotted that my removal of the Sangoma drivers missed a few bits. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Documentation/networking/00-INDEX |2 Documentation/networking/wan-router.txt | 621 include/linux/Kbuild|1 include/linux/if_wanpipe.h | 124 4 files changed, 748 deletions(-) b448ba4228b3dfaacfa7e043e3aa23579d06d36b diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 02e56d4..61ac35a 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -103,8 +103,6 @@ tuntap.txt - TUN/TAP device driver, allowing user space Rx/Tx of packets. vortex.txt - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. -wan-router.txt - - WAN router documentation wavelan.txt - AT GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver x25.txt diff --git a/Documentation/networking/wan-router.txt b/Documentation/networking/wan-router.txt deleted file mode 100644 index bc2ab41..000 --- a/Documentation/networking/wan-router.txt +++ /dev/null @@ -1,621 +0,0 @@ --- -Linux WAN Router Utilities Package --- -Version 2.2.1 -Mar 28, 2001 -Author: Nenad Corbic <[EMAIL PROTECTED]> -Copyright (c) 1995-2001 Sangoma Technologies Inc. --- - -INTRODUCTION - -Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs) -and/or stand-alone hosts over vast distances with data transfer rates -significantly higher than those achievable with commonly used dial-up -connections. - -Usually an external device called `WAN router' sitting on your local network -or connected to your machine's serial port provides physical connection to -WAN. Although router's job may be as simple as taking your local network -traffic, converting it to WAN format and piping it through the WAN link, these -devices are notoriously expensive, with prices as much as 2 - 5 times higher -then the price of a typical PC box. - -Alternatively, considering robustness and multitasking capabilities of Linux, -an internal router can be built (most routers use some sort of stripped down -Unix-like operating system anyway). With a number of relatively inexpensive WAN -interface cards available on the market, a perfectly usable router can be -built for less than half a price of an external router. Yet a Linux box -acting as a router can still be used for other purposes, such as fire-walling, -running FTP, WWW or DNS server, etc. - -This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux -operating system and provides generic hardware-independent services for such -drivers. Why can existing Linux network device interface not be used for -this purpose? Well, it can. However, there are a few key differences between -a typical network interface (e.g. Ethernet) and a WAN link. - -Many WAN protocols, such as X.25 and frame relay, allow for multiple logical -connections (known as `virtual circuits' in X.25 terminology) over a single -physical link. Each such virtual circuit may (and almost always does) lead -to a different geographical location and, therefore, different network. As a -result, it is the virtual circuit, not the physical link, that represents a -route and, therefore, a network interface in Linux terms. - -To further complicate things, virtual circuits are usually volatile in nature -(excluding so called `permanent' virtual circuits or PVCs). With almost no -time required to set up and tear down a virtual circuit, it is highly desirable -to implement on-demand connections in order to minimize network charges. So -unlike a typical network driver, the WAN driver must be able to handle multiple -network interfaces and cope as multiple virtual circuits come into existence -and go away dynamically. - -Last, but not least, WAN configuration is much more complex than that of say -Ethernet and may well amount to several dozens of parameters. Some of them -are "link-wide" while others are virtual circuit-specific. The same holds -true for WAN statistics which is by far more extensive and extremely useful -when troubleshooting WAN connections. Extending the ifconfig utility to suit -these needs may be possible, but does not seem quite reasonable. Therefore, a -WAN configuration utility and corresponding application programmer's interface -is needed for this purpose. - -Most of these problems are taken care of by this module. Its goal is to -provide a user with more-or-less standard look and feel for all WAN devices and -assist a WAN device driver writer by providing common services, such as: - - o User-level interface via /proc file system - o Cen
[2.6 patch] mm/filemap.c should #include
Every file should include the headers containing the externs for its global code (in this case for struct generic_file_vm_ops). Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- 31f02514a5fdca74a4f4f48f13d3450880b7f038 diff --git a/mm/filemap.c b/mm/filemap.c index 5c74b68..9b58ae0 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -34,6 +34,8 @@ #include #include /* for BUG_ON(!in_atomic()) only */ #include +#include + #include "internal.h" /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] proper prototype for show_numa_map()
This patch adds a proper prototype for show_numa_map()
in include/linux/mempolicy.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/proc/task_mmu.c|2 --
include/linux/mempolicy.h |3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
75c93e5637cf3337f8dcd2713bac390dec1cc987 diff --git a/fs/proc/task_mmu.c
b/fs/proc/task_mmu.c
index 6dc0334..624faf1 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -721,8 +721,6 @@ const struct file_operations proc_pagemap_operations = {
#endif /* CONFIG_PROC_PAGE_MONITOR */
#ifdef CONFIG_NUMA
-extern int show_numa_map(struct seq_file *m, void *v);
-
static int show_numa_map_checked(struct seq_file *m, void *v)
{
struct proc_maps_private *priv = m->private;
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index 59c4865..914fa6e 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -37,6 +37,7 @@
struct vm_area_struct;
struct mm_struct;
+struct seq_file;
#ifdef CONFIG_NUMA
@@ -165,6 +166,8 @@ static inline void check_highest_zone(enum zone_type k)
int do_migrate_pages(struct mm_struct *mm,
const nodemask_t *from_nodes, const nodemask_t *to_nodes, int flags);
+int show_numa_map(struct seq_file *m, void *v);
+
#else
struct mempolicy {};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] VIDEO_VIVI must depend on VIDEO_DEV
This patch fixes the following compile error with VIDEO_VIVI=y, VIDEO_DEV=m reported by Toralf Förster: <-- snip --> ... LD .tmp_vmlinux1 drivers/built-in.o: In function `vivi_release': vivi.c:(.text+0x322f5): undefined reference to `video_unregister_device' vivi.c:(.text+0x32337): undefined reference to `video_device_release' drivers/built-in.o: In function `vivi_open': vivi.c:(.text+0x32845): undefined reference to `v4l2_type_names' drivers/built-in.o: In function `vivi_init': vivi.c:(.init.text+0x1d20): undefined reference to `video_device_alloc' vivi.c:(.init.text+0x1d48): undefined reference to `video_register_device' drivers/built-in.o:(.rodata+0x1b40): undefined reference to `video_ioctl2'drivers/built-in.o:(.data+0x140c): undefined reference to `video_device_release' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- 0985a480a30ce903211cf285f543e4929007ef95 diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 37072a2..2c292ee 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -382,7 +382,7 @@ endmenu # encoder / decoder chips config VIDEO_VIVI tristate "Virtual Video Driver" - depends on VIDEO_V4L2 && !SPARC32 && !SPARC64 + depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64 select VIDEOBUF_VMALLOC default n ---help--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] proper prototypes for vread/vwrite
This patch adds proper prototypes for vread/vwrite in include/linux/vmalloc.h Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/char/mem.c |3 --- include/linux/vmalloc.h |3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) ce4fe62358ed9369d3ff4e67d621164b381234ab diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 20070b7..da6319f 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -350,9 +350,6 @@ static ssize_t read_oldmem(struct file *file, char __user *buf, } #endif -extern long vread(char *buf, char *addr, unsigned long count); -extern long vwrite(char *buf, char *addr, unsigned long count); - /* * This function reads the *virtual* memory as seen by the kernel. */ diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index ce8e7da..7bdd809 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -55,6 +55,9 @@ extern int remap_vmalloc_range(struct vm_area_struct *vma, void *addr, unsigned long pgoff); void vmalloc_sync_all(void); +long vread(char *buf, char *addr, unsigned long count); +long vwrite(char *buf, char *addr, unsigned long count); + /* * Lowlevel-APIs (not for driver use!) */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] make mm/rmap.c:anon_vma_cachep static
This patch makes the needlessly global anon_vma_cachep static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/rmap.h | 12
mm/rmap.c| 12 +++-
2 files changed, 11 insertions(+), 13 deletions(-)
8d2d63d71ecbf2db78f31025acb136c9dd4db6a2 diff --git a/include/linux/rmap.h
b/include/linux/rmap.h
index 1383692..8a8dbb9 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -31,18 +31,6 @@ struct anon_vma {
#ifdef CONFIG_MMU
-extern struct kmem_cache *anon_vma_cachep;
-
-static inline struct anon_vma *anon_vma_alloc(void)
-{
- return kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL);
-}
-
-static inline void anon_vma_free(struct anon_vma *anon_vma)
-{
- kmem_cache_free(anon_vma_cachep, anon_vma);
-}
-
static inline void anon_vma_lock(struct vm_area_struct *vma)
{
struct anon_vma *anon_vma = vma->anon_vma;
diff --git a/mm/rmap.c b/mm/rmap.c
index 8fd527c..ef6bb36 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -52,7 +52,17 @@
#include
-struct kmem_cache *anon_vma_cachep;
+static struct kmem_cache *anon_vma_cachep;
+
+static inline struct anon_vma *anon_vma_alloc(void)
+{
+ return kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL);
+}
+
+static inline void anon_vma_free(struct anon_vma *anon_vma)
+{
+ kmem_cache_free(anon_vma_cachep, anon_vma);
+}
/* This must be called under the mmap_sem. */
int anon_vma_prepare(struct vm_area_struct *vma)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/swapfile.c: make code static
This patch makes the following needlessly global code static:
- swap_lock
- nr_swapfiles
- struct swap_list
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/swap.h |3 ---
mm/swapfile.c|6 +++---
2 files changed, 3 insertions(+), 6 deletions(-)
bb7f3cffcbe9023d345ff94dd983292613a8de6b diff --git a/include/linux/swap.h
b/include/linux/swap.h
index 878459a..9c9f4e5 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -237,7 +237,6 @@ extern struct page *swapin_readahead(swp_entry_t, gfp_t,
/* linux/mm/swapfile.c */
extern long total_swap_pages;
-extern unsigned int nr_swapfiles;
extern void si_swapinfo(struct sysinfo *);
extern swp_entry_t get_swap_page(void);
extern swp_entry_t get_swap_page_of_type(int);
@@ -254,8 +253,6 @@ extern int can_share_swap_page(struct page *);
extern int remove_exclusive_swap_page(struct page *);
struct backing_dev_info;
-extern spinlock_t swap_lock;
-
/* linux/mm/thrash.c */
extern struct mm_struct * swap_token_mm;
extern void grab_swap_token(void);
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 2da149c..0b20c79 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -33,8 +33,8 @@
#include
#include
-DEFINE_SPINLOCK(swap_lock);
-unsigned int nr_swapfiles;
+static DEFINE_SPINLOCK(swap_lock);
+static unsigned int nr_swapfiles;
long total_swap_pages;
static int swap_overflow;
@@ -43,7 +43,7 @@ static const char Unused_file[] = "Unused swap file entry ";
static const char Bad_offset[] = "Bad swap offset entry ";
static const char Unused_offset[] = "Unused swap offset entry ";
-struct swap_list_t swap_list = {-1, -1};
+static struct swap_list_t swap_list = {-1, -1};
static struct swap_info_struct swap_info[MAX_SWAPFILES];
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] make atapi_dmadir static
atapi_dmadir can now become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |2 +-
drivers/ata/libata.h |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
ad621a905275c744307cdb9bb4bab47a187a477b diff --git a/drivers/ata/libata-core.c
b/drivers/ata/libata-core.c
index fbc2435..b57fad3 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -113,7 +113,7 @@ int atapi_enabled = 1;
module_param(atapi_enabled, int, 0444);
MODULE_PARM_DESC(atapi_enabled, "Enable discovery of ATAPI devices (0=off,
1=on)");
-int atapi_dmadir = 0;
+static int atapi_dmadir = 0;
module_param(atapi_dmadir, int, 0444);
MODULE_PARM_DESC(atapi_dmadir, "Enable ATAPI DMADIR bridge support (0=off,
1=on)");
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index 6036ded..aa884f7 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -56,7 +56,6 @@ enum {
extern unsigned int ata_print_id;
extern struct workqueue_struct *ata_aux_wq;
extern int atapi_enabled;
-extern int atapi_dmadir;
extern int atapi_passthru16;
extern int libata_fua;
extern int libata_noacpi;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/allocpercpu.c: make 4 functions static
This patch makes the following needlessly global functions static:
- percpu_depopulate()
- __percpu_depopulate_mask()
- percpu_populate()
- __percpu_populate_mask()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/percpu.h | 29 -
mm/allocpercpu.c | 20 +++-
2 files changed, 11 insertions(+), 38 deletions(-)
d11f49caeadfdeef1b9e9c07103de2cdb5346e36 diff --git a/include/linux/percpu.h
b/include/linux/percpu.h
index 1ac9697..4437b52 100644
--- a/include/linux/percpu.h
+++ b/include/linux/percpu.h
@@ -69,11 +69,6 @@ struct percpu_data {
(__typeof__(ptr))__p->ptrs[(cpu)]; \
})
-extern void *percpu_populate(void *__pdata, size_t size, gfp_t gfp, int cpu);
-extern void percpu_depopulate(void *__pdata, int cpu);
-extern int __percpu_populate_mask(void *__pdata, size_t size, gfp_t gfp,
- cpumask_t *mask);
-extern void __percpu_depopulate_mask(void *__pdata, cpumask_t *mask);
extern void *__percpu_alloc_mask(size_t size, gfp_t gfp, cpumask_t *mask);
extern void percpu_free(void *__pdata);
@@ -81,26 +76,6 @@ extern void percpu_free(void *__pdata);
#define percpu_ptr(ptr, cpu) ({ (void)(cpu); (ptr); })
-static inline void percpu_depopulate(void *__pdata, int cpu)
-{
-}
-
-static inline void __percpu_depopulate_mask(void *__pdata, cpumask_t *mask)
-{
-}
-
-static inline void *percpu_populate(void *__pdata, size_t size, gfp_t gfp,
- int cpu)
-{
- return percpu_ptr(__pdata, cpu);
-}
-
-static inline int __percpu_populate_mask(void *__pdata, size_t size, gfp_t gfp,
-cpumask_t *mask)
-{
- return 0;
-}
-
static __always_inline void *__percpu_alloc_mask(size_t size, gfp_t gfp,
cpumask_t *mask)
{
return kzalloc(size, gfp);
@@ -113,10 +88,6 @@ static inline void percpu_free(void *__pdata)
#endif /* CONFIG_SMP */
-#define percpu_populate_mask(__pdata, size, gfp, mask) \
- __percpu_populate_mask((__pdata), (size), (gfp), &(mask))
-#define percpu_depopulate_mask(__pdata, mask) \
- __percpu_depopulate_mask((__pdata), &(mask))
#define percpu_alloc_mask(size, gfp, mask) \
__percpu_alloc_mask((size), (gfp), &(mask))
diff --git a/mm/allocpercpu.c b/mm/allocpercpu.c
index 7e58322..cbadbe2 100644
--- a/mm/allocpercpu.c
+++ b/mm/allocpercpu.c
@@ -14,27 +14,28 @@
* Depopulating per-cpu data for a cpu going offline would be a typical
* use case. You need to register a cpu hotplug handler for that purpose.
*/
-void percpu_depopulate(void *__pdata, int cpu)
+static void percpu_depopulate(void *__pdata, int cpu)
{
struct percpu_data *pdata = __percpu_disguise(__pdata);
kfree(pdata->ptrs[cpu]);
pdata->ptrs[cpu] = NULL;
}
-EXPORT_SYMBOL_GPL(percpu_depopulate);
/**
* percpu_depopulate_mask - depopulate per-cpu data for some cpu's
* @__pdata: per-cpu data to depopulate
* @mask: depopulate per-cpu data for cpu's selected through mask bits
*/
-void __percpu_depopulate_mask(void *__pdata, cpumask_t *mask)
+static void __percpu_depopulate_mask(void *__pdata, cpumask_t *mask)
{
int cpu;
for_each_cpu_mask(cpu, *mask)
percpu_depopulate(__pdata, cpu);
}
-EXPORT_SYMBOL_GPL(__percpu_depopulate_mask);
+
+#define percpu_depopulate_mask(__pdata, mask) \
+ __percpu_depopulate_mask((__pdata), &(mask))
/**
* percpu_populate - populate per-cpu data for given cpu
@@ -47,7 +48,7 @@ EXPORT_SYMBOL_GPL(__percpu_depopulate_mask);
* use case. You need to register a cpu hotplug handler for that purpose.
* Per-cpu object is populated with zeroed buffer.
*/
-void *percpu_populate(void *__pdata, size_t size, gfp_t gfp, int cpu)
+static void *percpu_populate(void *__pdata, size_t size, gfp_t gfp, int cpu)
{
struct percpu_data *pdata = __percpu_disguise(__pdata);
int node = cpu_to_node(cpu);
@@ -59,7 +60,6 @@ void *percpu_populate(void *__pdata, size_t size, gfp_t gfp,
int cpu)
pdata->ptrs[cpu] = kzalloc(size, gfp);
return pdata->ptrs[cpu];
}
-EXPORT_SYMBOL_GPL(percpu_populate);
/**
* percpu_populate_mask - populate per-cpu data for more cpu's
@@ -70,8 +70,8 @@ EXPORT_SYMBOL_GPL(percpu_populate);
*
* Per-cpu objects are populated with zeroed buffers.
*/
-int __percpu_populate_mask(void *__pdata, size_t size, gfp_t gfp,
- cpumask_t *mask)
+static int __percpu_populate_mask(void *__pdata, size_t size, gfp_t gfp,
+ cpumask_t *mask)
{
cpumask_t populated = CPU_MASK_NONE;
int cpu;
@@ -84,7 +84,9 @@ int __percpu_populate_mask(void *__pdata, size_t size, gfp_t
gfp,
cpu_set(cpu, populated);
return 0;
}
-EXPORT_SYMBOL_GPL(__percpu_populate_mask);
+
+#define percpu_populate_mask(__pdata, size, gfp, mask) \
+ __percpu_
[2.6 patch] make mm/memory.c:print_bad_pte() static
This patch makes the needlessly global print_bad_pte() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/mm.h |1 -
mm/memory.c|3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
cf47cf1dae0fe5b04b95ede85cac61c74f75c1c2 diff --git a/include/linux/mm.h
b/include/linux/mm.h
index 3b3e134..33d5ebe 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -777,7 +777,6 @@ extern int access_process_vm(struct task_struct *tsk,
unsigned long addr, void *
int get_user_pages(struct task_struct *tsk, struct mm_struct *mm, unsigned
long start,
int len, int write, int force, struct page **pages, struct
vm_area_struct **vmas);
-void print_bad_pte(struct vm_area_struct *, pte_t, unsigned long);
extern int try_to_release_page(struct page * page, gfp_t gfp_mask);
extern void do_invalidatepage(struct page *page, unsigned long offset);
diff --git a/mm/memory.c b/mm/memory.c
index ce3c9e4..fe624e4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -355,7 +355,8 @@ static inline void add_mm_rss(struct mm_struct *mm, int
file_rss, int anon_rss)
*
* The calling function must still handle the error.
*/
-void print_bad_pte(struct vm_area_struct *vma, pte_t pte, unsigned long vaddr)
+static void print_bad_pte(struct vm_area_struct *vma, pte_t pte,
+ unsigned long vaddr)
{
printk(KERN_ERR "Bad pte = %08llx, process = %s, "
"vm_flags = %lx, vaddr = %lx\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2,6 patch] make mm/sparse.c: make a function static
This patch makes the needlessly global sparse_early_mem_map_alloc()
static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
47e8f879748b0e89a465a50626ae93dd55844a15 diff --git a/mm/sparse.c b/mm/sparse.c
index f6a43c0..99cd810 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -269,7 +269,7 @@ struct page __init *sparse_mem_map_populate(unsigned long
pnum, int nid)
}
#endif /* !CONFIG_SPARSEMEM_VMEMMAP */
-struct page __init *sparse_early_mem_map_alloc(unsigned long pnum)
+static struct page __init *sparse_early_mem_map_alloc(unsigned long pnum)
{
struct page *map;
struct mem_section *ms = __nr_to_section(pnum);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/memcontrol.c: make 2 functions static
This patch makes thefollowing needlessly global functions static:
- mem_cgroup_force_empty()
- mem_cgroup_write_strategy()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
mm/memcontrol.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
0d8013bdcc403636cc326410af419e2e94d2450d diff --git a/mm/memcontrol.c
b/mm/memcontrol.c
index 6bded84..f13c577 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -878,7 +878,7 @@ retry:
* This enables deleting this mem_cgroup.
*/
-int mem_cgroup_force_empty(struct mem_cgroup *mem)
+static int mem_cgroup_force_empty(struct mem_cgroup *mem)
{
int ret = -EBUSY;
int node, zid;
@@ -909,7 +909,7 @@ out:
-int mem_cgroup_write_strategy(char *buf, unsigned long long *tmp)
+static int mem_cgroup_write_strategy(char *buf, unsigned long long *tmp)
{
*tmp = memparse(buf, );
if (*buf != '\0')
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] IDE: Coding Style fixes to drivers/ide/ide-cd.c
On Sun, Feb 24, 2008 at 10:10:33PM +0100, Paolo Ciarrocchi wrote:
> Before:
> total: 43 errors, 66 warnings, 2183 lines checked
>
> After:
> total: 0 errors, 36 warnings, 2192 lines checked
>
> I didn't (and I don't plan to) fix the warnings:
> WARNING: line over 80 characters
>
>
> Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
> ---
> drivers/ide/ide-cd.c | 245
> ++
> 1 files changed, 127 insertions(+), 118 deletions(-)
>
> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index 546f436..3181e71 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
>...
> switch (sense->sense_key) {
> - case NO_SENSE: case RECOVERED_ERROR:
> - break;
>...
> + case NO_SENSE: case RECOVERED_ERROR:
> + break;
>...
In case the goal is not to only improve the checkpatch metrics but to
improve the readability of the code the biggest coding style problem
here was (and still is) not the indentation.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
defconfig's for all x86 subarchitectures
For compile tests it would be nice it we had at least for each subarchitecture not covered by X86_GENERICARCH a defconfig. These are the following subarchitectures: - X86_ELAN - X86_VOYAGER - X86_NUMAQ - X86_VISWS - X86_RDC321X - X86_VSMP A defconfig is nothing special, it's enough to simply put the .config used for one machine into arch/x86/configs/ . Thanks in advance Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
defconfig's for all x86 subarchitectures
For compile tests it would be nice it we had at least for each subarchitecture not covered by X86_GENERICARCH a defconfig. These are the following subarchitectures: - X86_ELAN - X86_VOYAGER - X86_NUMAQ - X86_VISWS - X86_RDC321X - X86_VSMP A defconfig is nothing special, it's enough to simply put the .config used for one machine into arch/x86/configs/ . Thanks in advance Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] IDE: Coding Style fixes to drivers/ide/ide-cd.c
On Sun, Feb 24, 2008 at 10:10:33PM +0100, Paolo Ciarrocchi wrote:
Before:
total: 43 errors, 66 warnings, 2183 lines checked
After:
total: 0 errors, 36 warnings, 2192 lines checked
I didn't (and I don't plan to) fix the warnings:
WARNING: line over 80 characters
Signed-off-by: Paolo Ciarrocchi [EMAIL PROTECTED]
---
drivers/ide/ide-cd.c | 245
++
1 files changed, 127 insertions(+), 118 deletions(-)
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 546f436..3181e71 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
...
switch (sense-sense_key) {
- case NO_SENSE: case RECOVERED_ERROR:
- break;
...
+ case NO_SENSE: case RECOVERED_ERROR:
+ break;
...
In case the goal is not to only improve the checkpatch metrics but to
improve the readability of the code the biggest coding style problem
here was (and still is) not the indentation.
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/memcontrol.c: make 2 functions static
This patch makes thefollowing needlessly global functions static:
- mem_cgroup_force_empty()
- mem_cgroup_write_strategy()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
mm/memcontrol.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
0d8013bdcc403636cc326410af419e2e94d2450d diff --git a/mm/memcontrol.c
b/mm/memcontrol.c
index 6bded84..f13c577 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -878,7 +878,7 @@ retry:
* This enables deleting this mem_cgroup.
*/
-int mem_cgroup_force_empty(struct mem_cgroup *mem)
+static int mem_cgroup_force_empty(struct mem_cgroup *mem)
{
int ret = -EBUSY;
int node, zid;
@@ -909,7 +909,7 @@ out:
-int mem_cgroup_write_strategy(char *buf, unsigned long long *tmp)
+static int mem_cgroup_write_strategy(char *buf, unsigned long long *tmp)
{
*tmp = memparse(buf, buf);
if (*buf != '\0')
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2,6 patch] make mm/sparse.c: make a function static
This patch makes the needlessly global sparse_early_mem_map_alloc()
static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
47e8f879748b0e89a465a50626ae93dd55844a15 diff --git a/mm/sparse.c b/mm/sparse.c
index f6a43c0..99cd810 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -269,7 +269,7 @@ struct page __init *sparse_mem_map_populate(unsigned long
pnum, int nid)
}
#endif /* !CONFIG_SPARSEMEM_VMEMMAP */
-struct page __init *sparse_early_mem_map_alloc(unsigned long pnum)
+static struct page __init *sparse_early_mem_map_alloc(unsigned long pnum)
{
struct page *map;
struct mem_section *ms = __nr_to_section(pnum);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/allocpercpu.c: make 4 functions static
This patch makes the following needlessly global functions static:
- percpu_depopulate()
- __percpu_depopulate_mask()
- percpu_populate()
- __percpu_populate_mask()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
include/linux/percpu.h | 29 -
mm/allocpercpu.c | 20 +++-
2 files changed, 11 insertions(+), 38 deletions(-)
d11f49caeadfdeef1b9e9c07103de2cdb5346e36 diff --git a/include/linux/percpu.h
b/include/linux/percpu.h
index 1ac9697..4437b52 100644
--- a/include/linux/percpu.h
+++ b/include/linux/percpu.h
@@ -69,11 +69,6 @@ struct percpu_data {
(__typeof__(ptr))__p-ptrs[(cpu)]; \
})
-extern void *percpu_populate(void *__pdata, size_t size, gfp_t gfp, int cpu);
-extern void percpu_depopulate(void *__pdata, int cpu);
-extern int __percpu_populate_mask(void *__pdata, size_t size, gfp_t gfp,
- cpumask_t *mask);
-extern void __percpu_depopulate_mask(void *__pdata, cpumask_t *mask);
extern void *__percpu_alloc_mask(size_t size, gfp_t gfp, cpumask_t *mask);
extern void percpu_free(void *__pdata);
@@ -81,26 +76,6 @@ extern void percpu_free(void *__pdata);
#define percpu_ptr(ptr, cpu) ({ (void)(cpu); (ptr); })
-static inline void percpu_depopulate(void *__pdata, int cpu)
-{
-}
-
-static inline void __percpu_depopulate_mask(void *__pdata, cpumask_t *mask)
-{
-}
-
-static inline void *percpu_populate(void *__pdata, size_t size, gfp_t gfp,
- int cpu)
-{
- return percpu_ptr(__pdata, cpu);
-}
-
-static inline int __percpu_populate_mask(void *__pdata, size_t size, gfp_t gfp,
-cpumask_t *mask)
-{
- return 0;
-}
-
static __always_inline void *__percpu_alloc_mask(size_t size, gfp_t gfp,
cpumask_t *mask)
{
return kzalloc(size, gfp);
@@ -113,10 +88,6 @@ static inline void percpu_free(void *__pdata)
#endif /* CONFIG_SMP */
-#define percpu_populate_mask(__pdata, size, gfp, mask) \
- __percpu_populate_mask((__pdata), (size), (gfp), (mask))
-#define percpu_depopulate_mask(__pdata, mask) \
- __percpu_depopulate_mask((__pdata), (mask))
#define percpu_alloc_mask(size, gfp, mask) \
__percpu_alloc_mask((size), (gfp), (mask))
diff --git a/mm/allocpercpu.c b/mm/allocpercpu.c
index 7e58322..cbadbe2 100644
--- a/mm/allocpercpu.c
+++ b/mm/allocpercpu.c
@@ -14,27 +14,28 @@
* Depopulating per-cpu data for a cpu going offline would be a typical
* use case. You need to register a cpu hotplug handler for that purpose.
*/
-void percpu_depopulate(void *__pdata, int cpu)
+static void percpu_depopulate(void *__pdata, int cpu)
{
struct percpu_data *pdata = __percpu_disguise(__pdata);
kfree(pdata-ptrs[cpu]);
pdata-ptrs[cpu] = NULL;
}
-EXPORT_SYMBOL_GPL(percpu_depopulate);
/**
* percpu_depopulate_mask - depopulate per-cpu data for some cpu's
* @__pdata: per-cpu data to depopulate
* @mask: depopulate per-cpu data for cpu's selected through mask bits
*/
-void __percpu_depopulate_mask(void *__pdata, cpumask_t *mask)
+static void __percpu_depopulate_mask(void *__pdata, cpumask_t *mask)
{
int cpu;
for_each_cpu_mask(cpu, *mask)
percpu_depopulate(__pdata, cpu);
}
-EXPORT_SYMBOL_GPL(__percpu_depopulate_mask);
+
+#define percpu_depopulate_mask(__pdata, mask) \
+ __percpu_depopulate_mask((__pdata), (mask))
/**
* percpu_populate - populate per-cpu data for given cpu
@@ -47,7 +48,7 @@ EXPORT_SYMBOL_GPL(__percpu_depopulate_mask);
* use case. You need to register a cpu hotplug handler for that purpose.
* Per-cpu object is populated with zeroed buffer.
*/
-void *percpu_populate(void *__pdata, size_t size, gfp_t gfp, int cpu)
+static void *percpu_populate(void *__pdata, size_t size, gfp_t gfp, int cpu)
{
struct percpu_data *pdata = __percpu_disguise(__pdata);
int node = cpu_to_node(cpu);
@@ -59,7 +60,6 @@ void *percpu_populate(void *__pdata, size_t size, gfp_t gfp,
int cpu)
pdata-ptrs[cpu] = kzalloc(size, gfp);
return pdata-ptrs[cpu];
}
-EXPORT_SYMBOL_GPL(percpu_populate);
/**
* percpu_populate_mask - populate per-cpu data for more cpu's
@@ -70,8 +70,8 @@ EXPORT_SYMBOL_GPL(percpu_populate);
*
* Per-cpu objects are populated with zeroed buffers.
*/
-int __percpu_populate_mask(void *__pdata, size_t size, gfp_t gfp,
- cpumask_t *mask)
+static int __percpu_populate_mask(void *__pdata, size_t size, gfp_t gfp,
+ cpumask_t *mask)
{
cpumask_t populated = CPU_MASK_NONE;
int cpu;
@@ -84,7 +84,9 @@ int __percpu_populate_mask(void *__pdata, size_t size, gfp_t
gfp,
cpu_set(cpu, populated);
return 0;
}
-EXPORT_SYMBOL_GPL(__percpu_populate_mask);
+
+#define percpu_populate_mask(__pdata, size, gfp, mask) \
+ __percpu_populate_mask((__pdata), (size), (gfp), (mask
[2.6 patch] make mm/memory.c:print_bad_pte() static
This patch makes the needlessly global print_bad_pte() static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
include/linux/mm.h |1 -
mm/memory.c|3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
cf47cf1dae0fe5b04b95ede85cac61c74f75c1c2 diff --git a/include/linux/mm.h
b/include/linux/mm.h
index 3b3e134..33d5ebe 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -777,7 +777,6 @@ extern int access_process_vm(struct task_struct *tsk,
unsigned long addr, void *
int get_user_pages(struct task_struct *tsk, struct mm_struct *mm, unsigned
long start,
int len, int write, int force, struct page **pages, struct
vm_area_struct **vmas);
-void print_bad_pte(struct vm_area_struct *, pte_t, unsigned long);
extern int try_to_release_page(struct page * page, gfp_t gfp_mask);
extern void do_invalidatepage(struct page *page, unsigned long offset);
diff --git a/mm/memory.c b/mm/memory.c
index ce3c9e4..fe624e4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -355,7 +355,8 @@ static inline void add_mm_rss(struct mm_struct *mm, int
file_rss, int anon_rss)
*
* The calling function must still handle the error.
*/
-void print_bad_pte(struct vm_area_struct *vma, pte_t pte, unsigned long vaddr)
+static void print_bad_pte(struct vm_area_struct *vma, pte_t pte,
+ unsigned long vaddr)
{
printk(KERN_ERR Bad pte = %08llx, process = %s,
vm_flags = %lx, vaddr = %lx\n,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] make atapi_dmadir static
atapi_dmadir can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/ata/libata-core.c |2 +-
drivers/ata/libata.h |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
ad621a905275c744307cdb9bb4bab47a187a477b diff --git a/drivers/ata/libata-core.c
b/drivers/ata/libata-core.c
index fbc2435..b57fad3 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -113,7 +113,7 @@ int atapi_enabled = 1;
module_param(atapi_enabled, int, 0444);
MODULE_PARM_DESC(atapi_enabled, Enable discovery of ATAPI devices (0=off,
1=on));
-int atapi_dmadir = 0;
+static int atapi_dmadir = 0;
module_param(atapi_dmadir, int, 0444);
MODULE_PARM_DESC(atapi_dmadir, Enable ATAPI DMADIR bridge support (0=off,
1=on));
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index 6036ded..aa884f7 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -56,7 +56,6 @@ enum {
extern unsigned int ata_print_id;
extern struct workqueue_struct *ata_aux_wq;
extern int atapi_enabled;
-extern int atapi_dmadir;
extern int atapi_passthru16;
extern int libata_fua;
extern int libata_noacpi;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/swapfile.c: make code static
This patch makes the following needlessly global code static:
- swap_lock
- nr_swapfiles
- struct swap_list
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
include/linux/swap.h |3 ---
mm/swapfile.c|6 +++---
2 files changed, 3 insertions(+), 6 deletions(-)
bb7f3cffcbe9023d345ff94dd983292613a8de6b diff --git a/include/linux/swap.h
b/include/linux/swap.h
index 878459a..9c9f4e5 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -237,7 +237,6 @@ extern struct page *swapin_readahead(swp_entry_t, gfp_t,
/* linux/mm/swapfile.c */
extern long total_swap_pages;
-extern unsigned int nr_swapfiles;
extern void si_swapinfo(struct sysinfo *);
extern swp_entry_t get_swap_page(void);
extern swp_entry_t get_swap_page_of_type(int);
@@ -254,8 +253,6 @@ extern int can_share_swap_page(struct page *);
extern int remove_exclusive_swap_page(struct page *);
struct backing_dev_info;
-extern spinlock_t swap_lock;
-
/* linux/mm/thrash.c */
extern struct mm_struct * swap_token_mm;
extern void grab_swap_token(void);
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 2da149c..0b20c79 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -33,8 +33,8 @@
#include asm/tlbflush.h
#include linux/swapops.h
-DEFINE_SPINLOCK(swap_lock);
-unsigned int nr_swapfiles;
+static DEFINE_SPINLOCK(swap_lock);
+static unsigned int nr_swapfiles;
long total_swap_pages;
static int swap_overflow;
@@ -43,7 +43,7 @@ static const char Unused_file[] = Unused swap file entry ;
static const char Bad_offset[] = Bad swap offset entry ;
static const char Unused_offset[] = Unused swap offset entry ;
-struct swap_list_t swap_list = {-1, -1};
+static struct swap_list_t swap_list = {-1, -1};
static struct swap_info_struct swap_info[MAX_SWAPFILES];
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] make mm/rmap.c:anon_vma_cachep static
This patch makes the needlessly global anon_vma_cachep static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
include/linux/rmap.h | 12
mm/rmap.c| 12 +++-
2 files changed, 11 insertions(+), 13 deletions(-)
8d2d63d71ecbf2db78f31025acb136c9dd4db6a2 diff --git a/include/linux/rmap.h
b/include/linux/rmap.h
index 1383692..8a8dbb9 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -31,18 +31,6 @@ struct anon_vma {
#ifdef CONFIG_MMU
-extern struct kmem_cache *anon_vma_cachep;
-
-static inline struct anon_vma *anon_vma_alloc(void)
-{
- return kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL);
-}
-
-static inline void anon_vma_free(struct anon_vma *anon_vma)
-{
- kmem_cache_free(anon_vma_cachep, anon_vma);
-}
-
static inline void anon_vma_lock(struct vm_area_struct *vma)
{
struct anon_vma *anon_vma = vma-anon_vma;
diff --git a/mm/rmap.c b/mm/rmap.c
index 8fd527c..ef6bb36 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -52,7 +52,17 @@
#include asm/tlbflush.h
-struct kmem_cache *anon_vma_cachep;
+static struct kmem_cache *anon_vma_cachep;
+
+static inline struct anon_vma *anon_vma_alloc(void)
+{
+ return kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL);
+}
+
+static inline void anon_vma_free(struct anon_vma *anon_vma)
+{
+ kmem_cache_free(anon_vma_cachep, anon_vma);
+}
/* This must be called under the mmap_sem. */
int anon_vma_prepare(struct vm_area_struct *vma)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] proper prototypes for vread/vwrite
This patch adds proper prototypes for vread/vwrite in include/linux/vmalloc.h Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- drivers/char/mem.c |3 --- include/linux/vmalloc.h |3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) ce4fe62358ed9369d3ff4e67d621164b381234ab diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 20070b7..da6319f 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -350,9 +350,6 @@ static ssize_t read_oldmem(struct file *file, char __user *buf, } #endif -extern long vread(char *buf, char *addr, unsigned long count); -extern long vwrite(char *buf, char *addr, unsigned long count); - /* * This function reads the *virtual* memory as seen by the kernel. */ diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index ce8e7da..7bdd809 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -55,6 +55,9 @@ extern int remap_vmalloc_range(struct vm_area_struct *vma, void *addr, unsigned long pgoff); void vmalloc_sync_all(void); +long vread(char *buf, char *addr, unsigned long count); +long vwrite(char *buf, char *addr, unsigned long count); + /* * Lowlevel-APIs (not for driver use!) */ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] VIDEO_VIVI must depend on VIDEO_DEV
This patch fixes the following compile error with VIDEO_VIVI=y, VIDEO_DEV=m reported by Toralf Förster: -- snip -- ... LD .tmp_vmlinux1 drivers/built-in.o: In function `vivi_release': vivi.c:(.text+0x322f5): undefined reference to `video_unregister_device' vivi.c:(.text+0x32337): undefined reference to `video_device_release' drivers/built-in.o: In function `vivi_open': vivi.c:(.text+0x32845): undefined reference to `v4l2_type_names' drivers/built-in.o: In function `vivi_init': vivi.c:(.init.text+0x1d20): undefined reference to `video_device_alloc' vivi.c:(.init.text+0x1d48): undefined reference to `video_register_device' drivers/built-in.o:(.rodata+0x1b40): undefined reference to `video_ioctl2'drivers/built-in.o:(.data+0x140c): undefined reference to `video_device_release' make: *** [.tmp_vmlinux1] Error 1 -- snip -- Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 0985a480a30ce903211cf285f543e4929007ef95 diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 37072a2..2c292ee 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -382,7 +382,7 @@ endmenu # encoder / decoder chips config VIDEO_VIVI tristate Virtual Video Driver - depends on VIDEO_V4L2 !SPARC32 !SPARC64 + depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 select VIDEOBUF_VMALLOC default n ---help--- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] proper prototype for show_numa_map()
This patch adds a proper prototype for show_numa_map()
in include/linux/mempolicy.h
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
fs/proc/task_mmu.c|2 --
include/linux/mempolicy.h |3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
75c93e5637cf3337f8dcd2713bac390dec1cc987 diff --git a/fs/proc/task_mmu.c
b/fs/proc/task_mmu.c
index 6dc0334..624faf1 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -721,8 +721,6 @@ const struct file_operations proc_pagemap_operations = {
#endif /* CONFIG_PROC_PAGE_MONITOR */
#ifdef CONFIG_NUMA
-extern int show_numa_map(struct seq_file *m, void *v);
-
static int show_numa_map_checked(struct seq_file *m, void *v)
{
struct proc_maps_private *priv = m-private;
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index 59c4865..914fa6e 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -37,6 +37,7 @@
struct vm_area_struct;
struct mm_struct;
+struct seq_file;
#ifdef CONFIG_NUMA
@@ -165,6 +166,8 @@ static inline void check_highest_zone(enum zone_type k)
int do_migrate_pages(struct mm_struct *mm,
const nodemask_t *from_nodes, const nodemask_t *to_nodes, int flags);
+int show_numa_map(struct seq_file *m, void *v);
+
#else
struct mempolicy {};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] forgotten bits of Sangoma drivers removal
Robert P. J. Day spotted that my removal of the Sangoma drivers missed a few bits. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- Documentation/networking/00-INDEX |2 Documentation/networking/wan-router.txt | 621 include/linux/Kbuild|1 include/linux/if_wanpipe.h | 124 4 files changed, 748 deletions(-) b448ba4228b3dfaacfa7e043e3aa23579d06d36b diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 02e56d4..61ac35a 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -103,8 +103,6 @@ tuntap.txt - TUN/TAP device driver, allowing user space Rx/Tx of packets. vortex.txt - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. -wan-router.txt - - WAN router documentation wavelan.txt - ATT GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver x25.txt diff --git a/Documentation/networking/wan-router.txt b/Documentation/networking/wan-router.txt deleted file mode 100644 index bc2ab41..000 --- a/Documentation/networking/wan-router.txt +++ /dev/null @@ -1,621 +0,0 @@ --- -Linux WAN Router Utilities Package --- -Version 2.2.1 -Mar 28, 2001 -Author: Nenad Corbic [EMAIL PROTECTED] -Copyright (c) 1995-2001 Sangoma Technologies Inc. --- - -INTRODUCTION - -Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs) -and/or stand-alone hosts over vast distances with data transfer rates -significantly higher than those achievable with commonly used dial-up -connections. - -Usually an external device called `WAN router' sitting on your local network -or connected to your machine's serial port provides physical connection to -WAN. Although router's job may be as simple as taking your local network -traffic, converting it to WAN format and piping it through the WAN link, these -devices are notoriously expensive, with prices as much as 2 - 5 times higher -then the price of a typical PC box. - -Alternatively, considering robustness and multitasking capabilities of Linux, -an internal router can be built (most routers use some sort of stripped down -Unix-like operating system anyway). With a number of relatively inexpensive WAN -interface cards available on the market, a perfectly usable router can be -built for less than half a price of an external router. Yet a Linux box -acting as a router can still be used for other purposes, such as fire-walling, -running FTP, WWW or DNS server, etc. - -This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux -operating system and provides generic hardware-independent services for such -drivers. Why can existing Linux network device interface not be used for -this purpose? Well, it can. However, there are a few key differences between -a typical network interface (e.g. Ethernet) and a WAN link. - -Many WAN protocols, such as X.25 and frame relay, allow for multiple logical -connections (known as `virtual circuits' in X.25 terminology) over a single -physical link. Each such virtual circuit may (and almost always does) lead -to a different geographical location and, therefore, different network. As a -result, it is the virtual circuit, not the physical link, that represents a -route and, therefore, a network interface in Linux terms. - -To further complicate things, virtual circuits are usually volatile in nature -(excluding so called `permanent' virtual circuits or PVCs). With almost no -time required to set up and tear down a virtual circuit, it is highly desirable -to implement on-demand connections in order to minimize network charges. So -unlike a typical network driver, the WAN driver must be able to handle multiple -network interfaces and cope as multiple virtual circuits come into existence -and go away dynamically. - -Last, but not least, WAN configuration is much more complex than that of say -Ethernet and may well amount to several dozens of parameters. Some of them -are link-wide while others are virtual circuit-specific. The same holds -true for WAN statistics which is by far more extensive and extremely useful -when troubleshooting WAN connections. Extending the ifconfig utility to suit -these needs may be possible, but does not seem quite reasonable. Therefore, a -WAN configuration utility and corresponding application programmer's interface -is needed for this purpose. - -Most of these problems are taken care of by this module. Its goal is to -provide a user with more-or-less standard look and feel for all WAN devices and -assist a WAN device driver writer by providing common services, such as: - - o User-level interface via /proc file system - o Centralized configuration - o
[2.6 patch] mm/filemap.c should #include linux/ramfs.h
Every file should include the headers containing the externs for its global code (in this case for struct generic_file_vm_ops). Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 31f02514a5fdca74a4f4f48f13d3450880b7f038 diff --git a/mm/filemap.c b/mm/filemap.c index 5c74b68..9b58ae0 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -34,6 +34,8 @@ #include linux/cpuset.h #include linux/hardirq.h /* for BUG_ON(!in_atomic()) only */ #include linux/memcontrol.h +#include linux/ramfs.h + #include internal.h /* -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/oom_kill.c: proper externs
This patch adds proper extern declarations for three variables in
include/linux/oom.h
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
include/linux/oom.h |4
kernel/sysctl.c |4 +---
2 files changed, 5 insertions(+), 3 deletions(-)
5ac59cd3de28fdad038576ebef6a2ac41c5d7c69 diff --git a/include/linux/oom.h
b/include/linux/oom.h
index 3852436..f76bf07 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -23,6 +23,10 @@ enum oom_constraint {
CONSTRAINT_MEMORY_POLICY,
};
+extern int sysctl_panic_on_oom;
+extern int sysctl_oom_kill_allocating_task;
+extern int sysctl_oom_dump_tasks;
+
extern int try_set_zone_oom(struct zonelist *zonelist);
extern void clear_zonelist_oom(struct zonelist *zonelist);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8b7e954..ffb687c 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -45,6 +45,7 @@
#include linux/nfs_fs.h
#include linux/acpi.h
#include linux/reboot.h
+#include linux/oom.h
#include asm/uaccess.h
#include asm/processor.h
@@ -64,9 +65,6 @@ extern int C_A_D;
extern int print_fatal_signals;
extern int sysctl_overcommit_memory;
extern int sysctl_overcommit_ratio;
-extern int sysctl_panic_on_oom;
-extern int sysctl_oom_kill_allocating_task;
-extern int sysctl_oom_dump_tasks;
extern int max_threads;
extern int core_uses_pid;
extern int suid_dumpable;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/page_alloc.c: cleanups
This patch contains the following cleanups:
- make the following needlessly global variables static:
- required_kernelcore
- zone_movable_pfn[]
- make the following needlessly global functions static:
- move_freepages()
- move_freepages_block()
- setup_pageset()
- find_usable_zone_for_movable()
- adjust_zone_range_for_zone_movable()
- __absent_pages_in_range()
- find_min_pfn_for_node()
- find_zone_movable_pfns_for_nodes()
- #if 0 the following no longer used global function:
- free_cold_page()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
include/linux/gfp.h |1 -
mm/page_alloc.c | 29 -
2 files changed, 16 insertions(+), 14 deletions(-)
cf9b9e8ae11df98bf68e5fd2f95fd8f8a429cea3 diff --git a/include/linux/gfp.h
b/include/linux/gfp.h
index 164be9d..2b8148c 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -220,7 +220,6 @@ extern unsigned long get_zeroed_page(gfp_t gfp_mask);
extern void __free_pages(struct page *page, unsigned int order);
extern void free_pages(unsigned long addr, unsigned int order);
extern void free_hot_page(struct page *page);
-extern void free_cold_page(struct page *page);
#define __free_page(page) __free_pages((page), 0)
#define free_page(addr) free_pages((addr),0)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 75b9793..6710b45 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -151,9 +151,9 @@ static unsigned long __meminitdata dma_reserve;
static unsigned long __meminitdata node_boundary_start_pfn[MAX_NUMNODES];
static unsigned long __meminitdata node_boundary_end_pfn[MAX_NUMNODES];
#endif /* CONFIG_MEMORY_HOTPLUG_RESERVE */
- unsigned long __initdata required_kernelcore;
+ static unsigned long __initdata required_kernelcore;
static unsigned long __initdata required_movablecore;
- unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
+ static unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
/* movable_zone is the real zone pages in ZONE_MOVABLE are taken from */
int movable_zone;
@@ -688,9 +688,9 @@ static int fallbacks[MIGRATE_TYPES][MIGRATE_TYPES-1] = {
* Note that start_page and end_pages are not aligned on a pageblock
* boundary. If alignment is required, use move_freepages_block()
*/
-int move_freepages(struct zone *zone,
- struct page *start_page, struct page *end_page,
- int migratetype)
+static int move_freepages(struct zone *zone,
+ struct page *start_page, struct page *end_page,
+ int migratetype)
{
struct page *page;
unsigned long order;
@@ -729,7 +729,8 @@ int move_freepages(struct zone *zone,
return pages_moved;
}
-int move_freepages_block(struct zone *zone, struct page *page, int migratetype)
+static int move_freepages_block(struct zone *zone, struct page *page,
+ int migratetype)
{
unsigned long start_pfn, end_pfn;
struct page *start_page, *end_page;
@@ -1013,11 +1014,13 @@ void free_hot_page(struct page *page)
{
free_hot_cold_page(page, 0);
}
-
+
+#if 0
void free_cold_page(struct page *page)
{
free_hot_cold_page(page, 1);
}
+#endif /* 0 */
/*
* split_page takes a non-compound higher-order page, and splits it into
@@ -2597,7 +2600,7 @@ static int zone_batchsize(struct zone *zone)
return batch;
}
-inline void setup_pageset(struct per_cpu_pageset *p, unsigned long batch)
+static void setup_pageset(struct per_cpu_pageset *p, unsigned long batch)
{
struct per_cpu_pages *pcp;
@@ -3026,7 +3029,7 @@ void __meminit get_pfn_range_for_nid(unsigned int nid,
* assumption is made that zones within a node are ordered in monotonic
* increasing memory addresses so that the highest populated zone is used
*/
-void __init find_usable_zone_for_movable(void)
+static void __init find_usable_zone_for_movable(void)
{
int zone_index;
for (zone_index = MAX_NR_ZONES - 1; zone_index = 0; zone_index--) {
@@ -3052,7 +3055,7 @@ void __init find_usable_zone_for_movable(void)
* highest usable zone for ZONE_MOVABLE. This preserves the assumption that
* zones within a node are in order of monotonic increases memory addresses
*/
-void __meminit adjust_zone_range_for_zone_movable(int nid,
+static void __meminit adjust_zone_range_for_zone_movable(int nid,
unsigned long zone_type,
unsigned long node_start_pfn,
unsigned long node_end_pfn,
@@ -3113,7 +3116,7 @@ static unsigned long __meminit
zone_spanned_pages_in_node(int nid,
* Return the number of holes in a range on a node. If nid is MAX_NUMNODES,
* then all holes in the requested range will be accounted for.
*/
-unsigned long __meminit __absent_pages_in_range(int nid,
+static unsigned long __meminit __absent_pages_in_range(int nid
[2.6 patch] mm/vmstat.c: proper externs
This patch adds proper extern declarations for five variables in
include/linux/vmstat.h
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
fs/proc/proc_misc.c|4
include/linux/vmstat.h |6 ++
kernel/sysctl.c|2 +-
mm/vmstat.c|1 +
4 files changed, 8 insertions(+), 5 deletions(-)
b2c1dc15728c7470d3ea5aad9c1227131eb5fc3f diff --git a/fs/proc/proc_misc.c
b/fs/proc/proc_misc.c
index 468805d..622d35b 100644
--- a/fs/proc/proc_misc.c
+++ b/fs/proc/proc_misc.c
@@ -222,7 +222,6 @@ static int meminfo_read_proc(char *page, char **start,
off_t off,
#undef K
}
-extern const struct seq_operations fragmentation_op;
static int fragmentation_open(struct inode *inode, struct file *file)
{
(void)inode;
@@ -236,7 +235,6 @@ static const struct file_operations
fragmentation_file_operations = {
.release= seq_release,
};
-extern const struct seq_operations pagetypeinfo_op;
static int pagetypeinfo_open(struct inode *inode, struct file *file)
{
return seq_open(file, pagetypeinfo_op);
@@ -249,7 +247,6 @@ static const struct file_operations pagetypeinfo_file_ops =
{
.release= seq_release,
};
-extern const struct seq_operations zoneinfo_op;
static int zoneinfo_open(struct inode *inode, struct file *file)
{
return seq_open(file, zoneinfo_op);
@@ -346,7 +343,6 @@ static const struct file_operations proc_devinfo_operations
= {
.release= seq_release,
};
-extern const struct seq_operations vmstat_op;
static int vmstat_open(struct inode *inode, struct file *file)
{
return seq_open(file, vmstat_op);
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 75370ec..0970628 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -40,6 +40,12 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
NR_VM_EVENT_ITEMS
};
+extern const struct seq_operations fragmentation_op;
+extern const struct seq_operations pagetypeinfo_op;
+extern const struct seq_operations zoneinfo_op;
+extern const struct seq_operations vmstat_op;
+extern int sysctl_stat_interval;
+
#ifdef CONFIG_VM_EVENT_COUNTERS
/*
* Light weight per cpu counter implementation.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ffb687c..d78773d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -42,6 +42,7 @@
#include linux/limits.h
#include linux/dcache.h
#include linux/syscalls.h
+#include linux/vmstat.h
#include linux/nfs_fs.h
#include linux/acpi.h
#include linux/reboot.h
@@ -76,7 +77,6 @@ extern int sysctl_drop_caches;
extern int percpu_pagelist_fraction;
extern int compat_log;
extern int maps_protect;
-extern int sysctl_stat_interval;
extern int latencytop_enabled;
/* Constants used for minimum and maximum */
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 422d960..81a6d5f 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -14,6 +14,7 @@
#include linux/module.h
#include linux/cpu.h
#include linux/sched.h
+#include linux/vmstat.h
#ifdef CONFIG_VM_EVENT_COUNTERS
DEFINE_PER_CPU(struct vm_event_state, vm_event_states) = {{0}};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/hugetlb.c: fix duplicate variable
It's confusing that set_max_huge_pages() contained two different
variables named ret, and although the code works correctly this should
be fixed.
The inner of the two variables can simply be removed.
Spotted by sparse.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
mm/hugetlb.c |1 -
1 file changed, 1 deletion(-)
--- linux-2.6/mm/hugetlb.c.old 2008-02-24 23:17:52.0 +0200
+++ linux-2.6/mm/hugetlb.c 2008-02-24 23:26:07.0 +0200
@@ -518,45 +518,44 @@
static unsigned long set_max_huge_pages(unsigned long count)
{
unsigned long min_count, ret;
/*
* Increase the pool size
* First take pages out of surplus state. Then make up the
* remaining difference by allocating fresh huge pages.
*
* We might race with alloc_buddy_huge_page() here and be unable
* to convert a surplus huge page to a normal huge page. That is
* not critical, though, it just means the overall size of the
* pool might be one hugepage larger than it needs to be, but
* within all the constraints specified by the sysctls.
*/
spin_lock(hugetlb_lock);
while (surplus_huge_pages count persistent_huge_pages) {
if (!adjust_pool_surplus(-1))
break;
}
while (count persistent_huge_pages) {
- int ret;
/*
* If this allocation races such that we no longer need the
* page, free_huge_page will handle it by freeing the page
* and reducing the surplus.
*/
spin_unlock(hugetlb_lock);
ret = alloc_fresh_huge_page();
spin_lock(hugetlb_lock);
if (!ret)
goto out;
}
/*
* Decrease the pool size
* First return free pages to the buddy allocator (being careful
* to keep enough around to satisfy reservations). Then place
* pages into surplus state as needed so the pool will shrink
* to the desired size as pages become free.
*
* By placing pages into the surplus state independent of the
* overcommit value, we are allowing the surplus pool size to
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6.25 patch] fix drivers/usb/host/u132-hcd.c compilation
This patch fixes the following compile error caused by
commit 3a2d5b700132f35401f1d9e22fe3c2cab02c2549:
<-- snip -->
...
CC drivers/usb/host/u132-hcd.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:
In function ‘u132_suspend’:
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3224:
error: expected expression before ‘int’
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225:
error: ‘ports’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225:
error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225:
error: for each function it appears in.)
make[4]: *** [drivers/usb/host/u132-hcd.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
69cf78da6371ad2aca30844858eeea318b37b3ec diff --git
a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index 6fca069..325c6c7 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -3221,9 +3221,11 @@ static int u132_suspend(struct platform_device *pdev,
pm_message_t state)
break;
case PM_EVENT_SUSPEND:
case PM_EVENT_HIBERNATE:
-int ports = MAX_U132_PORTS;
-while (ports-- > 0) {
-port_power(u132, ports, 0);
+ {
+ int ports = MAX_U132_PORTS;
+ while (ports-- > 0) {
+ port_power(u132, ports, 0);
+ }
}
break;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] IDE: Coding Style fixes to drivers/ide/pci/generic.c
On Sat, Feb 23, 2008 at 03:05:47PM +0100, Paolo Ciarrocchi wrote:
> File is now error free.
> Compile tested.
>
>
> Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
> ---
> drivers/ide/pci/generic.c | 50 ++--
> 1 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/ide/pci/generic.c b/drivers/ide/pci/generic.c
> index f83afa1..f9a5879 100644
> --- a/drivers/ide/pci/generic.c
> +++ b/drivers/ide/pci/generic.c
>...
> - /* 2 */ DECLARE_GENERIC_PCI_DEV("SAMURAI", 0),
> - /* 3 */ DECLARE_GENERIC_PCI_DEV("HT6565", 0),
> - /* 4 */ DECLARE_GENERIC_PCI_DEV("UM8673F", IDE_HFLAGS_UMC),
> - /* 5 */ DECLARE_GENERIC_PCI_DEV("UM8886A", IDE_HFLAGS_UMC),
> - /* 6 */ DECLARE_GENERIC_PCI_DEV("UM8886BF",IDE_HFLAGS_UMC),
> - /* 7 */ DECLARE_GENERIC_PCI_DEV("HINT_IDE",0),
> - /* 8 */ DECLARE_GENERIC_PCI_DEV("VIA_IDE", IDE_HFLAG_NO_AUTODMA),
> - /* 9 */ DECLARE_GENERIC_PCI_DEV("OPTI621V",IDE_HFLAG_NO_AUTODMA),
> + /* 2 */ DECLARE_GENERIC_PCI_DEV("SAMURAI", 0),
> + /* 3 */ DECLARE_GENERIC_PCI_DEV("HT6565", 0),
> + /* 4 */ DECLARE_GENERIC_PCI_DEV("UM8673F", IDE_HFLAGS_UMC),
> + /* 5 */ DECLARE_GENERIC_PCI_DEV("UM8886A", IDE_HFLAGS_UMC),
> + /* 6 */ DECLARE_GENERIC_PCI_DEV("UM8886BF", IDE_HFLAGS_UMC),
> + /* 7 */ DECLARE_GENERIC_PCI_DEV("HINT_IDE", 0),
> + /* 8 */ DECLARE_GENERIC_PCI_DEV("VIA_IDE", IDE_HFLAG_NO_AUTODMA),
> + /* 9 */ DECLARE_GENERIC_PCI_DEV("OPTI621V", IDE_HFLAG_NO_AUTODMA),
>...
I do not even see checkpatch complaining about this, and even if it did
your patch would make the code _less_ readable.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] IDE: Coding Style fixes to drivers/ide/pci/generic.c
On Sat, Feb 23, 2008 at 03:05:47PM +0100, Paolo Ciarrocchi wrote: File is now error free. Compile tested. Signed-off-by: Paolo Ciarrocchi [EMAIL PROTECTED] --- drivers/ide/pci/generic.c | 50 ++-- 1 files changed, 25 insertions(+), 25 deletions(-) diff --git a/drivers/ide/pci/generic.c b/drivers/ide/pci/generic.c index f83afa1..f9a5879 100644 --- a/drivers/ide/pci/generic.c +++ b/drivers/ide/pci/generic.c ... - /* 2 */ DECLARE_GENERIC_PCI_DEV(SAMURAI, 0), - /* 3 */ DECLARE_GENERIC_PCI_DEV(HT6565, 0), - /* 4 */ DECLARE_GENERIC_PCI_DEV(UM8673F, IDE_HFLAGS_UMC), - /* 5 */ DECLARE_GENERIC_PCI_DEV(UM8886A, IDE_HFLAGS_UMC), - /* 6 */ DECLARE_GENERIC_PCI_DEV(UM8886BF,IDE_HFLAGS_UMC), - /* 7 */ DECLARE_GENERIC_PCI_DEV(HINT_IDE,0), - /* 8 */ DECLARE_GENERIC_PCI_DEV(VIA_IDE, IDE_HFLAG_NO_AUTODMA), - /* 9 */ DECLARE_GENERIC_PCI_DEV(OPTI621V,IDE_HFLAG_NO_AUTODMA), + /* 2 */ DECLARE_GENERIC_PCI_DEV(SAMURAI, 0), + /* 3 */ DECLARE_GENERIC_PCI_DEV(HT6565, 0), + /* 4 */ DECLARE_GENERIC_PCI_DEV(UM8673F, IDE_HFLAGS_UMC), + /* 5 */ DECLARE_GENERIC_PCI_DEV(UM8886A, IDE_HFLAGS_UMC), + /* 6 */ DECLARE_GENERIC_PCI_DEV(UM8886BF, IDE_HFLAGS_UMC), + /* 7 */ DECLARE_GENERIC_PCI_DEV(HINT_IDE, 0), + /* 8 */ DECLARE_GENERIC_PCI_DEV(VIA_IDE, IDE_HFLAG_NO_AUTODMA), + /* 9 */ DECLARE_GENERIC_PCI_DEV(OPTI621V, IDE_HFLAG_NO_AUTODMA), ... I do not even see checkpatch complaining about this, and even if it did your patch would make the code _less_ readable. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.25 patch] fix drivers/usb/host/u132-hcd.c compilation
This patch fixes the following compile error caused by
commit 3a2d5b700132f35401f1d9e22fe3c2cab02c2549:
-- snip --
...
CC drivers/usb/host/u132-hcd.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:
In function ‘u132_suspend’:
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3224:
error: expected expression before ‘int’
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225:
error: ‘ports’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225:
error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/usb/host/u132-hcd.c:3225:
error: for each function it appears in.)
make[4]: *** [drivers/usb/host/u132-hcd.o] Error 1
-- snip --
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
69cf78da6371ad2aca30844858eeea318b37b3ec diff --git
a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index 6fca069..325c6c7 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -3221,9 +3221,11 @@ static int u132_suspend(struct platform_device *pdev,
pm_message_t state)
break;
case PM_EVENT_SUSPEND:
case PM_EVENT_HIBERNATE:
-int ports = MAX_U132_PORTS;
-while (ports-- 0) {
-port_power(u132, ports, 0);
+ {
+ int ports = MAX_U132_PORTS;
+ while (ports-- 0) {
+ port_power(u132, ports, 0);
+ }
}
break;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
xtansa common_defconfig compile error
Trying to compile common_defconfig fails with the following error: <-- snip --> ... CC init/main.o In file included from include2/asm/hardirq.h:15, from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/hardirq.h:7, from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/asm-generic/local.h:5, from include2/asm/local.h:14, from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/module.h:19, from /home/bunk/linux/kernel-2.6/git/linux-2.6/init/main.c:13: include2/asm/irq.h:14:35: error: asm/platform/hardware.h: No such file or directory make[2]: *** [init/main.o] Error 1 <-- snip --> cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/migrate.c should #include
Every file should include the headers containing the externs for its global functions (in this case for sys_move_pages()). Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- 5624ee2189a0b767e8e474cdd53d8a536dd8f262 diff --git a/mm/migrate.c b/mm/migrate.c index a73504f..36e1820 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -30,6 +30,7 @@ #include #include #include +#include #include "internal.h" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] make struct mempolicy.c:default_policy static
This patc makes the needlessly global struct default_policy static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
4a69fc08292ebe8b7d202436a71926950a980c21 diff --git a/include/linux/mempolicy.h
b/include/linux/mempolicy.h
index 59c4865..fd20b03 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -149,7 +149,6 @@ extern void mpol_rebind_task(struct task_struct *tsk,
extern void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new);
extern void mpol_fix_fork_child_flag(struct task_struct *p);
-extern struct mempolicy default_policy;
extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
unsigned long addr, gfp_t gfp_flags, struct mempolicy **mpol);
extern unsigned slab_node(struct mempolicy *policy);
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 6c7ba1a..f3118a8 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -105,7 +105,7 @@ static struct kmem_cache *sn_cache;
policied. */
enum zone_type policy_zone = 0;
-struct mempolicy default_policy = {
+static struct mempolicy default_policy = {
.refcnt = ATOMIC_INIT(1), /* never free it */
.policy = MPOL_DEFAULT,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/slub.c: remove unneeded NULL check
On Wed, Feb 20, 2008 at 03:52:44PM +0200, Pekka Enberg wrote:
>
> Hi Adrian,
>
> On 2/20/2008, "Adrian Bunk" <[EMAIL PROTECTED]> wrote:
> > The Coverity checker spotted the following inconsequent NULL checking
> > introduced by commit 8ff12cfc009a2a38d87fa7058226fe197bb2696f:
> >
> > <-- snip -->
> >
> > ...
> > static inline int is_end(void *addr)
> > {
> > return (unsigned long)addr & PAGE_MAPPING_ANON;
> > }
> > ...
> > static void deactivate_slab(struct kmem_cache *s, struct kmem_cache_cpu *c)
> > {
> > ...
> > if (c->freelist)<
> > stat(c, DEACTIVATE_REMOTE_FREES);
>
> I spotted this too.
I missed that.
> c->freelist should never be NULL so why not send a
> patch to Christoph?
Patch below.
cu
Adrian
<-- snip -->
There's no reason for checking c->freelist for being NULL here (and we'd
anyway Oops below if it was).
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
dae2a3c60f258f3ad2522b85d79b735a89d702f0 diff --git a/mm/slub.c b/mm/slub.c
index 74c65af..072e0a6 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1404,8 +1404,7 @@ static void deactivate_slab(struct kmem_cache *s, struct
kmem_cache_cpu *c)
struct page *page = c->page;
int tail = 1;
- if (c->freelist)
- stat(c, DEACTIVATE_REMOTE_FREES);
+ stat(c, DEACTIVATE_REMOTE_FREES);
/*
* Merge cpu freelist into freelist. Typically we get here
* because both freelists are empty. So this is unlikely
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] pci/pcie/aer/aerdrv_acpi.c: remove unneeded NULL check
On Wed, Feb 20, 2008 at 08:09:35AM -0800, Greg KH wrote:
> On Wed, Feb 20, 2008 at 09:56:28AM +0200, Adrian Bunk wrote:
> > On Tue, Feb 19, 2008 at 09:47:58PM -0800, Greg KH wrote:
> > > On Tue, Feb 19, 2008 at 09:29:02PM +0200, Adrian Bunk wrote:
> > > > The Coverity checker spotted the following inconsequent NULL checking
> > > > introduced by commit 3c75e23784e6ed5f4841de43d0750fd9b37bafcb:
> > > >
> > > > <-- snip -->
> > > >
> > > > ...
> > > > int aer_osc_setup(struct pcie_device *pciedev)
> > > > {
> > > > ...v
> > > > while (pdev->bus && pdev->bus->self)
> > > > pdev = pdev->bus->self;
> > >
> > > That could probably change to just pdev->bus->self, as a bus should
> > > always be there for a pdev, so I don't see this as a problem.
> >
> > I'm not claiming this specific case was a problem.
>
> Well, Coverity did :)
It only said it's once checked and once not.
> > When a NULL check is only performed in some cases that's sometimes a bug
> > that has to be fixed and in most cases a not required check that should
> > be removed at some point in time.
>
> I agree, patches are always welcome...
Patch below.
> thanks,
>
> greg k-h
cu
Adrian
<-- snip -->
There's no reason for checking pdev->bus for being NULL here (and we'd
anyway Oops 3 lines below if it was).
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
74832021c82be6e2ed6055f4f25dbf152df67cf5 diff --git
a/drivers/pci/pcie/aer/aerdrv_acpi.c b/drivers/pci/pcie/aer/aerdrv_acpi.c
index 8c199ae..1e2a858 100644
--- a/drivers/pci/pcie/aer/aerdrv_acpi.c
+++ b/drivers/pci/pcie/aer/aerdrv_acpi.c
@@ -34,7 +34,7 @@ int aer_osc_setup(struct pcie_device *pciedev)
acpi_handle handle = 0;
/* Find root host bridge */
- while (pdev->bus && pdev->bus->self)
+ while (pdev->bus->self)
pdev = pdev->bus->self;
handle = acpi_get_pci_rootbridge_handle(
pci_domain_nr(pdev->bus), pdev->bus->number);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] usb/serial/io_ti.c: remove unneeded NULL check
On Fri, Feb 22, 2008 at 10:10:16AM +, Alan Cox wrote:
> > Either the test of port->tty here is unneeded:
> >
> > if (port->tty)
> >port->tty->low_latency = low_latency;
> >
> > ...or the lack of test of port->tty here is a mistake:
> >
> > edge_set_termios (port, port->tty->termios);
>
> Interesting - so coverity doesn't understand the BKL. It's producing the
> right answer, for the right reason but the assumption it makes isn't 100%
> safe.
Coverity doesn't perform magic.
It simply notices that it's once checked and once dereferenced
unconditionally.
> The check can go.
Thanks, patch below.
> Alan
cu
Adrian
<-- snip -->
There's no reason for checking pdev->bus for being NULL here (and we'd
anyway Oops below if it was).
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
afefd6935c788b3e4071092ebc04c4d356dd7496 diff --git
a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index cd34059..700683c 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -1944,8 +1944,7 @@ static int edge_open (struct usb_serial_port *port,
struct file * filp)
if (edge_port == NULL)
return -ENODEV;
- if (port->tty)
- port->tty->low_latency = low_latency;
+ port->tty->low_latency = low_latency;
port_number = port->number - port->serial->minor;
switch (port_number) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
