On Tue, 11 Jan 2005 23:06:27 +0000 Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote:
Thomas Graf wrote:
* Andy Furniss <41E3F088.6060708@xxxxxxxxxxxxx> 2005-01-11 15:28
diff -urN linux-2.6.10.orig/include/linux/pkt_sched.h linux-2.6.10/include/linux/pkt_sched.h @@ -136,6 +143,7 @@ __u32 limit; /* Maximal packets in queue */ unsigned divisor; /* Hash divisor */ unsigned flows; /* Maximal number of flows */ + unsigned hash_kind; /* Hash function to use for flow identification */ };
This breaks compatibility to older iproute2 versions compiled with older header versions (not including the additional 4 octets). sch_sfq.c:
if (opt->rta_len < RTA_LENGTH(sizeof(*ctl))) return -EINVAL;
I did wonder if it could just come out now that iproute2 uses its own pkt_sched.h.
Just to be sure I understand - it's a risk that always existed eg. before Stephen maintained iproute2, when it compiled against kernel headers. If I patched kernel and failed to compile new tc/had old tc ahead in path etc. then sfq would be broken.
So if you patch make sure you build and use new tc do tc -V / check you don't have an old one in /sbin as iproute2's make install uses /usr/sbin by default.
We need to maintain binary compatibility so that old command with latest kernel, and new command works with old kernel. That restricts message formats.
But not source compatibility for iproute2, the iproute2 package needs to be self-contained and not depend on external (kernel) headers that may or may not be up to date.
Also, older version of iproute2 compiled with current kernel headers should be supported. I would rather see all versions of iproute2 tarball's as self contained and not depend on kernel headers.
Ahh - I think I see what you mean.
If esfq wants to get into kernel then it has to become a completly new queue and not mess with sfq options at all.
Andy.
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
