Patrick McHardy wrote:
Andrew McDonald wrote:
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
I guess this one makes sense on top.
[IPV4/6]:
Cal Peake wrote:
Hi,
The following compile error occurs with linux-2.6.13-rc3-git5:
CC net/ipv6/ip6_tunnel.o
net/ipv6/ip6_tunnel.c: In function `ip6ip6_unregister':
net/ipv6/ip6_tunnel.c:1126: warning: implicit declaration of function
`xfrm6_tunnel_unregister'
...
LD .tmp_vmlinu
Thomas Graf wrote:
I think we should head for a 16bit ifindex at some point
or is there any reason why 65K interfaces wouldn't be
sufficient? We waste one bit at the moment to have simpler
error handling for all the functions returning indices.
Although I don't know anyone doing so, it would
Jamal Hadi Salim wrote:
On Sat, 2005-23-07 at 16:50 +0200, Thomas Graf wrote:
No, we use s32 at the moment with the limitation that negative indices
are illegal. We don't have to break the interfaces just because of this,
but since dev_new_ifindex() will be reusing gone indices if needed it
m
From: Randy Dunlap <[EMAIL PROTECTED]>
This patch improves the presentation of several networking driver families.
It causes them to be displayed aligned with ARCnet and Ethernet
(immediately under them in menuconfig/xconfig/gconfig) instead of
not being subordinate to (i.e., not indented) the Net
Hi,
The following compile error occurs with linux-2.6.13-rc3-git5:
CC net/ipv6/ip6_tunnel.o
net/ipv6/ip6_tunnel.c: In function `ip6ip6_unregister':
net/ipv6/ip6_tunnel.c:1126: warning: implicit declaration of function
`xfrm6_tunnel_unregister'
...
LD .tmp_vmlinux1
net/built-in.o(.i
Andrew McDonald wrote:
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
I guess this one makes sense on top.
[IPV4/6]: Check if packet was actua
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global function:
- xfrm4_state.c: xfrm4_state_fini
- remove the following unneeded EXPORT_SYMBOL's:
- ip_output.c: ip_finish_output
- ip_output.c: sysctl_ip_default_ttl
- f
Andy Fleming <[EMAIL PROTECTED]> :
> Here's the latest version of the patch, done against a cogito
> linux-2.6 branch.
The patch includes a diff against drivers/net/phy/phy.c which does not
seem to exist in my -rc3-git4 local tree. Where can it be found ?
--
Ueimor
-
To unsubscribe from this li
Hi Dave!
The attached patch adds support for refcounting of modules implementing
netlink protocols. The idea is that you prevent the module from
disappearing as long as someone in userspace has still a socket talking
to you.
I think the current behaviour can be quite confusing, since modules lik
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
Signed-off-by: Andrew McDonald <[EMAIL PROTECTED]>
diff -uprN linux-2.6.13-rc3.orig/include/net/ra
On Sun, Jun 26, 2005 at 07:00:13PM -0400, Jeff Garzik wrote:
> randy_dunlap wrote:
> >On Sun, 26 Jun 2005 18:26:49 -0400 Jeff Garzik wrote:
> >
> >| Adrian Bunk wrote:
> >| > This patch contains the following cleanups:
> >| > - dmascc.c: remove the unused global function dmascc_setup
> >|
> >| Bet
Jamal Hadi Salim wrote:
This is part of mission skb diet.
Against git/davem/2.6.14 that was on vger 30 minutes back: It changes
input_dev to be an ifindex so we dont bother holding devices.
Would only cut a 4 byte fat on 64 bit machines.
Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
L
The DM9000 driver is responding to ioctl() calls it should not be. This
can cause problems with the wireless tools incorrectly indentifying the
device as wireless capable, and crashing under certain operations.
This patch also moves the version printk() to the init call, so that
you only get it on
Fix DM9000 driver usage of spinlocks, which mainly came to light
when running a kernel with spinlock debugging. These come down to:
1) Un-initialised spin lock
2) Several cases of using spin_xxx(lock) and not spin_xxx(&lock)
3) move the locking around the phy reg for read/write to only
keep
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-23 17:58
> Jamal Hadi Salim wrote:
> >Did you check if there was no side effect with the macros that
> >manipulate tc_verdict?
>
> Of course, these macros are basically the only user. They could use
> some cleanup btw, I think I'll do that later.
Hold
* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-07-23 10:14
> Most of these pieces of h/ware have different approaches to how those
> underlying rings are used sending out to the wire. As an example, it is
> clear the wireless folks have time slots + prios as the desired qos
> scheme. This will map nic
On Fri, Jul 22, 2005 at 08:12:58PM -0400, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 21 Jul 2005 21:44:43 +0100), Andrew
> McDonald <[EMAIL PROTECTED]> says:
>
> > I guess the fix would be a matter of changing:
> >
> > if (sk && ra->sel == sel) {
> >
> > to
Jamal Hadi Salim wrote:
Did you check if there was no side effect with the macros that
manipulate tc_verdict?
Of course, these macros are basically the only user. They could use
some cleanup btw, I think I'll do that later.
-
To unsubscribe from this list: send the line "unsubscribe netdev"
Jamal Hadi Salim wrote:
On Sat, 2005-23-07 at 06:53 +0200, Patrick McHardy wrote:
Great, thanks. Patch coming up in a couple of minutes :)
The only thing i would worry about is that at some point we had
assumptions about tc_index being 32 bit. I think it may have been used
to carry class majo
On Sat, 2005-23-07 at 16:50 +0200, Thomas Graf wrote:
> No, we use s32 at the moment with the limitation that negative indices
> are illegal. We don't have to break the interfaces just because of this,
> but since dev_new_ifindex() will be reusing gone indices if needed it
> might be possible to
* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-07-23 10:37
> ifindex has to be 32 bit because most management apps (SNMP etc) expect
> it to be 32 bit. I havent scanned the code but making int actually
> doesnt seem right - unless some code is expecting it to be a -ve number
> somewhere; it should be
On Sat, 2005-23-07 at 16:29 +0200, Thomas Graf wrote:
> I think we should head for a 16bit ifindex at some point
> or is there any reason why 65K interfaces wouldn't be
> sufficient? We waste one bit at the moment to have simpler
> error handling for all the functions returning indices.
Strange,
* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-07-23 09:32
> @@ -205,7 +205,6 @@ struct sk_buff {
> struct sock *sk;
> struct timeval stamp;
> struct net_device *dev;
> - struct net_device *input_dev;
> struct net_device *real_dev;
>
On Fri, 2005-22-07 at 15:52 -0700, David S. Miller wrote:
> Sounds OK. What happens if the top-level queue pulls out
> a packet with a certain priority, and that priority's queue
> in the device is stopped? Will it look for lower-priority
> packets and try to send those? All of this kind of log
This is part of mission skb diet.
Against git/davem/2.6.14 that was on vger 30 minutes back: It changes
input_dev to be an ifindex so we dont bother holding devices.
Would only cut a 4 byte fat on 64 bit machines.
Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
cheers,
jamal
diff --git a
Did you check if there was no side effect with the macros that
manipulate tc_verdict?
cheers,
jamal
On Sat, 2005-23-07 at 07:03 +0200, Patrick McHardy wrote:
> plain text document attachment (x)
> [NET]: Reduce tc_index/tc_verd to u16
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
>
>
On Sat, 2005-23-07 at 06:53 +0200, Patrick McHardy wrote:
> Thomas Graf wrote:
> > * Patrick McHardy <[EMAIL PROTECTED]> 2005-07-23 06:39
> >
> >>I'm trying to convert tc_index to a u16, which looks OK in all places
> >>but sched_gred. I can't make sense of this code:
> >>
> >>/* fix tc_i
Lennert Buytenhek writes:
> We know something new about 2.7 now: that it's not going to happen
> soon :) I'd love to see your pktgen devel version in 2.6...
Hello !
I'll guess you just didn't check. It's included from 2.6.11.
Cheers.
--ro
-
To unsu
On Thu, Dec 16, 2004 at 04:57:18PM +0100, Robert Olsson wrote:
> > Is it sane to try and keep pktgen-2.6 up to date when the devel
> > version is so much more flexible?
>
> Not really. The development version had some untested areas (and
> still has) so it was thought for 2.7 but it's been w
Hi,
I submitted this patch a while ago, and I still find myself patching
it in every time I compile a new kernel. Can something like this be
merged, please?
thanks,
Lennert
- Forwarded message from Lennert Buytenhek
-
Date: Wed, 24 Nov 2004 16:15:17 +0100
From: Lennert Buytenhek
T
31 matches
Mail list logo
