Ok, here is the final patch I came up with, it's on it's
way to the net-2.6.14 GIT tree right now as well.
The orig_dev argument to ptype->func() is never ever NULL.
BTW, I lied during my netconf2005 talk. On 64-bit we
started with a 272 byte sk_buff with everything enabled,
not a 256 byte one
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 22 Jul 2005 22:51:05 +0200
> Yes, currently we have TCF_META_ID_SECURITY still in there
> with a "/* obsolete */" comment so we can remove that
> immediately. Other candidates for removal are indev, realdev,
> and tcverdict so it's not a big problem
In article <[EMAIL PROTECTED]> (at Fri, 22 Jul 2005 14:12:27 -0700 (PDT)),
"David S. Miller" <[EMAIL PROTECTED]> says:
> From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> Date: Fri, 22 Jul 2005 17:06:38 -0400 (EDT)
>
> > No, please, please do not break binaries, whenever it is possible.
> > It is de
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Fri, 22 Jul 2005 17:06:38 -0400 (EDT)
> No, please, please do not break binaries, whenever it is possible.
> It is definitely much better to have many deaf entries in enums.
That is why we are trying to kill the constants before 2.6.13
gets releas
In article <[EMAIL PROTECTED]> (at Fri, 22 Jul 2005 22:55:14 +0200), Thomas
Graf <[EMAIL PROTECTED]> says:
> * Stephen Hemminger <[EMAIL PROTECTED]> 2005-07-22 13:48
> > I don't see how the ematch iproute2 stuff depends on SKB shrinking.
> > The CVS repository has the latest ematch stuff, just te
* Stephen Hemminger <[EMAIL PROTECTED]> 2005-07-22 13:48
> I don't see how the ematch iproute2 stuff depends on SKB shrinking.
> The CVS repository has the latest ematch stuff, just testing and
> checking before the next drop.
We cannot remove TCF_META_ID_* ids without breaking backwards
compatibi
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 22 Jul 2005 22:51:05 +0200
> Yes, currently we have TCF_META_ID_SECURITY still in there
> with a "/* obsolete */" comment so we can remove that
> immediately. Other candidates for removal are indev, realdev,
> and tcverdict so it's not a big problem
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 22 Jul 2005 13:48:42 -0700
> I don't see how the ematch iproute2 stuff depends on SKB shrinking.
> The CVS repository has the latest ematch stuff, just testing and
> checking before the next drop.
We're killing SKB members that the ematch stu
> Hopefully we can weed out the unusable ematch bits before 2.6.13 is
> released. Therefore, once 2.6.13 goes out the iproute2 update should
> be OK.
Sounds good.
> I'm hoping that since we're doing the SKB shrinking in parallel in the
> net-2.6.14 tree with the ongoing 2.6.13 bug fixing, we sho
On Fri, 22 Jul 2005 11:49:11 -0700 (PDT)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Thomas Graf <[EMAIL PROTECTED]>
> Date: Fri, 22 Jul 2005 17:04:00 +0200
>
> > Sure. I was just thinking that maybe we should delay
> > the iproute2 release with the ematch bits until we
> > finished to s
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 22 Jul 2005 17:04:00 +0200
> Sure. I was just thinking that maybe we should delay
> the iproute2 release with the ematch bits until we
> finished to shrink the skb. Stephen?
Hopefully we can weed out the unusable ematch bits before 2.6.13 is
releas
* David S. Miller <[EMAIL PROTECTED]> 2005-07-21 17:07
> Thomas, this kills the TCF_META_ID_REALDEV stuff, so we should
> kill it in 2.6.13-rcX too so that nobody starts using it in
> userspace ok?
Sure. I was just thinking that maybe we should delay
the iproute2 release with the ematch bits until
From: Jay Vosburgh <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 17:35:24 -0700
> FWIW, there have been a couple of proposals floating around
> bonding-devel for a while from people looking to get the skb->real_dev
> in user space (for network manager applications and user-level link
> state mo
From: Ben Greear <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 17:41:55 -0700
> Er, now I feel like an idiot. I am using the real_dev that
> is saved in the vlan device logic, not the thing in the
> skb.
Don't feel bad, that usage confused me as well while working
on this patch :-)
-
To unsubscribe
Ben Greear wrote:
Ben Greear wrote:
Er, now I feel like an idiot. I am using the real_dev that
is saved in the vlan device logic, not the thing in the
skb.
Please ignore my previous ravings.
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To un
Ben Greear wrote:
David S. Miller wrote:
I studied this and it's merely a matter of parameter passing.
Specifically, at ptype->func() time, it is plainly the skb->dev
before skb_bond() is applied.
So I added a "real_dev" arg to ptype->func() and converted
the tree over to that.
Thomas, this k
David S. Miller <[EMAIL PROTECTED]> wrote:
[...]
>Comments?
FWIW, there have been a couple of proposals floating around
bonding-devel for a while from people looking to get the skb->real_dev
in user space (for network manager applications and user-level link
state monitor type things). T
David S. Miller wrote:
I studied this and it's merely a matter of parameter passing.
Specifically, at ptype->func() time, it is plainly the skb->dev
before skb_bond() is applied.
So I added a "real_dev" arg to ptype->func() and converted
the tree over to that.
Thomas, this kills the TCF_META_ID
I studied this and it's merely a matter of parameter passing.
Specifically, at ptype->func() time, it is plainly the skb->dev
before skb_bond() is applied.
So I added a "real_dev" arg to ptype->func() and converted
the tree over to that.
Thomas, this kills the TCF_META_ID_REALDEV stuff, so we sh
19 matches
Mail list logo
