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. _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
