* Re: [PATCH 00/34] Make kernel build deterministic
From: Artem Bityutskiy @ 2011-04-06 9:25 UTC (permalink / raw)
To: Michal Marek
Cc: anil_ravindranath, mchehab, benh, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, tipc-discussion, dwmw2,
linux-media, arnaud.giersch, linux-kbuild, IvDoorn, teigland,
tony.olech, apw, linux-hams, tglx, swhiteho, linux-arm-kernel,
linux-edac, jon.maloy, linux-scsi, netdev, Greg KH,
linux-wireless, linux-kernel@
In-Reply-To: <4D9C2D56.70700@suse.cz>
On Wed, 2011-04-06 at 11:07 +0200, Michal Marek wrote:
> > So additionally, I'd suggest:
> > 1. Instrument checkpatch.pl and make it err or warn on timestamps.
>
> This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198
Yeah, great, did not notice, thanks!
> > 2. Probably instrument linux-next to rise a warning when people break
> > this.
>
> I'm not sure if Stephen has that much spare time, and I don't think it
> is necessary. I think the checkpatch check is sufficient and I'll check
> myself occasionally.
Yes, that's fine, I just wanted to speak this out - there is a
probability that someone gets excited and creates some instrumentation
to kbuild to automatically detect bad things and then Stephen could
easily use that.
WRT "not necessary" - well, I think it is always better to cut bad
things before they are merged, rather than afterwards.
But anyway, let's forget about this.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Michal Marek @ 2011-04-06 9:23 UTC (permalink / raw)
To: Greg KH
Cc: anil_ravindranath, mchehab, benh, x86, mac, aacraid, linux-mtd,
allan.stephens, hpa, netdev, t.sailer, gwingerde, IvDoorn, elf,
cluster-devel, ccaulfie, mingo, dougthompson, linux-media,
arnaud.giersch, linux-kbuild, teigland, tony.olech, apw,
linux-hams, tglx, swhiteho, linux-arm-kernel, linux-edac,
jon.maloy, linux-scsi, linuxppc-dev, linux-usb, linux-wireless,
linux-kernel, bluesmoke-
In-Reply-To: <20110405154918.GA31337@suse.de>
On 5.4.2011 17:49, Greg KH wrote:
> Very nice stuff. Do you want to take the individual patches through one
> of your trees, or do you mind if the subsystem maintainers take them
> through theirs?
I'd leave it up to the subsystem maintainers. I'll check once the merge
window opens and send the remaining patches to Linus directly.
Michal
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Michal Marek @ 2011-04-06 9:07 UTC (permalink / raw)
To: dedekind1
Cc: anil_ravindranath, mchehab, benh, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, tipc-discussion, dwmw2,
linux-media, arnaud.giersch, linux-kbuild, IvDoorn, teigland,
tony.olech, apw, linux-hams, tglx, swhiteho, linux-arm-kernel,
linux-edac, jon.maloy, linux-scsi, netdev, Greg KH,
linux-wireless, linux-kernel@
In-Reply-To: <1302031447.2608.41.camel@koala>
On 5.4.2011 21:24, Artem Bityutskiy wrote:
> On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
>> On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
>>>
>>> Hi,
>>>
>>> this series makes it possible to build bit-identical kernel image and
>>> modules from identical sources. Of course the build is already
>>> deterministic in terms of behavior of the code, but the various
>>> timestamps embedded in the object files make it hard to compare two
>>> builds, for instance to verify that a makefile cleanup didn't
>>> accidentally change something. A prime example is /proc/config.gz, which
>>> has both a timestamp in the gzip header and a timestamp in the payload
>>> data. With this series applied, a script like this will produce
>>> identical kernels each time:
>>
>> Very nice stuff. Do you want to take the individual patches through one
>> of your trees, or do you mind if the subsystem maintainers take them
>> through theirs?
>
> But unfortunately, it is very easy to break this and for sure it'll be
> broken very soon.
I'm not so pessimistic. 34 patches and 57 files might sound like a lot,
but given that this has been accumulating since day one, the cleanup
should last for some time.
> So additionally, I'd suggest:
> 1. Instrument checkpatch.pl and make it err or warn on timestamps.
This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198
> 2. Probably instrument linux-next to rise a warning when people break
> this.
I'm not sure if Stephen has that much spare time, and I don't think it
is necessary. I think the checkpatch check is sufficient and I'll check
myself occasionally.
Michal
^ permalink raw reply
* [Patch] isdn: remove deprecated ISDN_CAPI_CAPIFS
From: Amerigo Wang @ 2011-04-06 9:05 UTC (permalink / raw)
To: netdev; +Cc: Karsten Keil, David S. Miller, Jan Kiszka, WANG Cong
Cc: Jan Kiszka <jan.kiszka@web.de>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: WANG Cong <amwang@redhat.com>
--
Documentation/feature-removal-schedule.txt | 10 --
drivers/isdn/capi/Kconfig | 15 --
drivers/isdn/capi/Makefile | 1 -
drivers/isdn/capi/capi.c | 4 +-
drivers/isdn/capi/capifs.c | 239 ----------------------------
drivers/isdn/capi/capifs.h | 28 ----
6 files changed, 1 insertions(+), 296 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 274b32d..e38ccae 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -425,16 +425,6 @@ Who: anybody or Florian Mickler <florian@mickler.org>
----------------------------
-What: capifs
-When: February 2011
-Files: drivers/isdn/capi/capifs.*
-Why: udev fully replaces this special file system that only contains CAPI
- NCCI TTY device nodes. User space (pppdcapiplugin) works without
- noticing the difference.
-Who: Jan Kiszka <jan.kiszka@web.de>
-
-----------------------------
-
What: KVM paravirt mmu host support
When: January 2011
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
diff --git a/drivers/isdn/capi/Kconfig b/drivers/isdn/capi/Kconfig
index a168e8a..15c3ffd 100644
--- a/drivers/isdn/capi/Kconfig
+++ b/drivers/isdn/capi/Kconfig
@@ -33,21 +33,6 @@ config ISDN_CAPI_CAPI20
standardized libcapi20 to access this functionality. You should say
Y/M here.
-config ISDN_CAPI_CAPIFS_BOOL
- bool "CAPI2.0 filesystem support (DEPRECATED)"
- depends on ISDN_CAPI_MIDDLEWARE && ISDN_CAPI_CAPI20
- help
- This option provides a special file system, similar to /dev/pts with
- device nodes for the special ttys established by using the
- middleware extension above.
- You no longer need this, udev fully replaces it. This feature is
- scheduled for removal.
-
-config ISDN_CAPI_CAPIFS
- tristate
- depends on ISDN_CAPI_CAPIFS_BOOL
- default ISDN_CAPI_CAPI20
-
config ISDN_CAPI_CAPIDRV
tristate "CAPI2.0 capidrv interface support"
depends on ISDN_I4L
diff --git a/drivers/isdn/capi/Makefile b/drivers/isdn/capi/Makefile
index 57123e3..4d5b4b7 100644
--- a/drivers/isdn/capi/Makefile
+++ b/drivers/isdn/capi/Makefile
@@ -7,7 +7,6 @@
obj-$(CONFIG_ISDN_CAPI) += kernelcapi.o
obj-$(CONFIG_ISDN_CAPI_CAPI20) += capi.o
obj-$(CONFIG_ISDN_CAPI_CAPIDRV) += capidrv.o
-obj-$(CONFIG_ISDN_CAPI_CAPIFS) += capifs.o
# Multipart objects.
diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
index 0d70883..b16e845 100644
--- a/drivers/isdn/capi/capi.c
+++ b/drivers/isdn/capi/capi.c
@@ -1514,9 +1514,7 @@ static int __init capi_init(void)
proc_init();
-#if defined(CONFIG_ISDN_CAPI_CAPIFS) || defined(CONFIG_ISDN_CAPI_CAPIFS_MODULE)
- compileinfo = " (middleware+capifs)";
-#elif defined(CONFIG_ISDN_CAPI_MIDDLEWARE)
+#if defined(CONFIG_ISDN_CAPI_MIDDLEWARE)
compileinfo = " (no capifs)";
#else
compileinfo = " (no middleware)";
diff --git a/drivers/isdn/capi/capifs.c b/drivers/isdn/capi/capifs.c
deleted file mode 100644
index b4faed7..0000000
--- a/drivers/isdn/capi/capifs.c
+++ /dev/null
@@ -1,239 +0,0 @@
-/* $Id: capifs.c,v 1.1.2.3 2004/01/16 21:09:26 keil Exp $
- *
- * Copyright 2000 by Carsten Paeth <calle@calle.de>
- *
- * Heavily based on devpts filesystem from H. Peter Anvin
- *
- * This software may be used and distributed according to the terms
- * of the GNU General Public License, incorporated herein by reference.
- *
- */
-
-#include <linux/fs.h>
-#include <linux/mount.h>
-#include <linux/slab.h>
-#include <linux/namei.h>
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/ctype.h>
-#include <linux/sched.h> /* current */
-
-#include "capifs.h"
-
-MODULE_DESCRIPTION("CAPI4Linux: /dev/capi/ filesystem");
-MODULE_AUTHOR("Carsten Paeth");
-MODULE_LICENSE("GPL");
-
-/* ------------------------------------------------------------------ */
-
-#define CAPIFS_SUPER_MAGIC (('C'<<8)|'N')
-
-static struct vfsmount *capifs_mnt;
-static int capifs_mnt_count;
-
-static struct {
- int setuid;
- int setgid;
- uid_t uid;
- gid_t gid;
- umode_t mode;
-} config = {.mode = 0600};
-
-/* ------------------------------------------------------------------ */
-
-static int capifs_remount(struct super_block *s, int *flags, char *data)
-{
- int setuid = 0;
- int setgid = 0;
- uid_t uid = 0;
- gid_t gid = 0;
- umode_t mode = 0600;
- char *this_char;
- char *new_opt = kstrdup(data, GFP_KERNEL);
-
- this_char = NULL;
- while ((this_char = strsep(&data, ",")) != NULL) {
- int n;
- char dummy;
- if (!*this_char)
- continue;
- if (sscanf(this_char, "uid=%i%c", &n, &dummy) == 1) {
- setuid = 1;
- uid = n;
- } else if (sscanf(this_char, "gid=%i%c", &n, &dummy) == 1) {
- setgid = 1;
- gid = n;
- } else if (sscanf(this_char, "mode=%o%c", &n, &dummy) == 1)
- mode = n & ~S_IFMT;
- else {
- kfree(new_opt);
- printk("capifs: called with bogus options\n");
- return -EINVAL;
- }
- }
-
- mutex_lock(&s->s_root->d_inode->i_mutex);
-
- replace_mount_options(s, new_opt);
- config.setuid = setuid;
- config.setgid = setgid;
- config.uid = uid;
- config.gid = gid;
- config.mode = mode;
-
- mutex_unlock(&s->s_root->d_inode->i_mutex);
-
- return 0;
-}
-
-static const struct super_operations capifs_sops =
-{
- .statfs = simple_statfs,
- .remount_fs = capifs_remount,
- .show_options = generic_show_options,
-};
-
-
-static int
-capifs_fill_super(struct super_block *s, void *data, int silent)
-{
- struct inode * inode;
-
- s->s_blocksize = 1024;
- s->s_blocksize_bits = 10;
- s->s_magic = CAPIFS_SUPER_MAGIC;
- s->s_op = &capifs_sops;
- s->s_time_gran = 1;
-
- inode = new_inode(s);
- if (!inode)
- goto fail;
- inode->i_ino = 1;
- inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
- inode->i_mode = S_IFDIR | S_IRUGO | S_IXUGO | S_IWUSR;
- inode->i_op = &simple_dir_inode_operations;
- inode->i_fop = &simple_dir_operations;
- inode->i_nlink = 2;
-
- s->s_root = d_alloc_root(inode);
- if (s->s_root)
- return 0;
-
- printk("capifs: get root dentry failed\n");
- iput(inode);
-fail:
- return -ENOMEM;
-}
-
-static struct dentry *capifs_mount(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data)
-{
- return mount_single(fs_type, flags, data, capifs_fill_super);
-}
-
-static struct file_system_type capifs_fs_type = {
- .owner = THIS_MODULE,
- .name = "capifs",
- .mount = capifs_mount,
- .kill_sb = kill_anon_super,
-};
-
-static struct dentry *new_ncci(unsigned int number, dev_t device)
-{
- struct super_block *s = capifs_mnt->mnt_sb;
- struct dentry *root = s->s_root;
- struct dentry *dentry;
- struct inode *inode;
- char name[10];
- int namelen;
-
- mutex_lock(&root->d_inode->i_mutex);
-
- namelen = sprintf(name, "%d", number);
- dentry = lookup_one_len(name, root, namelen);
- if (IS_ERR(dentry)) {
- dentry = NULL;
- goto unlock_out;
- }
-
- if (dentry->d_inode) {
- dput(dentry);
- dentry = NULL;
- goto unlock_out;
- }
-
- inode = new_inode(s);
- if (!inode) {
- dput(dentry);
- dentry = NULL;
- goto unlock_out;
- }
-
- /* config contents is protected by root's i_mutex */
- inode->i_uid = config.setuid ? config.uid : current_fsuid();
- inode->i_gid = config.setgid ? config.gid : current_fsgid();
- inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
- inode->i_ino = number + 2;
- init_special_inode(inode, S_IFCHR|config.mode, device);
-
- d_instantiate(dentry, inode);
- dget(dentry);
-
-unlock_out:
- mutex_unlock(&root->d_inode->i_mutex);
-
- return dentry;
-}
-
-struct dentry *capifs_new_ncci(unsigned int number, dev_t device)
-{
- struct dentry *dentry;
-
- if (simple_pin_fs(&capifs_fs_type, &capifs_mnt, &capifs_mnt_count) < 0)
- return NULL;
-
- dentry = new_ncci(number, device);
- if (!dentry)
- simple_release_fs(&capifs_mnt, &capifs_mnt_count);
-
- return dentry;
-}
-
-void capifs_free_ncci(struct dentry *dentry)
-{
- struct dentry *root = capifs_mnt->mnt_sb->s_root;
- struct inode *inode;
-
- if (!dentry)
- return;
-
- mutex_lock(&root->d_inode->i_mutex);
-
- inode = dentry->d_inode;
- if (inode) {
- drop_nlink(inode);
- d_delete(dentry);
- dput(dentry);
- }
- dput(dentry);
-
- mutex_unlock(&root->d_inode->i_mutex);
-
- simple_release_fs(&capifs_mnt, &capifs_mnt_count);
-}
-
-static int __init capifs_init(void)
-{
- return register_filesystem(&capifs_fs_type);
-}
-
-static void __exit capifs_exit(void)
-{
- unregister_filesystem(&capifs_fs_type);
-}
-
-EXPORT_SYMBOL(capifs_new_ncci);
-EXPORT_SYMBOL(capifs_free_ncci);
-
-module_init(capifs_init);
-module_exit(capifs_exit);
diff --git a/drivers/isdn/capi/capifs.h b/drivers/isdn/capi/capifs.h
deleted file mode 100644
index e193d11..0000000
--- a/drivers/isdn/capi/capifs.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/* $Id: capifs.h,v 1.1.2.2 2004/01/16 21:09:26 keil Exp $
- *
- * Copyright 2000 by Carsten Paeth <calle@calle.de>
- *
- * This software may be used and distributed according to the terms
- * of the GNU General Public License, incorporated herein by reference.
- *
- */
-
-#include <linux/dcache.h>
-
-#if defined(CONFIG_ISDN_CAPI_CAPIFS) || defined(CONFIG_ISDN_CAPI_CAPIFS_MODULE)
-
-struct dentry *capifs_new_ncci(unsigned int num, dev_t device);
-void capifs_free_ncci(struct dentry *dentry);
-
-#else
-
-static inline struct dentry *capifs_new_ncci(unsigned int num, dev_t device)
-{
- return NULL;
-}
-
-static inline void capifs_free_ncci(struct dentry *dentry)
-{
-}
-
-#endif
^ permalink raw reply related
* Re: [PATCH 00/34] Make kernel build deterministic
From: Ingo Molnar @ 2011-04-06 9:01 UTC (permalink / raw)
To: Michal Marek
Cc: anil_ravindranath, mchehab, benh, x86, mac, aacraid, linux-mtd,
allan.stephens, hpa, netdev, t.sailer, gwingerde, IvDoorn, elf,
cluster-devel, ccaulfie, mingo, dougthompson, linux-usb,
linux-media, arnaud.giersch, linux-kbuild, teigland, tony.olech,
apw, linux-hams, tglx, swhiteho, linux-arm-kernel, linux-edac,
jon.maloy, linux-scsi, linuxppc-dev, gregkh, linux-wireless,
linux-kernel
In-Reply-To: <1302015561-21047-1-git-send-email-mmarek@suse.cz>
* Michal Marek <mmarek@suse.cz> wrote:
>
> Hi,
>
> this series makes it possible to build bit-identical kernel image and
> modules from identical sources. Of course the build is already
> deterministic in terms of behavior of the code, but the various
> timestamps embedded in the object files make it hard to compare two
> builds, for instance to verify that a makefile cleanup didn't
> accidentally change something. A prime example is /proc/config.gz, which
> has both a timestamp in the gzip header and a timestamp in the payload
> data. With this series applied, a script like this will produce
> identical kernels each time:
>
> #!/bin/bash
> rm -rf /dev/shm/{source,build}{,1,2}
> export KCONFIG_NOTIMESTAMP=1
> export KBUILD_BUILD_TIMESTAMP='Sun May 1 12:00:00 CEST 2011'
> export KBUILD_BUILD_USER=user
> export KBUILD_BUILD_HOST=host
> export ROOT_DEV=FLOPPY
> for i in 1 2; do
> mkdir /dev/shm/source
> # randomize the inode order just for fun
> git ls-tree -r -z --name-only HEAD | sort -R -z | xargs -0 \
> cp --parents --target=/dev/shm/source
> pushd /dev/shm/source
> mkdir /dev/shm/build
> >/dev/shm/build/all.config
> for opt in GCOV_KERNEL UBIFS_FS_DEBUG; do
> echo "# CONFIG_$opt is not set" >>"/dev/shm/build"/all.config
> done
> make O="/dev/shm/build" KCONFIG_ALLCONFIG=1 allmodconfig
> make O="/dev/shm/build" -j64
> popd
> mv /dev/shm/source /dev/shm/source$i
> mv /dev/shm/build /dev/shm/build$i
> done
> diff -rq /dev/shm/build{1,2}
Nice!
Acked-by: Ingo Molnar <mingo@elte.hu>
> Unfortunatelly, this cannot be used to validate indentation-only
> patches, even if CONFIG_DEBUG_INFO is turned off. This is because of the
> __FILE__ and __LINE__ macros used in many places. For the same reason,
> the source and build directory needs to be the same, otherwise the
> results will differ.
Nor can it be used to validate untrusted patches in general: a subtle change
might be introduced in a piece of code that is dependent on a .config detail
that is off for that particular build.
But in the common case it's nice to be able to have deterministic/reproducable
builds.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Ingo Molnar @ 2011-04-06 8:57 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: anil_ravindranath, mchehab, benh, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, tipc-discussion, dwmw2,
linux-media, jon.maloy, arnaud.giersch, linux-kbuild, IvDoorn,
teigland, tony.olech, apw, linux-hams, tglx, swhiteho,
linux-arm-kernel, linux-edac, Michal Marek, linux-scsi, netdev,
Greg KH, linux-wireless
In-Reply-To: <1302031447.2608.41.camel@koala>
* Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
> > On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
> > >
> > > Hi,
> > >
> > > this series makes it possible to build bit-identical kernel image and
> > > modules from identical sources. Of course the build is already
> > > deterministic in terms of behavior of the code, but the various
> > > timestamps embedded in the object files make it hard to compare two
> > > builds, for instance to verify that a makefile cleanup didn't
> > > accidentally change something. A prime example is /proc/config.gz, which
> > > has both a timestamp in the gzip header and a timestamp in the payload
> > > data. With this series applied, a script like this will produce
> > > identical kernels each time:
> >
> > Very nice stuff. Do you want to take the individual patches through one
> > of your trees, or do you mind if the subsystem maintainers take them
> > through theirs?
>
> But unfortunately, it is very easy to break this and for sure it'll be
> broken very soon.
>
> So additionally, I'd suggest:
> 1. Instrument checkpatch.pl and make it err or warn on timestamps.
See the grandparent mail:
checkpatch: Warn about usage of __DATE__, __TIME__ and __TIMESTAMP__
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] Fix panic in ip6_pol_route
From: David Miller @ 2011-04-06 8:21 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <OFCD49CDC4.C2B9408D-ON6525786A.002C2B92-6525786A.002CBDC6@in.ibm.com>
From: Krishna Kumar2 <krkumar2@in.ibm.com>
Date: Wed, 6 Apr 2011 13:40:57 +0530
> Is it better to disallow configuring vlan on lo?
Yes, but the real stinker to me is that the IFF_LOOPBACK flag
propagates to the VLAN device, that really seems even more
wrong to me.
^ permalink raw reply
* Re: [PATCH] Fix panic in ip6_pol_route
From: Krishna Kumar2 @ 2011-04-06 8:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110406.004043.193732725.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 04/06/2011 01:10:43 PM:
> > The fix is to not update ip6_null_entry for a vlan device. Please
> > review.
>
> This is just rediculious.
>
> Configuring a vlan on loopback is stupid.
>
> Having IFF_LOOPBACK be set on a loopback device is even more
> stupid.
>
> So fix one of those two things, otherwise we'll just add a million
> tests over time to this conditional.
We had asked the test team for the reason for this test case:
"I suspect that the use of the loopback, is simply due to some of
our images being very limited and the automated test needed an
interface that it could assume would always exist"
Is it better to disallow configuring vlan on lo?
thanks,
- KK
^ permalink raw reply
* Re: [PATCH 12/34] isdn/diva: Drop __TIME__ usage
From: Michal Marek @ 2011-04-06 8:06 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Armin Schindler, linux-kbuild, linux-kernel, netdev
In-Reply-To: <20627.1302031056@localhost>
On 5.4.2011 21:17, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 05 Apr 2011 17:10:34 +0200, Armin Schindler said:
>> On Tue, 5 Apr 2011, Michal Marek wrote:
>>> The kernel already prints its build timestamp during boot, no need to
>>> repeat it in random drivers and produce different object files each
>>> time.
>>
>> The module can be build separately from the kernel, therefore it can have
>> an own build timestamp.
>
> If the same code is being built as an out-of-tree module, that's a possibly
> good reason for a code version variable, but what does the build timestamp
> actually tell you? If you already know foo_driver.c version 0.814 was buiilt
> against 2.6.41-rc2, in what cases does it matter if the compile was on Tuesday
> or Thursday - especially since an 'ls -l foo_driver.ko' will tell you? If it's
> a matter of "the target .config changed on Wednesday", a build timestamp still
> doesn't help over 'ls -l'.
Exactly. Build timestamps are only a poor substitute for proper version
tracking. If you want to be able to reproduce the build of a binary, you
want it to embed some source revision, not the date when you built it.
For the kernel, you can use KBUILD_BUILD_TIMESTAMP=<source timestamp>,
for out-of-tree modules, you need to come up with something own.
Michal
^ permalink raw reply
* Re: [PATCH] Fix panic in ip6_pol_route
From: David Miller @ 2011-04-06 7:41 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <20110406.004043.193732725.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 06 Apr 2011 00:40:43 -0700 (PDT)
> Having IFF_LOOPBACK be set on a loopback device is even more
> stupid.
I mean "VLAN device" here of course.
^ permalink raw reply
* Re: [PATCH] Fix panic in ip6_pol_route
From: David Miller @ 2011-04-06 7:40 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <20110406064504.30691.36599.sendpatchset@krkumar2.in.ibm.com>
From: Krishna Kumar <krkumar2@in.ibm.com>
Date: Wed, 06 Apr 2011 12:15:04 +0530
> The fix is to not update ip6_null_entry for a vlan device. Please
> review.
This is just rediculious.
Configuring a vlan on loopback is stupid.
Having IFF_LOOPBACK be set on a loopback device is even more
stupid.
So fix one of those two things, otherwise we'll just add a million
tests over time to this conditional.
^ permalink raw reply
* Re: shutdown oops in xt_compat_calc_jump
From: Florian Westphal @ 2011-04-06 7:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Florian Westphal, Patrick McHardy, dann frazier, netdev,
netfilter-devel@vger.kernel.org
In-Reply-To: <1302064927.3020.1.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 06 avril 2011 à 01:42 +0200, Florian Westphal a écrit :
>
> > using ninfo->nentries does not always work because ebtables compat
> > can call xt_compat_add_offset() more than once per entry.
> >
>
> With same offset ? Maybe we should tweak xt_compat_add_offset() to
> detect this and add delta to previous delta in this case
No, different offset (it calls it per match/watcher/target instead
of summing up the match/target deltas and using that in a single
add_offset call).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH/RFC] can: mcp251x: Allow pass IRQ flags through platform data.
From: Kurt Van Dijck @ 2011-04-06 7:14 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1302023321-25182-1-git-send-email-eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
On Tue, Apr 05, 2011 at 07:08:41PM +0200, Enric Balletbo i Serra wrote:
> ret = request_threaded_irq(spi->irq, NULL, mcp251x_can_ist,
> - IRQF_TRIGGER_FALLING, DEVICE_NAME, priv);
> + pdata->irq_flags ? pdata->irq_flags : IRQF_TRIGGER_FALLING,
> + DEVICE_NAME, priv);
IMHO, doing like this looks just a tiny bit cleaner
> + pdata->irq_flags ?: IRQF_TRIGGER_FALLING,
> + DEVICE_NAME, priv);
That's really the only remark :-)
Regards,
Kurt
^ permalink raw reply
* Re: [PATCH/RFC] can: mcp251x: Allow pass IRQ flags through platform data.
From: Marc Kleine-Budde @ 2011-04-06 6:57 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1302023321-25182-1-git-send-email-eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 897 bytes --]
On 04/05/2011 07:08 PM, Enric Balletbo i Serra wrote:
> When an interrupt occurs, the INT pin is driven low by the
> MCP251x controller (falling edge) but in some cases the INT
> pin can be connected to the MPU through a transistor or level
> translator which inverts this signal. In this case interrupt
> should be configured in rising edge.
>
> This patch adds support to pass the IRQ flags via
> mcp251x_platform_data.
>
> Signed-off-by: Enric Balletbo i Serra <eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
looks good
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH/RFC] can: mcp251x: Allow pass IRQ flags through platform data.
From: Wolfgang Grandegger @ 2011-04-06 6:47 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1302023321-25182-1-git-send-email-eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
On 04/05/2011 07:08 PM, Enric Balletbo i Serra wrote:
> When an interrupt occurs, the INT pin is driven low by the
> MCP251x controller (falling edge) but in some cases the INT
> pin can be connected to the MPU through a transistor or level
> translator which inverts this signal. In this case interrupt
> should be configured in rising edge.
>
> This patch adds support to pass the IRQ flags via
> mcp251x_platform_data.
>
> Signed-off-by: Enric Balletbo i Serra <eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks,
Wolfgang.
^ permalink raw reply
* [PATCH] Fix panic in ip6_pol_route
From: Krishna Kumar @ 2011-04-06 6:45 UTC (permalink / raw)
To: davem; +Cc: netdev, Krishna Kumar
Vlan testing panic'd with this script:
# vconfig add lo 42
# vconfig rem lo.42
# ifdown lo
# ifup lo
# ping6 fe80::%eth0
BUG: unable to handle kernel NULL pointer dereference at 0000000000000106
IP: [<ffffffffa018efd3>] ip6_pol_route+0x233/0x360 [ipv6]
PGD 1c1a8067 PUD 1cb2a067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/net/lo.42/addr_len
CPU 0
Modules linked in: garp stp llc ip6table_filter ip6_tables iptable_filter
ip_tables ebtable_nat ebtables autofs4 sunrpc ipv6 virtio_net virtio_balloon
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer
snd soundcore snd_page_alloc i2c_piix4 i2c_core sg ext3 jbd mbcache sd_mod
crc_t10dif virtio_pci virtio_ring virtio pata_acpi ata_generic ata_piix dm_mod
[last unloaded: 8021q]
Modules linked in: garp stp llc ip6table_filter ip6_tables iptable_filter
ip_tables ebtable_nat ebtables autofs4 sunrpc ipv6 virtio_net virtio_balloon
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer
snd soundcore snd_page_alloc i2c_piix4 i2c_core sg ext3 jbd mbcache sd_mod
crc_t10dif virtio_pci virtio_ring virtio pata_acpi ata_generic ata_piix dm_mod
[last unloaded: 8021q]
Pid: 1752, comm: ping6 Not tainted 2.6.32-71.18.5.mcp7.x86_64 #1 Bochs
RIP: 0010:[<ffffffffa018efd3>] [<ffffffffa018efd3>] ip6_pol_route+0x233/0x360
[ipv6]
RSP: 0018:ffff88001fad1ae8 EFLAGS: 00010296
RAX: ffff88001fb23800 RBX: ffff88001fb23800 RCX: ffff88001fb23800
RDX: ffffffff81c99600 RSI: 0000000000000002 RDI: ffff88001fb23800
RBP: ffff88001fad1b78 R08: 000000000000000b R09: ffff88001fb23910
R10: 0000000000000000 R11: ffff88001fad1da4 R12: 00000000ffffffff
R13: 0000000000000003 R14: 0000000000000002 R15: ffff88001fad1b44
FS: 00007f89ed64a700(0000) GS:ffff880001e00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000106 CR3: 000000001cb1e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ping6 (pid: 1752, threadinfo ffff88001fad0000, task ffff88001cadeaf0)
Stack:
000000001cadeaf0 ffff88001fa84254 0000000100000003 ffff88001fa84258
<0> ffff88001fad1db4 ffff88001fad1da4 0000000200000002 ffffffff81c99600
<0> ffff88001fa84258 ffff88001fb23800 ffffea0000000041 ffffffff00000000
Call Trace:
[<ffffffffa018f116>] ip6_pol_route_output+0x16/0x20 [ipv6]
[<ffffffffa01b2601>] fib6_rule_action+0xd1/0x1f0 [ipv6]
[<ffffffffa018f100>] ? ip6_pol_route_output+0x0/0x20 [ipv6]
[<ffffffff8142205d>] fib_rules_lookup+0xbd/0x110
[<ffffffffa01b2755>] fib6_rule_lookup+0x35/0xa0 [ipv6]
[<ffffffffa018f100>] ? ip6_pol_route_output+0x0/0x20 [ipv6]
[<ffffffffa018d2c5>] ip6_route_output+0xa5/0xc0 [ipv6]
[<ffffffffa0180773>] ip6_dst_lookup_tail+0x223/0x250 [ipv6]
[<ffffffffa0197b60>] ? ipv6_rcv_saddr_equal+0x0/0x1f0 [ipv6]
[<ffffffffa01808b5>] ip6_dst_lookup+0x15/0x20 [ipv6]
[<ffffffffa01ab493>] ip6_datagram_connect+0x323/0x630 [ipv6]
[<ffffffff814c93cb>] ? _spin_unlock_bh+0x1b/0x20
[<ffffffff813ff697>] ? release_sock+0xb7/0xd0
[<ffffffff8146f5ec>] inet_dgram_connect+0x2c/0x80
[<ffffffff813fd1c7>] sys_connect+0xd7/0xf0
[<ffffffff810d3872>] ? audit_syscall_entry+0x272/0x2a0
[<ffffffff81013172>] system_call_fastpath+0x16/0x1b
Code: 28 48 8b 4d b8 48 8b 55 a8 48 8b 41 18 48 8b 80 08 04 00 00 4c 8b 80 c0
03 00 00 48 8b 82 c0 03 00 00 4c 39 c0 0f 84 35 ff ff ff <41> f6 80 fb 00 00 00
01 0f 85 aa 00 00 00 3e 41 ff 80 c0 00 00
RIP [<ffffffffa018efd3>] ip6_pol_route+0x233/0x360 [ipv6]
RSP <ffff88001fad1ae8>
CR2: 0000000000000106
The fix is to not update ip6_null_entry for a vlan device. Please
review.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
---
net/ipv6/route.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -ruNp org/net/ipv6/route.c new/net/ipv6/route.c
--- org/net/ipv6/route.c 2011-03-29 19:35:21.000000000 +0530
+++ new/net/ipv6/route.c 2011-03-29 19:36:05.000000000 +0530
@@ -2488,7 +2488,8 @@ static int ip6_route_dev_notify(struct n
struct net_device *dev = (struct net_device *)data;
struct net *net = dev_net(dev);
- if (event == NETDEV_REGISTER && (dev->flags & IFF_LOOPBACK)) {
+ if (event == NETDEV_REGISTER && (dev->flags & IFF_LOOPBACK) &&
+ !(dev->priv_flags & IFF_802_1Q_VLAN)) {
net->ipv6.ip6_null_entry->dst.dev = dev;
net->ipv6.ip6_null_entry->rt6i_idev = in6_dev_get(dev);
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
^ permalink raw reply
* Re: [PATCH] bonding-tlb: better balance when choosing slaves
From: Weiping Pan @ 2011-04-06 5:31 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Andy Gospodarek (supporter:BONDING DRIVER), netdev, linux-kernel
In-Reply-To: <3084.1302065172@death>
On 04/06/2011 12:46 PM, Jay Vosburgh wrote:
> Weiping Pan<panweiping3@gmail.com> wrote:
>
>> On 04/03/2011 02:25 AM, Jay Vosburgh wrote:
>>>> tlb_get_least_loaded_slave() always chooses slave from
>>>> bonding->first_slave, that gives the beginnig slaves more chances to be used.
>>>>
>>>> Let tlb_get_least_loaded_slave() chooses slave from a random positon in the
>>>> slave list, make all slaves transmit packets more balanced.
>>> If outgoing traffic is not being starved (i.e., connections are
>>> being balanced such that they are stacking up on one slave but
>>> under-utilizing another), then I don't understand what benefit this has.
>>>
>>> There is already some degree of randomness, as peers will be
>>> assigned in the order that packets are transmitted to them after each
>>> rebalance. The busiest peers will tend to be on the earlier slaves, and
>>> vice versa, but I'm not sure this is a bad thing.
>>>
>>> Does this have any real gain other than making the rx/tx
>>> statistics for the slaves more equal over time?
>>>
>>> I haven't measured it, but I would expect that for small numbers
>>> of peers, having them tend to stay on the same slaves over time is
>>> probably a good thing.
>> modprobe bonding mode=balance-tlb miimon=100
>> ifconfig bond0 192.168.1.2 netmask 255.255.255.0 up
>> ifenslave bond0 eth0
>> ifenslave bond0 eth1
>> ifenslave bond0 eth2
>> ping 192.168.1.100 -A -s 10240
>>
>> I find that bonding will always use eth0 and eth1, it never uses eth2,
>> because tlb_get_least_loaded_slave() always chooses slave from
>> bonding->first_slave, that gives the beginnig slaves more chances to be
>> used.
>>
>> Do you think this is a problem ?
> Not for this test case, no.
>
> On the other hand, if you run three pings concurrently to three
> different destinations and it still never uses eth2, then that might be
> something to look into.
>
>> Does it has conflicts with the meaning of balance and reblance?
> Not really; with only one active flow, there isn't really any
> advantage to moving it around. The balance and rebalance activity
> becomes more interesting when the traffic volume and number of
> destinations is larger.
>
> -J
ok, i agree with you.
thanks
Weiping Pan
>>>> Signed-off-by: Weiping Pan(潘卫平)<panweiping3@gmail.com>
>>>> ---
>>>> drivers/net/bonding/bond_alb.c | 17 +++++++++++++++--
>>>> 1 files changed, 15 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>>>> index 9bc5de3..9fa64b0 100644
>>>> --- a/drivers/net/bonding/bond_alb.c
>>>> +++ b/drivers/net/bonding/bond_alb.c
>>>> @@ -36,6 +36,7 @@
>>>> #include<linux/if_bonding.h>
>>>> #include<linux/if_vlan.h>
>>>> #include<linux/in.h>
>>>> +#include<linux/random.h>
>>>> #include<net/ipx.h>
>>>> #include<net/arp.h>
>>>> #include<net/ipv6.h>
>>>> @@ -206,15 +207,27 @@ static long long compute_gap(struct slave *slave)
>>>> /* Caller must hold bond lock for read */
>>>> static struct slave *tlb_get_least_loaded_slave(struct bonding *bond)
>>>> {
>>>> - struct slave *slave, *least_loaded;
>>>> + struct slave *slave, *least_loaded, *start_slave;
>>>> long long max_gap;
>>>> int i;
>>>> + u8 n;
>>>>
>>>> least_loaded = NULL;
>>>> + start_slave = bond->first_slave;
>>>> max_gap = LLONG_MIN;
>>>> +
>>>> + get_random_bytes(&n, 1);
>>>> +
>>>> + if (bond->slave_cnt == 0)
>>>> + return NULL;
>>>> + n = n % bond->slave_cnt;
>>>> +
>>>> + for (i=0; i<n; ++i) {
>>>> + start_slave = start_slave->next;
>>>> + }
>>>>
>>>> /* Find the slave with the largest gap */
>>>> - bond_for_each_slave(bond, slave, i) {
>>>> + bond_for_each_slave_from(bond, slave, i, start_slave) {
>>>> if (SLAVE_IS_OK(slave)) {
>>>> long long gap = compute_gap(slave);
>>>>
>>>> --
>>>> 1.7.4
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH v2 net-next 3/9] tg3: Reintroduce 5717_PLUS
From: Joe Perches @ 2011-04-06 5:30 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev
In-Reply-To: <1302049371-13799-4-git-send-email-mcarlson@broadcom.com>
On Tue, 2011-04-05 at 17:22 -0700, Matt Carlson wrote:
> This patch reintroduces the TG3_FLG3_5717_PLUS to identify 5717 and
> later devices.
[]
> @@ -13427,8 +13422,7 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
[]
> + if (tp->tg3_flags3 & TG3_FLG3_5717_PLUS)
> tp->tg3_flags3 |= TG3_FLG3_LRG_PROD_RING_CAP;
This seems redundant. Maybe consolidate to just
TG3_FLG3_5717_PLUS and remove LRG_PROD_RING_CAP?
I don't know if these attributes really are linked.
Another option may be to use DECLARE_BITMAP
and set_bit/test_bit so there's no real need
to use FLAG/FLG2/FLG3, etc.
^ permalink raw reply
* Re: [PATCH] bonding-tlb: better balance when choosing slaves
From: Jay Vosburgh @ 2011-04-06 4:46 UTC (permalink / raw)
To: Weiping Pan
Cc: Andy Gospodarek (supporter:BONDING DRIVER), netdev, linux-kernel
In-Reply-To: <4D9BD1A9.1040402@gmail.com>
Weiping Pan <panweiping3@gmail.com> wrote:
>On 04/03/2011 02:25 AM, Jay Vosburgh wrote:
>>> tlb_get_least_loaded_slave() always chooses slave from
>>> bonding->first_slave, that gives the beginnig slaves more chances to be used.
>>>
>>> Let tlb_get_least_loaded_slave() chooses slave from a random positon in the
>>> slave list, make all slaves transmit packets more balanced.
>> If outgoing traffic is not being starved (i.e., connections are
>> being balanced such that they are stacking up on one slave but
>> under-utilizing another), then I don't understand what benefit this has.
>>
>> There is already some degree of randomness, as peers will be
>> assigned in the order that packets are transmitted to them after each
>> rebalance. The busiest peers will tend to be on the earlier slaves, and
>> vice versa, but I'm not sure this is a bad thing.
>>
>> Does this have any real gain other than making the rx/tx
>> statistics for the slaves more equal over time?
>>
>> I haven't measured it, but I would expect that for small numbers
>> of peers, having them tend to stay on the same slaves over time is
>> probably a good thing.
>modprobe bonding mode=balance-tlb miimon=100
>ifconfig bond0 192.168.1.2 netmask 255.255.255.0 up
>ifenslave bond0 eth0
>ifenslave bond0 eth1
>ifenslave bond0 eth2
>ping 192.168.1.100 -A -s 10240
>
>I find that bonding will always use eth0 and eth1, it never uses eth2,
>because tlb_get_least_loaded_slave() always chooses slave from
>bonding->first_slave, that gives the beginnig slaves more chances to be
>used.
>
>Do you think this is a problem ?
Not for this test case, no.
On the other hand, if you run three pings concurrently to three
different destinations and it still never uses eth2, then that might be
something to look into.
>Does it has conflicts with the meaning of balance and reblance?
Not really; with only one active flow, there isn't really any
advantage to moving it around. The balance and rebalance activity
becomes more interesting when the traffic volume and number of
destinations is larger.
-J
>>> Signed-off-by: Weiping Pan(潘卫平)<panweiping3@gmail.com>
>>> ---
>>> drivers/net/bonding/bond_alb.c | 17 +++++++++++++++--
>>> 1 files changed, 15 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>>> index 9bc5de3..9fa64b0 100644
>>> --- a/drivers/net/bonding/bond_alb.c
>>> +++ b/drivers/net/bonding/bond_alb.c
>>> @@ -36,6 +36,7 @@
>>> #include<linux/if_bonding.h>
>>> #include<linux/if_vlan.h>
>>> #include<linux/in.h>
>>> +#include<linux/random.h>
>>> #include<net/ipx.h>
>>> #include<net/arp.h>
>>> #include<net/ipv6.h>
>>> @@ -206,15 +207,27 @@ static long long compute_gap(struct slave *slave)
>>> /* Caller must hold bond lock for read */
>>> static struct slave *tlb_get_least_loaded_slave(struct bonding *bond)
>>> {
>>> - struct slave *slave, *least_loaded;
>>> + struct slave *slave, *least_loaded, *start_slave;
>>> long long max_gap;
>>> int i;
>>> + u8 n;
>>>
>>> least_loaded = NULL;
>>> + start_slave = bond->first_slave;
>>> max_gap = LLONG_MIN;
>>> +
>>> + get_random_bytes(&n, 1);
>>> +
>>> + if (bond->slave_cnt == 0)
>>> + return NULL;
>>> + n = n % bond->slave_cnt;
>>> +
>>> + for (i=0; i<n; ++i) {
>>> + start_slave = start_slave->next;
>>> + }
>>>
>>> /* Find the slave with the largest gap */
>>> - bond_for_each_slave(bond, slave, i) {
>>> + bond_for_each_slave_from(bond, slave, i, start_slave) {
>>> if (SLAVE_IS_OK(slave)) {
>>> long long gap = compute_gap(slave);
>>>
>>> --
>>> 1.7.4
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: shutdown oops in xt_compat_calc_jump
From: Eric Dumazet @ 2011-04-06 4:42 UTC (permalink / raw)
To: Florian Westphal
Cc: Patrick McHardy, dann frazier, netdev,
netfilter-devel@vger.kernel.org
In-Reply-To: <20110405234216.GD32579@Chamillionaire.breakpoint.cc>
Le mercredi 06 avril 2011 à 01:42 +0200, Florian Westphal a écrit :
> using ninfo->nentries does not always work because ebtables compat
> can call xt_compat_add_offset() more than once per entry.
>
With same offset ? Maybe we should tweak xt_compat_add_offset() to
detect this and add delta to previous delta in this case
> That is of course not necessary; the ebt compat code should do better.
> I plan to look at this in the evening.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PatchV2 : PL25A1 Support - 1/3] whitespace
From: Simon Wood @ 2011-04-06 4:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Brownell, Sergei Shtylyov, linux-usb, netdev, linux-kernel,
davem, Simon Wood
In-Reply-To: <1301456667-1648-1-git-send-email-simon@mungewell.org>
Clear up a couple of instances of incorrect whitespace
Signed-off-by: Simon Wood <simon@mungewell.org>
---
drivers/net/usb/plusb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 08ad269..30578ea 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -134,13 +134,13 @@ static struct usb_driver plusb_driver = {
static int __init plusb_init(void)
{
- return usb_register(&plusb_driver);
+ return usb_register(&plusb_driver);
}
module_init(plusb_init);
static void __exit plusb_exit(void)
{
- usb_deregister(&plusb_driver);
+ usb_deregister(&plusb_driver);
}
module_exit(plusb_exit);
--
1.7.0.4
^ permalink raw reply related
* [PatchV2 : PL25A1 Support - 3/3] reset_debug
From: Simon Wood @ 2011-04-06 4:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Brownell, Sergei Shtylyov, linux-usb, netdev, linux-kernel,
davem, Simon Wood
In-Reply-To: <1301456667-1648-1-git-send-email-simon@mungewell.org>
Adds some debug in the event that reseting chip fails for some reason
Signed-off-by: Simon Wood <simon@mungewell.org>
---
drivers/net/usb/plusb.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index b9649e0..11ff297 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -94,11 +94,15 @@ pl_set_QuickLink_features(struct usbnet *dev, int val)
static int pl_reset(struct usbnet *dev)
{
+ int status;
+
/* some units seem to need this reset, others reject it utterly.
* FIXME be more like "naplink" or windows drivers.
*/
- (void) pl_set_QuickLink_features(dev,
+ status = pl_set_QuickLink_features(dev,
PL_S_EN|PL_RESET_OUT|PL_RESET_IN|PL_PEER_E);
+ if (status != 0 && netif_msg_probe(dev))
+ netif_dbg(dev, link, dev->net, "pl_reset --> %d\n", status);
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* [PatchV2 : PL25A1 Support - 2/3] add_pl25a1
From: Simon Wood @ 2011-04-06 4:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Brownell, Sergei Shtylyov, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Simon Wood
In-Reply-To: <1301456667-1648-1-git-send-email-simon-wM4F9T/ekXmXDw4h08c5KA@public.gmane.org>
This patch adds the USB ID's for the PL25A1, which is used in the
Belkin 'Windows Easy Transfer' cables.
Signed-off-by: Simon Wood <simon-wM4F9T/ekXmXDw4h08c5KA@public.gmane.org>
---
drivers/net/usb/Kconfig | 2 +-
drivers/net/usb/plusb.c | 22 ++++++++++++++++++++--
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 6f600cc..85fec06 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -258,7 +258,7 @@ config USB_NET_NET1080
optionally with LEDs that indicate traffic
config USB_NET_PLUSB
- tristate "Prolific PL-2301/2302 based cables"
+ tristate "Prolific PL-2301/2302/25A1 based cables"
# if the handshake/init/reset problems, from original 'plusb',
# are ever resolved ... then remove "experimental"
depends on USB_USBNET && EXPERIMENTAL
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 30578ea..b9649e0 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -45,6 +45,14 @@
* seems to get wedged under load. Prolific docs are weak, and
* don't identify differences between PL2301 and PL2302, much less
* anything to explain the different PL2302 versions observed.
+ *
+ * NOTE: pl2501 has several modes, including pl2301 and pl2302
+ * compatibility. Some docs suggest the difference between 2301
+ * and 2302 is only to make MS-Windows use a different driver...
+ *
+ * pl25a1 glue based on patch from Tony Gibbs. Prolific "docs" on
+ * this chip are as usual incomplete about what control messages
+ * are supported.
*/
/*
@@ -95,7 +103,7 @@ static int pl_reset(struct usbnet *dev)
}
static const struct driver_info prolific_info = {
- .description = "Prolific PL-2301/PL-2302",
+ .description = "Prolific PL-2301/PL-2302/PL-25A1",
.flags = FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset = pl_reset,
@@ -111,6 +119,7 @@ static const struct driver_info prolific_info = {
static const struct usb_device_id products [] = {
+/* full speed cables */
{
USB_DEVICE(0x067b, 0x0000), // PL-2301
.driver_info = (unsigned long) &prolific_info,
@@ -119,6 +128,15 @@ static const struct usb_device_id products [] = {
.driver_info = (unsigned long) &prolific_info,
},
+/* high speed cables */
+{
+ USB_DEVICE(0x067b, 0x25a1), /* PL-25A1, no eeprom */
+ .driver_info = (unsigned long) &prolific_info,
+}, {
+ USB_DEVICE(0x050d, 0x258a), /* Belkin F5U258/F5U279 (PL-25A1) */
+ .driver_info = (unsigned long) &prolific_info,
+},
+
{ }, // END
};
MODULE_DEVICE_TABLE(usb, products);
@@ -145,5 +163,5 @@ static void __exit plusb_exit(void)
module_exit(plusb_exit);
MODULE_AUTHOR("David Brownell");
-MODULE_DESCRIPTION("Prolific PL-2301/2302 USB Host to Host Link Driver");
+MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link Driver");
MODULE_LICENSE("GPL");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: mourning the loss of David Brownell
From: Jidong Xiao @ 2011-04-06 3:35 UTC (permalink / raw)
To: Sarah Sharp
Cc: Alan Stern, Greg KH, Oliver Neukum, Bill Gatliff,
Kernel development list, USB list, linux-omap, spi-devel-general,
netdev
In-Reply-To: <20110406002144.GC6983@xanatos>
On Tue, Apr 5, 2011 at 8:21 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Tue, Apr 05, 2011 at 02:10:53PM -0400, Alan Stern wrote:
>> On Mon, 4 Apr 2011, Greg KH wrote:
>>
>> > As I have seen this tangentally mentioned already a few times
>> > publically, I figured it warranted it's own announcement now.
>> >
>> > Linux has lost a great developer with the passing of David Brownell
>> > recently and he will be greatly missed.
>>
>> David made contributions to a large number of areas in the Linux
>> kernel. Even a quick look through MAINTAINERS will show that he worked
>> on USB controllers (OHCI, EHCI, OMAP and others), USB gadgets, USB
>> networking, and SPI. He was influential in the core USB design (the
>> HCD "glue" layer and the scatter-gather library) and the development of
>> Power Management (system sleep and the USB PM implementation). His
>> designs were elegant and his code was always a pleasure to read.
>>
>> He also was a big help to me personally, assisting in my initial entry
>> to USB core development. And he was the first person I met at the
>> first Linux conference I attended. I too will miss him.
>
> On Tue, Apr 05, 2011 at 11:17:20AM -0700, Bill Gatliff wrote:
>> Guys:
>>
>>
>> David Brownell unknowingly inspired me to get involved in Linux as a
>> profession. I saw him as an individual working successfully on Free
>> and Open Software, and have made an effort to emulate his success for
>> over a decade now.
>>
>> I deeply regret never taking the time to meet and thank him in person.
>
> A reminder that we all are mortal. Since David I can't thank David
> either, I'd like to take a moment to thank Greg, Alan, and Oliver.
> David, Greg, Alan, and Oliver were really great at putting up with my
> newbie questions when I was first working on usbfs2, and I really
> appreciate all the help, support, and feedback they've given me over the
> years. Thank you!
>
Me too. David and the other developers you mentioned here helped me a
lot. So sad, he is so young.
Regards
Jidong
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/20] net-core: extending (hw_/wanted_/vlan_)features fields to a bitmap.
From: Ben Hutchings @ 2011-04-06 1:45 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: David Miller, netdev
In-Reply-To: <BANLkTimjYRiMCXEdHfaDaXAn+A0fgZR6ZQ@mail.gmail.com>
On Tue, 2011-04-05 at 18:35 -0700, Mahesh Bandewar wrote:
> On Tue, Apr 5, 2011 at 6:27 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> > On Tue, 2011-04-05 at 17:44 -0700, Mahesh Bandewar wrote:
> >> Converting current use of (hw_/wanted_/vlan_)features to
> >> legacy_(hw_/wanted_/vlan_)features to differntiate from the proposed usage.
> > [...]
> >> @@ -1029,44 +1065,51 @@ struct net_device {
> >> struct list_head napi_list;
> >> struct list_head unreg_list;
> >>
> >> +#define DEV_FEATURE_WORDS 2
> >> +#define DEV_FEATURE_BITS (DEV_FEATURE_WORDS*sizeof(long)*BITS_PER_BYTE)
> >> +#define LEGACY_FEATURE_WORD 0
> >> +
> >> /* currently active device features */
> >> - u32 features;
> >> + unsigned long features;
> >> /* user-changeable features */
> >> - u32 hw_features;
> >> + DECLARE_BITMAP(hw_feature, DEV_FEATURE_BITS);
> > [...]
> >
> > Sorry, you can't get rid of hw_features without converting all the
> > callers at the same time. All code has to remain compilable after each
> > single commit.
> >
> I thought I did! My "make allyesconfig; make all" went through. Did I
> miss something?
After 1 commit, or after all 20?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox