[ANNOUNCE] iproute2 2.6.20-070313

[ANNOUNCE] iproute2 2.6.20-070313

[Stephen Hemminger]

This is an experimental to the iproute2 command set.

The version number includes the kernel version to denote what features are
supported. The same source should build on older systems, but obviously the
newer kernel features won't be available. As much as possible, this package
tries to be source compatible across releases.

It can be downloaded from:
  http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.20-070313.tar.gz

Repository:
  git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git

For more info on iproute2 see:
  http://linux-net.osdl.org/index.php/Iproute2

Changes:

Jamal Hadi Salim:
      update rest to use nl_mgrp
      nl_mgrp to crap if base multicast groups exceeded
      Old bug on tc

Mike Frysinger:
      do not ignore build failures in subdirs of iproute2

Noriaki TAKAMIYA:
      enabled to manipulate the flags of IFA_F_HOMEADDRESS or IFA_F_NODAD from ip.

Patrick McHardy:
      tbf: fix latency printing
      Use tc_calc_xmittime() where appropriate
      Introduce tc_calc_xmitsize and use where appropriate
      Introduce TIME_UNITS_PER_SEC to represent internal clock resolution
      Replace "usec" by "time" in function names
      Add sprint_ticks() function and use in CBQ
      Handle different kernel clock resolutions
      Increase internal clock resolution to nsec

Stephen Hemminger:
      netem use read/write for changes
      fix tc-pfifo and tc-bfifo man pages
      iptables library fix
      TC bfifo man page
      Use kernel headers from 2.6.20.y

Thomas Hisch:
      Fixes use of uninitialized string

Re: [ANNOUNCE] iproute2 2.6.20-070313

[Arkadiusz Miskiewicz]

On Tuesday 13 of March 2007, Stephen Hemminger wrote:
> This is an experimental to the iproute2 command set.
>
> The version number includes the kernel version to denote what features are
> supported. The same source should build on older systems, but obviously the
> newer kernel features won't be available. As much as possible, this package
> tries to be source compatible across releases.
>
> It can be downloaded from:
>  
> http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.20-070313.tar.
>gz

This patch

http://www.mail-archive.com/netdev@vger.kernel.org/msg27506.html

didn't make into upstream linux kernel it seems.

The question is - are patches adding some functionality that's not in upstream 
kernel accepted?

There is one wrr patch for iproute floating around that I'm thinking about.

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: [ANNOUNCE] iproute2 2.6.20-070313

[Arkadiusz Miskiewicz]

On Wednesday 14 of March 2007, Arkadiusz Miskiewicz wrote:

Of course I mean:

> This patch
>
> http://www.mail-archive.com/netdev@vger.kernel.org/msg27506.html
>

adds functionality that...

> didn't make into upstream linux kernel it seems.

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: [ANNOUNCE] iproute2 2.6.20-070313

[Patrick McHardy]

Arkadiusz Miskiewicz wrote:
> This patch
> 
> http://www.mail-archive.com/netdev@vger.kernel.org/msg27506.html
> 
> didn't make into upstream linux kernel it seems.

As mentioned in the changelog, its in 2.6.19.

> The question is - are patches adding some functionality that's not in upstream 
> kernel accepted?
> 
> There is one wrr patch for iproute floating around that I'm thinking about.

Last time I looked at the WRR patch it was a huge mess and
used architecture dependant types in the netlink messages.
Unless someone fixed this, adding support to iproute is a
bad idea since in case it would get merged compatibility
would break.

[LARTC] Re: [ANNOUNCE] iproute2 2.6.20-070313

[Patrick McHardy]

Arkadiusz Miskiewicz wrote:
> This patch
> 
> http://www.mail-archive.com/netdev@vger.kernel.org/msg27506.html
> 
> didn't make into upstream linux kernel it seems.

As mentioned in the changelog, its in 2.6.19.

> The question is - are patches adding some functionality that's not in upstream 
> kernel accepted?
> 
> There is one wrr patch for iproute floating around that I'm thinking about.

Last time I looked at the WRR patch it was a huge mess and
used architecture dependant types in the netlink messages.
Unless someone fixed this, adding support to iproute is a
bad idea since in case it would get merged compatibility
would break.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [ANNOUNCE] iproute2 2.6.20-070313

[Arkadiusz Miskiewicz]

On Wednesday 14 of March 2007, Patrick McHardy wrote:
> Arkadiusz Miskiewicz wrote:
> > This patch
> >
> > http://www.mail-archive.com/netdev@vger.kernel.org/msg27506.html
> >
> > didn't make into upstream linux kernel it seems.
>
> As mentioned in the changelog, its in 2.6.19.

Hm, why no RTA_FWMASK in HEAD rtnetlink.h

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/rtnetlink.h;h=4a629ea70cc4ca60a6f486f8653974af68dbe8cd;hb=HEAD

and 2.6.19

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/rtnetlink.h;h=3a18addaed4ccb7436bffc9cf5fd0666f145d35c;hb=0215ffb08ce99e2bb59eca114a99499a4d06e704

?

> Last time I looked at the WRR patch it was a huge mess and
> used architecture dependant types in the netlink messages.
> Unless someone fixed this, adding support to iproute is a
> bad idea since in case it would get merged compatibility
> would break.
Ok.

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: [ANNOUNCE] iproute2 2.6.20-070313

[Patrick McHardy]

Arkadiusz Miskiewicz wrote:
> Hm, why no RTA_FWMASK in HEAD rtnetlink.h
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/rtnetlink.h;h=4a629ea70cc4ca60a6f486f8653974af68dbe8cd;hb=HEAD
> 
> and 2.6.19
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/rtnetlink.h;h=3a18addaed4ccb7436bffc9cf5fd0666f145d35c;hb=0215ffb08ce99e2bb59eca114a99499a4d06e704
> 
> ?

Its in include/linux/fib_rules.h:

enum
{
...
        FRA_FWMASK,     /* mask for netfilter mark */

        __FRA_MAX
};

RTA_* attributes aren't used for routing rules anymore inside
the kernel.

[LARTC] Re: [ANNOUNCE] iproute2 2.6.20-070313

[Patrick McHardy]

Arkadiusz Miskiewicz wrote:
> Hm, why no RTA_FWMASK in HEAD rtnetlink.h
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/rtnetlink.h;hJ629ea70cc4ca60a6f486f8653974af68dbe8cd;hb=HEAD
> 
> and 2.6.19
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/rtnetlink.h;h:18addaed4ccb7436bffc9cf5fd0666f145d35c;hb\x0215ffb08ce99e2bb59eca114a99499a4d06e704
> 
> ?

Its in include/linux/fib_rules.h:

enum
{
...
        FRA_FWMASK,     /* mask for netfilter mark */

        __FRA_MAX
};

RTA_* attributes aren't used for routing rules anymore inside
the kernel.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [ANNOUNCE] iproute2 2.6.20-070313

[Stephen Hemminger]

On Wed, 14 Mar 2007 13:32:28 +0100
Patrick McHardy <kaber@trash.net> wrote:

> Arkadiusz Miskiewicz wrote:
> > Hm, why no RTA_FWMASK in HEAD rtnetlink.h
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/rtnetlink.h;h=4a629ea70cc4ca60a6f486f8653974af68dbe8cd;hb=HEAD
> > 
> > and 2.6.19
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/rtnetlink.h;h=3a18addaed4ccb7436bffc9cf5fd0666f145d35c;hb=0215ffb08ce99e2bb59eca114a99499a4d06e704
> > 
> > ?
> 
> Its in include/linux/fib_rules.h:
> 
> enum
> {
> ...
>         FRA_FWMASK,     /* mask for netfilter mark */
> 
>         __FRA_MAX
> };
> 
> RTA_* attributes aren't used for routing rules anymore inside
> the kernel.

But we need to keep them in iproute2 for back compatibility?

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [ANNOUNCE] iproute2 2.6.20-070313

[Patrick McHardy]

Stephen Hemminger wrote:
> On Wed, 14 Mar 2007 13:32:28 +0100
> Patrick McHardy <kaber@trash.net> wrote:
> 
>>RTA_* attributes aren't used for routing rules anymore inside
>>the kernel.
> 
> 
> But we need to keep them in iproute2 for back compatibility?

Not really for compatibility, its the numerical values that matter.
iproute hasn't been changed to use the FRA_* attributes for routing
rules, but it might be a good idea to do this before adding the next
RTA_* attribute since RTA_FWMASK doesn't have any meaning for routes
in the kernel, so the next RTA attribute we add could just use the
same value instead of leaving a hole.

Re: [ANNOUNCE] iproute2 2.6.20-070313

[Patrick McHardy]

Stephen Hemminger wrote:
> On Wed, 14 Mar 2007 13:32:28 +0100
> Patrick McHardy <kaber@trash.net> wrote:
> 
>>RTA_* attributes aren't used for routing rules anymore inside
>>the kernel.
> 
> 
> But we need to keep them in iproute2 for back compatibility?

Not really for compatibility, its the numerical values that matter.
iproute hasn't been changed to use the FRA_* attributes for routing
rules, but it might be a good idea to do this before adding the next
RTA_* attribute since RTA_FWMASK doesn't have any meaning for routes
in the kernel, so the next RTA attribute we add could just use the
same value instead of leaving a hole.

[LARTC] Re: [ANNOUNCE] iproute2 2.6.20-070313

[Patrick McHardy]

Stephen Hemminger wrote:
> On Wed, 14 Mar 2007 13:32:28 +0100
> Patrick McHardy <kaber@trash.net> wrote:
> 
>>RTA_* attributes aren't used for routing rules anymore inside
>>the kernel.
> 
> 
> But we need to keep them in iproute2 for back compatibility?

Not really for compatibility, its the numerical values that matter.
iproute hasn't been changed to use the FRA_* attributes for routing
rules, but it might be a good idea to do this before adding the next
RTA_* attribute since RTA_FWMASK doesn't have any meaning for routes
in the kernel, so the next RTA attribute we add could just use the
same value instead of leaving a hole.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc