sys-apps/iproute2: drop old <4.4.0 versions

15 files changed, 0 insertions, 1646 deletions

diff --git a/sys-apps/iproute2/files/iproute2-2.6.26-ldflags.patch b/sys-apps/iproute2/files/iproute2-2.6.26-ldflags.patch
deleted file mode 100644
index 39e07995da5c..000000000000
--- a/sys-apps/iproute2/files/iproute2-2.6.26-ldflags.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-respect env LDFLAGS
-
-http://bugs.gentoo.org/236861
-
---- tc/Makefile
-+++ tc/Makefile
-@@ -83,7 +83,7 @@
- 	rm -f emp_ematch.yacc.output
- 
- q_atm.so: q_atm.c
--	$(CC) $(CFLAGS) -shared -fpic -o q_atm.so q_atm.c -latm
-+	$(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o q_atm.so q_atm.c -latm
- 
- %.yacc.c: %.y
- 	$(YACC) $(YACCFLAGS) -o $@ $<
diff --git a/sys-apps/iproute2/files/iproute2-2.6.29.1-flush.patch b/sys-apps/iproute2/files/iproute2-2.6.29.1-flush.patch
deleted file mode 100644
index 8eb32280986e..000000000000
--- a/sys-apps/iproute2/files/iproute2-2.6.29.1-flush.patch
+++ /dev/null
@@ -1,224 +0,0 @@
-https://bugs.gentoo.org/274973
-
-If the routing table that I wanna flush has 60 entries or more, "ip route flush
-table foo" fails with the following error:
-  Failed to send flush request: Success
-  Flush terminated
-
-Patch by Alin Năstac <mrness@gentoo.org>
-
---- iproute2-2.6.29-1/ip/ipaddress.c
-+++ iproute2-2.6.29-1/ip/ipaddress.c
-@@ -37,6 +37,8 @@
- 
- #define MAX_ROUNDS 10
- 
-+static struct rtnl_handle rth_flush = { .fd = -1 };
-+
- static struct
- {
- 	int ifindex;
-@@ -339,7 +341,7 @@
- 
- static int flush_update(void)
- {
--	if (rtnl_send_check(&rth, filter.flushb, filter.flushp) < 0) {
-+	if (rtnl_send_check(&rth_flush, filter.flushb, filter.flushp) < 0) {
- 		perror("Failed to send flush request");
- 		return -1;
- 	}
-@@ -697,6 +699,9 @@
- 		filter.flushp = 0;
- 		filter.flushe = sizeof(flushb);
- 
-+		if (rtnl_open(&rth_flush, 0) < 0)
-+			return 1;
-+
- 		while (round < MAX_ROUNDS) {
- 			if (rtnl_wilddump_request(&rth, filter.family, RTM_GETADDR) < 0) {
- 				perror("Cannot send dump request");
-@@ -715,18 +720,20 @@
- 						printf("*** Flush is complete after %d round%s ***\n", round, round>1?"s":"");
- 				}
- 				fflush(stdout);
-+				rtnl_close(&rth_flush);
- 				return 0;
- 			}
- 			round++;
- 			if (flush_update() < 0)
--				return 1;
-+				break;
- 
- 			if (show_stats) {
- 				printf("\n*** Round %d, deleting %d addresses ***\n", round, filter.flushed);
- 				fflush(stdout);
- 			}
- 		}
--		fprintf(stderr, "*** Flush remains incomplete after %d rounds. ***\n", MAX_ROUNDS); fflush(stderr);
-+		fprintf(stderr, "*** Flush remains incomplete after %d rounds. ***\n", round); fflush(stderr);
-+		rtnl_close(&rth_flush);
- 		return 1;
- 	}
- 
---- iproute2-2.6.29-1/ip/ipneigh.c
-+++ iproute2-2.6.29-1/ip/ipneigh.c
-@@ -32,6 +32,8 @@
- #define NUD_VALID	(NUD_PERMANENT|NUD_NOARP|NUD_REACHABLE|NUD_PROBE|NUD_STALE|NUD_DELAY)
- #define MAX_ROUNDS	10
- 
-+static struct rtnl_handle rth_flush = { .fd = -1 };
-+
- static struct
- {
- 	int family;
-@@ -87,7 +89,7 @@
- 
- static int flush_update(void)
- {
--	if (rtnl_send_check(&rth, filter.flushb, filter.flushp) < 0) {
-+	if (rtnl_send_check(&rth_flush, filter.flushb, filter.flushp) < 0) {
- 		perror("Failed to send flush request");
- 		return -1;
- 	}
-@@ -391,6 +393,9 @@
- 		filter.flushe = sizeof(flushb);
- 		filter.state &= ~NUD_FAILED;
- 
-+		if (rtnl_open(&rth_flush, 0) < 0)
-+			return 1;
-+
- 		while (round < MAX_ROUNDS) {
- 			if (rtnl_wilddump_request(&rth, filter.family, RTM_GETNEIGH) < 0) {
- 				perror("Cannot send dump request");
-@@ -409,18 +414,20 @@
- 						printf("*** Flush is complete after %d round%s ***\n", round, round>1?"s":"");
- 				}
- 				fflush(stdout);
-+				rtnl_close(&rth_flush);
- 				return 0;
- 			}
- 			round++;
- 			if (flush_update() < 0)
--				exit(1);
-+				break;
-+
- 			if (show_stats) {
- 				printf("\n*** Round %d, deleting %d entries ***\n", round, filter.flushed);
- 				fflush(stdout);
- 			}
- 		}
--		printf("*** Flush not complete bailing out after %d rounds\n",
--			MAX_ROUNDS);
-+		fprintf(stderr, "*** Flush remains incomplete after %d rounds. ***\n", round); fflush(stderr);
-+		rtnl_close(&rth_flush);
- 		return 1;
- 	}
- 
---- iproute2-2.6.29-1/ip/iproute.c
-+++ iproute2-2.6.29-1/ip/iproute.c
-@@ -37,6 +37,7 @@
- #define RTAX_RTTVAR RTAX_HOPS
- #endif
- 
-+static struct rtnl_handle rth_flush = { .fd = -1 };
- 
- static const char *mx_names[RTAX_MAX+1] = {
- 	[RTAX_MTU]	= "mtu",
-@@ -112,7 +113,7 @@
- 
- static int flush_update(void)
- {
--	if (rtnl_send_check(&rth, filter.flushb, filter.flushp) < 0) {
-+	if (rtnl_send_check(&rth_flush, filter.flushb, filter.flushp) < 0) {
- 		perror("Failed to send flush request");
- 		return -1;
- 	}
-@@ -1210,6 +1211,9 @@
- 		filter.flushp = 0;
- 		filter.flushe = sizeof(flushb);
- 
-+		if (rtnl_open(&rth_flush, 0) < 0)
-+			return 1;
-+
- 		for (;;) {
- 			if (rtnl_wilddump_request(&rth, do_ipv6, RTM_GETROUTE) < 0) {
- 				perror("Cannot send dump request");
-@@ -1228,6 +1232,7 @@
- 						printf("*** Flush is complete after %d round%s ***\n", round, round>1?"s":"");
- 				}
- 				fflush(stdout);
-+				rtnl_close(&rth_flush);
- 				return 0;
- 			}
- 			round++;
---- iproute2-2.6.29-1/ip/xfrm_policy.c
-+++ iproute2-2.6.29-1/ip/xfrm_policy.c
-@@ -756,11 +756,15 @@
- 		struct xfrm_buffer xb;
- 		char buf[NLMSG_DELETEALL_BUF_SIZE];
- 		int i;
-+		struct rtnl_handle rth2;
- 
- 		xb.buf = buf;
- 		xb.size = sizeof(buf);
- 		xb.rth = &rth;
- 
-+		if (rtnl_open(&rth2, 0) < 0)
-+			exit(1);
-+
- 		for (i = 0; ; i++) {
- 			xb.offset = 0;
- 			xb.nlmsg_count = 0;
-@@ -783,7 +787,7 @@
- 				break;
- 			}
- 
--			if (rtnl_send_check(&rth, xb.buf, xb.offset) < 0) {
-+			if (rtnl_send_check(&rth2, xb.buf, xb.offset) < 0) {
- 				perror("Failed to send delete-all request");
- 				exit(1);
- 			}
-@@ -793,6 +797,8 @@
- 			xb.offset = 0;
- 			xb.nlmsg_count = 0;
- 		}
-+
-+		rtnl_close(&rth2);
- 	} else {
- 		if (rtnl_wilddump_request(&rth, preferred_family, XFRM_MSG_GETPOLICY) < 0) {
- 			perror("Cannot send dump request");
---- iproute2-2.6.29-1/ip/xfrm_state.c
-+++ iproute2-2.6.29-1/ip/xfrm_state.c
-@@ -924,11 +924,15 @@
- 		struct xfrm_buffer xb;
- 		char buf[NLMSG_DELETEALL_BUF_SIZE];
- 		int i;
-+		struct rtnl_handle rth2;
- 
- 		xb.buf = buf;
- 		xb.size = sizeof(buf);
- 		xb.rth = &rth;
- 
-+		if (rtnl_open(&rth2, 0) < 0)
-+			exit(1);
-+
- 		for (i = 0; ; i++) {
- 			xb.offset = 0;
- 			xb.nlmsg_count = 0;
-@@ -951,7 +955,7 @@
- 				break;
- 			}
- 
--			if (rtnl_send_check(&rth, xb.buf, xb.offset) < 0) {
-+			if (rtnl_send_check(&rth2, xb.buf, xb.offset) < 0) {
- 				perror("Failed to send delete-all request\n");
- 				exit(1);
- 			}
-@@ -962,6 +966,7 @@
- 			xb.nlmsg_count = 0;
- 		}
- 
-+		rtnl_close(&rth2);
- 	} else {
- 		if (rtnl_wilddump_request(&rth, preferred_family, XFRM_MSG_GETSA) < 0) {
- 			perror("Cannot send dump request");
diff --git a/sys-apps/iproute2/files/iproute2-2.6.29.1-hfsc.patch b/sys-apps/iproute2/files/iproute2-2.6.29.1-hfsc.patch
deleted file mode 100644
index 4f39ded905c1..000000000000
--- a/sys-apps/iproute2/files/iproute2-2.6.29.1-hfsc.patch
+++ /dev/null
@@ -1,885 +0,0 @@
-http://bugs.gentoo.org/291907
-
-This patch was merged from two patches extracted from this thread:
-http://markmail.org/thread/qkd76gpdgefpjlfn
-
-Patch #1.
-This patch adds detailed documentation for HFSC scheduler. It roughly
-follows HFSC paper, but tries to not rely too much on math side of things.
-Post-paper/Linux specific subjects (timer resolution, ul service curve, etc.)
-are also discussed.
-
-
-I've read it many times over, but it's a lengthy chunk of text - so try
-to be understanding in case I made some mistakes.
-
-
-tc-hfsc(7): explains algorithm in detail (very long)
-tc-hfsc(8): explains command line options briefly
-tc(8): adds references to new man pages
-Makefile: adds man7 directory to install target
-q_hfsc.c: minimal help text changes, consistency with tc-hfsc(8)
-
-
-Patch #2.
-This adds generic explanation about size tables.
-
-
-tc-stab(8): Commandline + details
-One thing I'm not sure, is whenever any layer2 data is included in case
-of shaping directly on ppp interface (see the bottom of the man page).
-
-
-tc_stab.c: small fixes to commandline help
-
-
-tc_core.c:
-As kernel part of things relies on cell align which is always set to -1,
-I also added it to userspace computation stage. This way if someone
-specified e.g. 2048 and 512 for mtu and tsize respectively, one wouldn't
-end with tsize supporting mtu 4096 suddenly, New default mtu is also set
-to 2048 (disregarding weirdness of setting mtu to such values).
-
-
-Unless I missed something, this is harmless and feels cleaner, but if it's
-not allowed, documentation will have to be changed back to 2047 + extra
-explanation as well.
-
---- iproute2/Makefile
-+++ iproute2-new/Makefile
-@@ -56,6 +56,8 @@
- 	install -m 0644 $(shell find etc/iproute2 -maxdepth 1 -type f) $(DESTDIR)$(CONFDIR)
- 	install -m 0755 -d $(DESTDIR)$(MANDIR)/man8
- 	install -m 0644 $(shell find man/man8 -maxdepth 1 -type f) $(DESTDIR)$(MANDIR)/man8
-+	install -m 0755 -d $(DESTDIR)$(MANDIR)/man7
-+	install -m 0644 $(shell find man/man7 -maxdepth 1 -type f) $(DESTDIR)$(MANDIR)/man7
- 	ln -sf tc-bfifo.8  $(DESTDIR)$(MANDIR)/man8/tc-pfifo.8
- 	ln -sf lnstat.8  $(DESTDIR)$(MANDIR)/man8/rtstat.8
- 	ln -sf lnstat.8  $(DESTDIR)$(MANDIR)/man8/ctstat.8
---- iproute2/man/man7/tc-hfsc.7
-+++ iproute2-new/man/man7/tc-hfsc.7
-@@ -0,0 +1,525 @@
-+.TH HFSC 7 "25 February 2009" iproute2 Linux
-+.ce 1
-+\fBHIERARCHICAL FAIR SERVICE CURVE\fR
-+.
-+.SH "HISTORY & INTRODUCTION"
-+.
-+HFSC \- \fBHierarchical Fair Service Curve\fR was first presented at
-+SIGCOMM'97. Developed as a part of ALTQ (ALTernative Queuing) on NetBSD, found
-+its way quickly to other BSD systems, and then a few years ago became part of
-+the linux kernel. Still, it's not the most popular scheduling algorithm \-
-+especially if compared to HTB \- and it's not well documented from enduser's
-+perspective. This introduction aims to explain how HFSC works without
-+going to deep into math side of things (although some if it will be
-+inevitable).
-+
-+In short HFSC aims to:
-+.
-+.RS 4
-+.IP \fB1)\fR 4
-+guarantee precise bandwidth and delay allocation for all leaf classes (realtime
-+criterion)
-+.IP \fB2)\fR
-+allocate excess bandwidth fairly as specified by class hierarchy (linkshare &
-+upperlimit criterion)
-+.IP \fB3)\fR
-+minimize any discrepancy between the service curve and the actual amount of
-+service provided during linksharing
-+.RE
-+.PP
-+.
-+The main "selling" point of HFSC is feature \fB(1)\fR, which is achieved by
-+using nonlinear service curves (more about what it actually is later). This is
-+particularly useful in VoIP or games, where not only guarantee of consistent
-+bandwidth is important, but initial delay of a data stream as well. Note that
-+it matters only for leaf classes (where the actual queues are) \- thus class
-+hierarchy is ignored in realtime case.
-+
-+Feature \fB(2)\fR is well, obvious \- any algorithm featuring class hierarchy
-+(such as HTB or CBQ) strives to achieve that. HFSC does that well, although
-+you might end with unusual situations, if you define service curves carelessly
-+\- see section CORNER CASES for examples.
-+
-+Feature \fB(3)\fR is mentioned due to the nature of the problem. There may be
-+situations where it's either not possible to guarantee service of all curves at
-+the same time, and/or it's impossible to do so fairly. Both will be explained
-+later. Note that this is mainly related to interior (aka aggregate) classes, as
-+the leafs are already handled by \fB(1)\fR. Still \- it's perfectly possible to
-+create a leaf class w/o realtime service, and in such case \- the caveats will
-+naturally extend to leaf classes as well.
-+
-+.SH ABBREVIATIONS
-+For the remaining part of the document, we'll use following shortcuts:
-+.nf
-+.RS 4
-+
-+RT \- realtime
-+LS \- linkshare
-+UL \- upperlimit
-+SC \- service curve
-+.fi
-+.
-+.SH "BASICS OF HFSC"
-+.
-+To understand how HFSC works, we must first introduce a service curve.
-+Overall, it's a nondecreasing function of some time unit, returning amount of
-+service (allowed or allocated amount of bandwidth) by some specific point in
-+time. The purpose of it should be subconsciously obvious \- if a class was
-+allowed to transfer not less than the amount specified by its service curve \-
-+then service curve is not violated.
-+
-+Still \- we need more elaborate criterion than just the above (although in
-+most generic case it can be reduced to it). The criterion has to take two
-+things into account:
-+.
-+.RS 4
-+.IP \(bu 4
-+idling periods
-+.IP \(bu
-+ability to "look back", so if during current active period service curve is violated, maybe it
-+isn't if we count excess bandwidth received during earlier active period(s)
-+.RE
-+.PP
-+Let's define the criterion as follows:
-+.RS 4
-+.nf
-+.IP "\fB(1)\fR" 4
-+For each t1, there must exist t0 in set B, so S(t1\-t0)\~<=\~w(t0,t1)
-+.fi
-+.RE
-+.
-+.PP
-+Here 'w' denotes the amount of service received during some time period between t0
-+and t1. B is a set of all times, where a session becomes active after idling
-+period (further denoted as 'becoming backlogged'). For a clearer picture,
-+imagine two situations:
-+.
-+.RS 4
-+.IP \fBa)\fR 4
-+our session was active during two periods, with a small time gap between them
-+.IP \fBb)\fR
-+as in (a), but with a larger gap
-+.RE
-+.
-+.PP
-+Consider \fB(a)\fR \- if the service received during both periods meets
-+\fB(1)\fR, then all is good. But what if it doesn't do so during the 2nd
-+period ? If the amount of service received during the 1st period is bigger
-+than the service curve, then it might compensate for smaller service during
-+the 2nd period \fIand\fR the gap \- if the gap is small enough.
-+
-+If the gap is larger \fB(b)\fR \- then it's less likely to happen (unless the
-+excess bandwidth allocated during the 1st part was really large). Still, the
-+larger the gap \- the less interesting is what happened in the past (e.g. 10
-+minutes ago) \- what matters is the current traffic that just started.
-+
-+From HFSC's perspective, more interesting is answering the following question:
-+when should we start transferring packets, so a service curve of a class is not
-+violated. Or rephrasing it: How much X() amount of service should a session
-+receive by time t, so the service curve is not violated. Function X() defined
-+as below is the basic building block of HFSC, used in: eligible, deadline,
-+virtual\-time and fit\-time curves. Of course, X() is based on equation
-+\fB(1)\fR and is defined recursively:
-+
-+.RS 4
-+.IP \(bu 4
-+At the 1st backlogged period beginning function X is initialized to generic
-+service curve assigned to a class
-+.IP \(bu
-+At any subsequent backlogged period, X() is:
-+.nf
-+\fBmin(X() from previous period ; w(t0)+S(t\-t0) for t>=t0),\fR
-+.fi
-+\&... where t0 denotes the beginning of the current backlogged period.
-+.RE
-+.
-+.PP
-+HFSC uses either linear, or two\-piece linear service curves. In case of
-+linear or two\-piece linear convex functions (first slope < second slope),
-+min() in X's definition reduces to the 2nd argument. But in case of two\-piece
-+concave functions, the 1st argument might quickly become lesser for some
-+t>=t0. Note, that for some backlogged period, X() is defined only from that
-+period's beginning. We also define X^(\-1)(w) as smallest t>=t0, for which
-+X(t)\~=\~w. We have to define it this way, as X() is usually not an injection.
-+
-+The above generic X() can be one of the following:
-+.
-+.RS 4
-+.IP "E()" 4
-+In realtime criterion, selects packets eligible for sending. If none are
-+eligible, HFSC will use linkshare criterion. Eligible time \&'et' is calculated
-+with reference to packets' heads ( et\~=\~E^(\-1)(w) ). It's based on RT
-+service curve, \fIbut in case of a convex curve, uses its 2nd slope only.\fR
-+.IP "D()"
-+In realtime criterion, selects the most suitable packet from the ones chosen
-+by E(). Deadline time \&'dt' corresponds to packets' tails
-+(dt\~=\~D^(\-1)(w+l), where \&'l' is packet's length). Based on RT service
-+curve.
-+.IP "V()"
-+In linkshare criterion, arbitrates which packet to send next. Note that V() is
-+function of a virtual time \- see \fBLINKSHARE CRITERION\fR section for
-+details.  Virtual time \&'vt' corresponds to packets' heads
-+(vt\~=\~V^(\-1)(w)). Based on LS service curve.
-+.IP "F()"
-+An extension to linkshare criterion, used to limit at which speed linkshare
-+criterion is allowed to dequeue. Fit\-time 'ft' corresponds to packets' heads
-+as well (ft\~=\~F^(\-1)(w)). Based on UL service curve.
-+.RE
-+
-+Be sure to make clean distinction between session's RT, LS and UL service
-+curves and the above "utility" functions.
-+.
-+.SH "REALTIME CRITERION"
-+.
-+RT criterion \fIignores class hierarchy\fR and guarantees precise bandwidth and
-+delay allocation. We say that packet is eligible for sending, when current real
-+time is bigger than eligible time. From all packets eligible, the one most
-+suited for sending, is the one with the smallest deadline time. Sounds simply,
-+but consider following example:
-+
-+Interface 10mbit, two classes, both with two\-piece linear service curves:
-+.RS 4
-+.IP \(bu 4
-+1st class \- 2mbit for 100ms, then 7mbit (convex \- 1st slope < 2nd slope)
-+.IP \(bu
-+2nd class \- 7mbit for 100ms, then 2mbit (concave \- 1st slope > 2nd slope)
-+.RE
-+.PP
-+Assume for a moment, that we only use D() for both finding eligible packets,
-+and choosing the most fitting one, thus eligible time would be computed as
-+D^(\-1)(w) and deadline time would be computed as D^(\-1)(w+l).  If the 2nd
-+class starts sending packets 1 second after the 1st class, it's of course
-+impossible to guarantee 14mbit, as the interface capability is only 10mbit.
-+The only workaround in this scenario is to allow the 1st class to send the
-+packets earlier that would normally be allowed. That's where separate E() comes
-+to help.  Putting all the math aside (see HFSC paper for details), E() for RT
-+concave service curve is just like D(), but for the RT convex service curve \-
-+it's constructed using \fIonly\fR RT service curve's 2nd slope (in our example
-+\- 7mbit).
-+
-+The effect of such E() \- packets will be sent earlier, and at the same time
-+D() \fIwill\fR be updated \- so current deadline time calculated from it will
-+be bigger. Thus, when the 2nd class starts sending packets later, both the 1st
-+and the 2nd class will be eligible, but the 2nd session's deadline time will be
-+smaller and its packets will be sent first. When the 1st class becomes idle at
-+some later point, the 2nd class will be able to "buffer" up again for later
-+active period of the 1st class.
-+
-+A short remark \- in a situation, where the total amount of bandwidth
-+available on the interface is bigger than the allocated total realtime parts
-+(imagine interface 10 mbit, but 1mbit/2mbit and 2mbit/1mbit classes), the sole
-+speed of the interface could suffice to guarantee the times.
-+
-+Important part of RT criterion is that apart from updating its D() and E(),
-+also V() used by LS criterion is updated. Generally the RT criterion is
-+secondary to LS one, and used \fIonly\fR if there's a risk of violating precise
-+realtime requirements. Still, the "participation" in bandwidth distributed by
-+LS criterion is there, so V() has to be updated along the way. LS criterion can
-+than properly compensate for non\-ideal fair sharing situation, caused by RT
-+scheduling. If you use UL service curve its F() will be updated as well (UL
-+service curve is an extension to LS one \- see \fBUPPERLIMIT CRITERION\fR
-+section).
-+
-+Anyway \- careless specification of LS and RT service curves can lead to
-+potentially undesired situations (see CORNER CASES for examples). This wasn't
-+the case in HFSC paper where LS and RT service curves couldn't be specified
-+separately.
-+
-+.SH "LINKSHARING CRITERION"
-+.
-+LS criterion's task is to distribute bandwidth according to specified class
-+hierarchy. Contrary to RT criterion, there're no comparisons between current
-+real time and virtual time \- the decision is based solely on direct comparison
-+of virtual times of all active subclasses \- the one with the smallest vt wins
-+and gets scheduled. One immediate conclusion from this fact is that absolute
-+values don't matter \- only ratios between them (so for example, two children
-+classes with simple linear 1mbit service curves will get the same treatment
-+from LS criterion's perspective, as if they were 5mbit). The other conclusion
-+is, that in perfectly fluid system with linear curves, all virtual times across
-+whole class hierarchy would be equal.
-+
-+Why is VC defined in term of virtual time (and what is it) ?
-+
-+Imagine an example: class A with two children \- A1 and A2, both with let's say
-+10mbit SCs. If A2 is idle, A1 receives all the bandwidth of A (and update its
-+V() in the process). When A2 becomes active, A1's virtual time is already
-+\fIfar\fR bigger than A2's one. Considering the type of decision made by LS
-+criterion, A1 would become idle for a lot of time. We can workaround this
-+situation by adjusting virtual time of the class becoming active \- we do that
-+by getting such time "up to date". HFSC uses a mean of the smallest and the
-+biggest virtual time of currently active children fit for sending. As it's not
-+real time anymore (excluding trivial case of situation where all classes become
-+active at the same time, and never become idle), it's called virtual time.
-+
-+Such approach has its price though. The problem is analogous to what was
-+presented in previous section and is caused by non\-linearity of service
-+curves:
-+.IP 1) 4
-+either it's impossible to guarantee both service curves and satisfy fairness
-+during certain time periods:
-+
-+.RS 4
-+Recall the example from RT section, slightly modified (with 3mbit slopes
-+instead of 2mbit ones):
-+
-+.IP \(bu 4
-+1st class \- 3mbit for 100ms, then 7mbit (convex \- 1st slope < 2nd slope)
-+.IP \(bu
-+2nd class \- 7mbit for 100ms, then 3mbit (concave \- 1st slope > 2nd slope)
-+
-+.PP
-+They sum up nicely to 10mbit \- interface's capacity. But if we wanted to only
-+use LS for guarantees and fairness \- it simply won't work. In LS context,
-+only V() is used for making decision which class to schedule. If the 2nd class
-+becomes active when the 1st one is in its second slope, the fairness will be
-+preserved \- ratio will be 1:1 (7mbit:7mbit), but LS itself is of course
-+unable to guarantee the absolute values themselves \- as it would have to go
-+beyond of what the interface is capable of.
-+.RE
-+
-+.IP 2) 4
-+and/or it's impossible to guarantee service curves of all classes at all
-+
-+.RS 4
-+Even if we didn't use virtual time and allowed a session to be "punished",
-+there's a possibility that service curves of all classes couldn't be
-+guaranteed for a brief period. Consider following, a bit more complicated
-+example:
-+
-+Root interface, classes A and B with concave and convex curve (summing up to
-+root), A1 & A2 (children of A), \fIboth\fR with concave curves summing up to A,
-+B1 & B2 (children of B), \fIboth\fR with convex curves summing up to B.
-+
-+Assume that A2, B1 and B2 are constantly backlogged, and at some later point
-+A1 becomes backlogged. We can easily choose slopes, so that even if we
-+"punish" A2 for earlier excess bandwidth received, A1 will have no chance of
-+getting bandwidth corresponding to its first slope. Following from the above
-+example:
-+
-+.nf
-+A  \- 7mbit, then 3mbit
-+A1 \- 5mbit, then 2mbit
-+A2 \- 2mbit, then 1mbit
-+
-+B  \- 3mbit, then 7mbit
-+B1 \- 2mbit, then 5mbit
-+B2 \- 1mbit, then 2mbit
-+.fi
-+
-+At the point when A1 starts sending, it should get 5mbit to not violate its
-+service curve. A2 gets punished and doesn't send at all, B1 and B2 both keep
-+sending at their 5mbit and 2mbit. But as you can see, we already are beyond
-+interface's capacity \- at 12mbit. A1 could get 3mbit at most. If we used
-+virtual times and kept fairness property, A1 and A2 would send at 3mbit
-+together with 5:2 ratio (so respectively at ~2.14mbit and ~0.86mbit).
-+.RE
-+.
-+.SH "UPPERLIMIT CRITERION"
-+.
-+UL criterion is an extensions to LS one, that permits sending packets only
-+if current real time is bigger than fit\-time ('ft'). So the modified LS
-+criterion becomes: choose the smallest virtual time from all active children,
-+such that fit\-time < current real time also holds. Fit\-time is calculated
-+from F(), which is based on UL service curve. As you can see, it's role is
-+kinda similar to E() used in RT criterion. Also, for obvious reasons \- you
-+can't specify UL service curve without LS one.
-+
-+Main purpose of UL service curve is to limit HFSC to bandwidth available on the
-+upstream router (think adsl home modem/router, and linux server as
-+nat/firewall/etc. with 100mbit+ connection to mentioned modem/router).
-+Typically, it's used to create a single class directly under root, setting
-+linear UL service curve to available bandwidth \- and then creating your class
-+structure from that class downwards. Of course, you're free to add UL service
-+(linear or not) curve to any class with LS criterion.
-+
-+Important part about UL service curve is, that whenever at some point in time
-+a class doesn't qualify for linksharing due to its fit\-time, the next time it
-+does qualify, it will update its virtual time to the smallest virtual time of
-+all active children fit for linksharing. This way, one of the main things LS
-+criterion tries to achieve \- equality of all virtual times across whole
-+hierarchy \- is preserved (in perfectly fluid system with only linear curves,
-+all virtual times would be equal).
-+
-+Without that, 'vt' would lag behind other virtual times, and could cause
-+problems. Consider interface with capacity 10mbit, and following leaf classes
-+(just in case you're skipping this text quickly \- this example shows behavior
-+that \f(BIdoesn't happen\fR):
-+
-+.nf
-+A \- ls 5.0mbit
-+B \- ls 2.5mbit
-+C \- ls 2.5mbit, ul 2.5mbit
-+.fi
-+
-+If B was idle, while A and C were constantly backlogged, they would normally
-+(as far as LS criterion is concerned) divide bandwidth in 2:1 ratio. But due
-+to UL service curve in place, C would get at most 2.5mbit, and A would get the
-+remaining 7.5mbit. The longer the backlogged period, the more virtual times of
-+A and C would drift apart. If B became backlogged at some later point in time,
-+its virtual time would be set to (A's\~vt\~+\~C's\~vt)/2, thus blocking A from
-+sending any traffic, until B's virtual time catches up with A.
-+.
-+.SH "SEPARATE LS / RT SCs"
-+.
-+Another difference from original HFSC paper, is that RT and LS SCs can be
-+specified separately. Moreover \- leaf classes are allowed to have only either
-+RT SC or LS SC. For interior classes, only LS SCs make sense \- Any RT SC will
-+be ignored.
-+.
-+.SH "CORNER CASES"
-+.
-+Separate service curves for LS and RT criteria can lead to certain traps,
-+that come from "fighting" between ideal linksharing and enforced realtime
-+guarantees. Those situations didn't exist in original HFSC paper, where
-+specifying separate LS / RT service curves was not discussed.
-+
-+Consider interface with capacity 10mbit, with following leaf classes:
-+
-+.nf
-+A \- ls 5.0mbit, rt 8mbit
-+B \- ls 2.5mbit
-+C \- ls 2.5mbit
-+.fi
-+
-+Imagine A and C are constantly backlogged. As B is idle, A and C would divide
-+bandwidth in 2:1 ratio, considering LS service curve (so in theory \- 6.66 and
-+3.33). Alas RT criterion takes priority, so A will get 8mbit and LS will be
-+able to compensate class C for only 2 mbit \- this will cause discrepancy
-+between virtual times of A and C.
-+
-+Assume this situation lasts for a lot of time with no idle periods, and
-+suddenly B becomes active. B's virtual time will be updated to
-+(A's\~vt\~+\~C's\~vt)/2, effectively landing in the middle between A's and C's
-+virtual time. The effect \- B, having no RT guarantees, will be punished and
-+will not be allowed to transfer until C's virtual time catches up.
-+
-+If the interface had higher capacity \- for example 100mbit, this example
-+would behave perfectly fine though.
-+
-+Let's look a bit closer at the above example \- it "cleverly" invalidates one
-+of the basic things LS criterion tries to achieve \- equality of all virtual
-+times across class hierarchy. Leaf classes without RT service curves are
-+literally left to their own fate (governed by messed up virtual times).
-+
-+Also - it doesn't make much sense. Class A will always be guaranteed up to
-+8mbit, and this is more than any absolute bandwidth that could happen from its
-+LS criterion (excluding trivial case of only A being active). If the bandwidth
-+taken by A is smaller than absolute value from LS criterion, the unused part
-+will be automatically assigned to other active classes (as A has idling periods
-+in such case). The only "advantage" is, that even in case of low bandwidth on
-+average, bursts would be handled at the speed defined by RT criterion. Still,
-+if extra speed is needed (e.g. due to latency), non linear service curves
-+should be used in such case.
-+
-+In the other words - LS criterion is meaningless in the above example.
-+
-+You can quickly "workaround" it by making sure each leaf class has RT service
-+curve assigned (thus guaranteeing all of them will get some bandwidth), but it
-+doesn't make it any more valid.
-+.
-+.SH "LINUX AND TIMER RESOLUTION"
-+.
-+In certain situations, the scheduler can throttle itself and setup so
-+called watchdog to wakeup dequeue function at some time later. In case of HFSC
-+it happens when for example no packet is eligible for scheduling, and UL
-+service curve is used to limit the speed at which LS criterion is allowed to
-+dequeue packets. It's called throttling, and accuracy of it is dependent on
-+how the kernel is compiled.
-+
-+There're 3 important options in modern kernels, as far as timers' resolution
-+goes: \&'tickless system', \&'high resolution timer support' and \&'timer
-+frequency'.
-+
-+If you have \&'tickless system' enabled, then the timer interrupt will trigger
-+as slowly as possible, but each time a scheduler throttles itself (or any
-+other part of the kernel needs better accuracy), the rate will be increased as
-+needed / possible. The ceiling is either \&'timer frequency' if \&'high
-+resolution timer support' is not available or not compiled in. Otherwise it's
-+hardware dependent and can go \fIfar\fR beyond the highest \&'timer frequency'
-+setting available.
-+
-+If \&'tickless system' is not enabled, the timer will trigger at a fixed rate
-+specified by \&'timer frequency' \- regardless if high resolution timers are
-+or aren't available.
-+
-+This is important to keep those settings in mind, as in scenario like: no
-+tickless, no HR timers, frequency set to 100hz \- throttling accuracy would be
-+at 10ms. It doesn't automatically mean you would be limited to ~0.8mbit/s
-+(assuming packets at ~1KB) \- as long as your queues are prepared to cover for
-+timer inaccuracy. Of course, in case of e.g. locally generated udp traffic \-
-+appropriate socket size is needed as well. Short example to make it more
-+understandable (assume hardcore anti\-schedule settings \- HZ=100, no HR
-+timers, no tickless):
-+
-+.nf
-+tc qdisc add dev eth0 root handle 1:0 hfsc default 1
-+tc class add dev eth0 parent 1:0 classid 1:1 hfsc rt m2 10mbit
-+.fi
-+
-+Assuming packet of ~1KB size and HZ=100, that averages to ~0.8mbit \- anything
-+beyond it (e.g. the above example with specified rate over 10x bigger) will
-+require appropriate queuing and cause bursts every ~10 ms.  As you can
-+imagine, any HFSC's RT guarantees will be seriously invalidated by that.
-+Aforementioned example is mainly important if you deal with old hardware \- as
-+it's particularly popular for home server chores. Even then, you can easily
-+set HZ=1000 and have very accurate scheduling for typical adsl speeds.
-+
-+Anything modern (apic or even hpet msi based timers + \&'tickless system')
-+will provide enough accuracy for superb 1gbit scheduling. For example, on one
-+of basically cheap dual core AMD boards I have with following settings:
-+
-+.nf
-+tc qdisc add dev eth0 parent root handle 1:0 hfsc default 1
-+tc class add dev eth0 paretn 1:0 classid 1:1 hfsc rt m2 300mbit
-+.fi
-+
-+And simple:
-+
-+.nf
-+nc \-u dst.host.com 54321 </dev/zero
-+nc \-l \-p 54321 >/dev/null
-+.fi
-+
-+\&...will yield following effects over period of ~10 seconds (taken from
-+/proc/interrupts):
-+
-+.nf
-+319: 42124229   0  HPET_MSI\-edge  hpet2 (before)
-+319: 42436214   0  HPET_MSI\-edge  hpet2 (after 10s.)
-+.fi
-+
-+That's roughly 31000/s. Now compare it with HZ=1000 setting. The obvious
-+drawback of it is that cpu load can be rather extensive with servicing that
-+many timer interrupts. Example with 300mbit RT service curve on 1gbit link is
-+particularly ugly, as it requires a lot of throttling with minuscule delays.
-+
-+Also note that it's just an example showing capability of current hardware.
-+The above example (essentially 300mbit TBF emulator) is pointless on internal
-+interface to begin with \- you will pretty much always want regular LS service
-+curve there, and in such scenario HFSC simply doesn't throttle at all.
-+
-+300mbit RT service curve (selected columns from mpstat \-P ALL 1):
-+
-+.nf
-+10:56:43 PM  CPU  %sys     %irq   %soft   %idle
-+10:56:44 PM  all  20.10    6.53   34.67   37.19
-+10:56:44 PM    0  35.00    0.00   63.00    0.00
-+10:56:44 PM    1   4.95   12.87    6.93   73.27
-+.fi
-+
-+So, in rare case you need those speeds with only RT service curve, or with UL
-+service curve \- remember about drawbacks.
-+.
-+.SH "LAYER2 ADAPTATION"
-+.
-+Please refer to \fBtc\-stab\fR(8)
-+.
-+.SH "SEE ALSO"
-+.
-+\fBtc\fR(8), \fBtc\-hfsc\fR(8), \fBtc\-stab\fR(8)
-+
-+Please direct bugreports and patches to: <net...@vger.kernel.org>
-+.
-+.SH "AUTHOR"
-+.
-+Manpage created by Michal Soltys (sol...@ziu.info)
---- iproute2/man/man8/tc.8
-+++ iproute2-new/man/man8/tc.8
-@@ -368,12 +368,15 @@
- .SH SEE ALSO
- .BR tc-cbq (8),
- .BR tc-htb (8),
-+.BR tc-hfsc (8),
-+.BR tc-hfsc (7),
- .BR tc-sfq (8),
- .BR tc-red (8),
- .BR tc-tbf (8),
- .BR tc-pfifo (8),
- .BR tc-bfifo (8),
- .BR tc-pfifo_fast (8),
-+.BR tc-stab (8),
- .br
- .RB "User documentation at " http://lartc.org/ ", but please direct bugreports and patches to: " <netdev@vger.kernel.org>
- 
---- iproute2/man/man8/tc-hfsc.8
-+++ iproute2-new/man/man8/tc-hfsc.8
-@@ -0,0 +1,61 @@
-+.TH HFSC 8 "25 February 2009" iproute2 Linux
-+.
-+.SH NAME
-+HFSC \- Hierarchical Fair Service Curve's control under linux
-+.
-+.SH SYNOPSIS
-+.nf
-+tc qdisc add ... hfsc [ \fBdefault\fR CLASSID ]
-+
-+tc class add ... hfsc [ [ \fBrt\fR SC ] [ \fBls\fR SC ] | [ \fBsc\fR SC ] ] [ \fBul\fR SC ]
-+
-+\fBrt\fR : realtime service curve
-+\fBls\fR : linkshare service curve
-+\fBsc\fR : rt+ls service curve
-+\fBul\fR : upperlimit service curve
-+
-+\(bu at least one of \fBrt\fR, \fBls\fR or \fBsc\fR must be specified
-+\(bu \fBul\fR can only be specified with \fBls\fR or \fBsc\fR
-+.
-+.IP "SC := [ [ \fBm1\fR BPS ] \fBd\fR SEC ] \fBm2\fR BPS"
-+\fBm1\fR : slope of the first segment
-+\fBd\fR  : x\-coordinate of intersection
-+\fBm2\fR : slope of the second segment
-+.PP
-+.IP "SC := [ [ \fBumax\fR BYTE ] \fBdmax\fR SEC ] \fBrate\fR BPS"
-+\fBumax\fR : maximum unit of work
-+\fBdmax\fR : maximum delay
-+\fBrate\fR : rate
-+.PP
-+.fi
-+For description of BYTE, BPS and SEC \- please see \fBUNITS\fR
-+section of \fBtc\fR(8).
-+.
-+.SH DESCRIPTION (qdisc)
-+HFSC qdisc has only one optional parameter \- \fBdefault\fR.  CLASSID specifies
-+the minor part of the default classid, where packets not classified by other
-+means (e.g. u32 filter, CLASSIFY target of iptables) will be enqueued. If
-+\fBdefault\fR is not specified, unclassified packets will be dropped.
-+.
-+.SH DESCRIPTION (class)
-+HFSC class is used to create a class hierarchy for HFSC scheduler. For
-+explanation of the algorithm, and the meaning behind \fBrt\fR, \fBls\fR,
-+\fBsc\fR and \fBul\fR service curves \- please refer to \fBtc\-hfsc\fR(7).
-+
-+As you can see in \fBSYNOPSIS\fR, service curve (SC) can be specified in two
-+ways. Either as maximum delay for certain amount of work, or as a bandwidth
-+assigned for certain amount of time. Obviously, \fBm1\fR is simply
-+\fBumax\fR/\fBdmax\fR.
-+
-+Both \fBm2\fR and \fBrate\fR are mandatory. If you omit other
-+parameters, you will specify linear service curve.
-+.
-+.SH "SEE ALSO"
-+.
-+\fBtc\fR(8), \fBtc\-hfsc\fR(7), \fBtc\-stab\fR(8)
-+
-+Please direct bugreports and patches to: <net...@vger.kernel.org>
-+.
-+.SH "AUTHOR"
-+.
-+Manpage created by Michal Soltys (sol...@ziu.info)
---- iproute2/man/man8/tc-stab.8
-+++ iproute2-new/man/man8/tc-stab.8
-@@ -0,0 +1,156 @@
-+.TH STAB 8 "25 February 2009" iproute2 Linux
-+.
-+.SH NAME
-+tc\-stab \- Generic size table manipulations
-+.
-+.SH SYNOPSIS
-+.nf
-+tc qdisc add ... stab \\
-+.RS 4
-+[ \fBmtu\fR BYTES ] [ \fBtsize\fR SLOTS ] \\
-+[ \fBmpu\fR BYTES ] [ \fBoverhead\fR BYTES ] [ \fBlinklayer\fR TYPE ] ...
-+.RE
-+
-+TYPE := adsl | atm | ethernet
-+.fi
-+
-+For the description of BYTES \- please refer to the \fBUNITS\fR
-+section of \fBtc\fR(8).
-+
-+.IP \fBmtu\fR 4
-+.br
-+maximum packet size we create size table for, assumed 2048 if not specified explicitly
-+.IP \fBtsize\fR
-+.br
-+required table size, assumed 512 if not specified explicitly
-+.IP \fBmpu\fR
-+.br
-+minimum packet size used in computations
-+.IP \fBoverhead\fR
-+.br
-+per\-packet size overhead (can be negative) used in computations
-+.IP \fBlinklayer\fR
-+.br
-+required linklayer adaptation.
-+.PP
-+.
-+.SH DESCRIPTION
-+.
-+Size tables allow manipulation of packet size, as seen by whole scheduler
-+framework (of course, the actual packet size remains the same). Adjusted packet
-+size is calculated only once \- when a qdisc enqueues the packet. Initial root
-+enqueue initializes it to the real packet's size.
-+
-+Each qdisc can use different size table, but the adjusted size is stored in
-+area shared by whole qdisc hierarchy attached to the interface (technically,
-+it's stored in skb). The effect is, that if you have such setup, the last qdisc
-+with a stab in a chain "wins". For example, consider HFSC with simple pfifo
-+attached to one of its leaf classes. If that pfifo qdisc has stab defined, it
-+will override lengths calculated during HFSC's enqueue, and in turn, whenever
-+HFSC tries to dequeue a packet, it will use potentially invalid size in its
-+calculations. Normal setups will usually include stab defined only on root
-+qdisc, but further overriding gives extra flexibility for less usual setups.
-+
-+Initial size table is calculated by \fBtc\fR tool using \fBmtu\fR and
-+\fBtsize\fR parameters. The algorithm sets each slot's size to the smallest
-+power of 2 value, so the whole \fBmtu\fR is covered by the size table. Neither
-+\fBtsize\fR, nor \fBmtu\fR have to be power of 2 value, so the size
-+table will usually support more than is required by \fBmtu\fR.
-+
-+For example, with \fBmtu\fR\~=\~1500 and \fBtsize\fR\~=\~128, a table with 128
-+slots will be created, where slot 0 will correspond to sizes 0\-16, slot 1 to
-+17\~\-\~32, \&..., slot 127 to 2033\~\-\~2048. Note, that the sizes
-+are shifted 1 byte (normally you would expect 0\~\-\~15, 16\~\-\~31, \&...,
-+2032\~\-\~2047). Sizes assigned to each slot depend on \fBlinklayer\fR parameter.
-+
-+Stab calculation is also safe for an unusual case, when a size assigned to a
-+slot would be larger than 2^16\-1 (you will lose the accuracy though).
-+
-+During kernel part of packet size adjustment, \fBoverhead\fR will be added to
-+original size, and after subtracting 1 (to land in the proper slot \- see above
-+about shifting by 1 byte) slot will be calculated. If the size would cause
-+overflow, more than 1 slot will be used to get the final size. It of course will
-+affect accuracy, but it's only a guard against unusual situations.
-+
-+Currently there're two methods of creating values stored in the size table \-
-+ethernet and atm (adsl):
-+
-+.IP ethernet 4
-+.br
-+This is basically 1\-1 mapping, so following our example from above
-+(disregarding \fBmpu\fR for a moment) slot 0 would have 8, slot 1 would have 16
-+and so on, up to slot 127 with 2048. Note, that \fBmpu\fR\~>\~0 must be
-+specified, and slots that would get less than specified by \fBmpu\fR, will get
-+\fBmpu\fR instead. If you don't specify \fBmpu\fR, the size table will not be
-+created at all, although any \fBoverhead\fR value will be respected during
-+calculations.
-+.IP "atm, adsl"
-+.br
-+ATM linklayer consists of 53 byte cells, where each of them provides 48 bytes
-+for payload. Also all the cells must be fully utilized, thus the last one is
-+padded if/as necessary.
-+
-+When size table is calculated, adjusted size that fits properly into lowest
-+amount of cells is assigned to a slot. For example, a 100 byte long packet
-+requires three 48\-byte payloads, so the final size would require 3 ATM cells
-+\- 159 bytes.
-+
-+For ATM size tables, 16\~bytes sized slots are perfectly enough. The default
-+values of \fBmtu\fR and \fBtsize\fR create 4\~bytes sized slots.
-+.PP
-+.
-+.SH "TYPICAL OVERHEADS"
-+The following values are typical for different adsl scenarios (based on
-+\fB[1]\fR and \fB[2]\fR):
-+
-+.nf
-+LLC based:
-+.RS 4
-+PPPoA \- 14 (PPP \- 2, ATM \- 12)
-+PPPoE \- 40+ (PPPoE \- 8, ATM \- 18, ethernet 14, possibly FCS \- 4+padding)
-+Bridged \- 32 (ATM \- 18, ethernet 14, possibly FCS \- 4+padding)
-+IPoA \- 16 (ATM \- 16)
-+.RE
-+
-+VC Mux based:
-+.RS 4
-+PPPoA \- 10 (PPP \- 2, ATM \- 8)
-+PPPoE \- 32+ (PPPoE \- 8, ATM \- 10, ethernet 14, possibly FCS \- 4+padding)
-+Bridged \- 24+ (ATM \- 10, ethernet 14, possibly FCS \- 4+padding)
-+IPoA \- 8 (ATM \- 8)
-+.RE
-+.fi
-+\p There're few important things regarding the above overheads:
-+.
-+.IP \(bu 4
-+IPoA in LLC case requires SNAP, instead of LLC\-NLPID (see rfc2684) \- this is
-+the reason, why it actually takes more space than PPPoA.
-+.IP \(bu
-+In rare cases, FCS might be preserved on protocols that include ethernet frame
-+(Bridged and PPPoE).  In such situation, any ethernet specific padding
-+guaranteeing 64 bytes long frame size has to be included as well (see rfc2684).
-+In the other words, it also guarantees that any packet you send will take
-+minimum 2 atm cells. You should set \fBmpu\fR accordingly for that.
-+.IP \(bu
-+When size table is consulted, and you're shaping traffic for the sake of
-+another modem/router, ethernet header (without padding) will already be added
-+to initial packet's length. You should compensate for that by subtracting 14
-+from the above overheads in such case. If you're shaping directly on the router
-+(for example, with speedtouch usb modem) using ppp daemon, layer2 header will
-+not be added yet.
-+
-+For more thorough explanations, please see \fB[1]\fR and \fB[2]\fR.
-+.
-+.SH "SEE ALSO"
-+.
-+\fBtc\fR(8), \fBtc\-hfsc\fR(7), \fBtc\-hfsc\fR(8),
-+.br
-+\fB[1]\fR http://ace\-host.stuart.id.au/russell/files/tc/tc\-atm/
-+.br
-+\fB[2]\fR http://www.faqs.org/rfcs/rfc2684.html
-+
-+Please direct bugreports and patches to: <net...@vger.kernel.org>
-+.
-+.SH "AUTHOR"
-+.
-+Manpage created by Michal Soltys (sol...@ziu.info)
---- iproute2/tc/q_hfsc.c
-+++ iproute2-new/tc/q_hfsc.c
-@@ -43,7 +43,7 @@
- 	fprintf(stderr,
- 		"Usage: ... hfsc [ [ rt SC ] [ ls SC ] | [ sc SC ] ] [ ul SC ]\n"
- 		"\n"
--		"SC := [ [ m1 BPS ] [ d SEC ] m2 BPS\n"
-+		"SC := [ [ m1 BPS ] d SEC ] m2 BPS\n"
- 		"\n"
- 		" m1 : slope of first segment\n"
- 		" d  : x-coordinate of intersection\n"
-@@ -57,6 +57,10 @@
- 		" dmax : maximum delay\n"
- 		" rate : rate\n"
- 		"\n"
-+		"Remarks:\n"
-+		" - at least one of 'rt', 'ls' or 'sc' must be specified\n"
-+		" - 'ul' can only be specified with 'ls' or 'sc'\n"
-+		"\n"
- 	);
- }
- 
---- iproute2/tc/tc_core.c
-+++ iproute2-new/tc/tc_core.c
-@@ -155,12 +155,12 @@
- 	}
- 
- 	if (s->mtu == 0)
--		s->mtu = 2047;
-+		s->mtu = 2048;
- 	if (s->tsize == 0)
- 		s->tsize = 512;
- 
- 	s->cell_log = 0;
--	while ((s->mtu >> s->cell_log) > s->tsize - 1)
-+	while ((s->mtu - 1 >> s->cell_log) > s->tsize - 1)
- 		s->cell_log++;
- 
- 	*stab = malloc(s->tsize * sizeof(__u16));
---- iproute2/tc/tc_stab.c
-+++ iproute2-new/tc/tc_stab.c
-@@ -32,11 +32,15 @@
- 	fprintf(stderr,
- 		"Usage: ... stab [ mtu BYTES ] [ tsize SLOTS ] [ mpu BYTES ] \n"
- 		"                [ overhead BYTES ] [ linklayer TYPE ] ...\n"
--		"   mtu       : max packet size we create rate map for {2047}\n"
-+		"TYPE := adsl | atm | ethernet\n"
-+		"   mtu       : max packet size we create size table for {2048}\n"
- 		"   tsize     : how many slots should size table have {512}\n"
- 		"   mpu       : minimum packet size used in rate computations\n"
- 		"   overhead  : per-packet size overhead used in rate computations\n"
- 		"   linklayer : adapting to a linklayer e.g. atm\n"
-+		"   mpu       : minimum packet size used in size table computations\n"
-+		"   overhead  : per-packet size overhead used in size table computations\n"
-+		"   linklayer : required linklayer adaptation, (adsl and atm are synonyms)\n"
- 		"Example: ... stab overhead 20 linklayer atm\n");
- 
- 	return;
diff --git a/sys-apps/iproute2/files/iproute2-2.6.35-cached-routes.patch b/sys-apps/iproute2/files/iproute2-2.6.35-cached-routes.patch
deleted file mode 100644
index 821d8c3fae5a..000000000000
--- a/sys-apps/iproute2/files/iproute2-2.6.35-cached-routes.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-http://bugs.gentoo.org/331447
-
-From c73f3e02f8ae25e5daad0367690a3069895dd8a3 Mon Sep 17 00:00:00 2001
-From: Ulrich Weber <uweber@astaro.com>
-Date: Thu, 12 Aug 2010 11:05:19 +0200
-Subject: [PATCH] iproute2: dont filter cached routes on iproute_get
-
-iproute_get will return cloned routes for IPv4
-and cloned as well non-cloned routes for IPv6.
-
-Therefore RTM_F_CLONED flag should not be checked
-for iproute_get routes. Check in print_route will
-always fail because valid values are 0 and 1.
-
-Signed-off-by: Ulrich Weber <uweber@astaro.com>
----
- ip/iproute.c |    1 +
- 1 files changed, 1 insertions(+), 0 deletions(-)
-
-diff --git a/ip/iproute.c b/ip/iproute.c
-index 711576e..b43933c 100644
---- a/ip/iproute.c
-+++ b/ip/iproute.c
-@@ -1286,6 +1286,7 @@ int iproute_get(int argc, char **argv)
- 	memset(&req, 0, sizeof(req));
- 
- 	iproute_reset_filter();
-+	filter.cloned = 2;
- 
- 	req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct rtmsg));
- 	req.n.nlmsg_flags = NLM_F_REQUEST;
--- 
-1.7.2
-
diff --git a/sys-apps/iproute2/files/iproute2-2.6.35-no-iptables.patch b/sys-apps/iproute2/files/iproute2-2.6.35-no-iptables.patch
deleted file mode 100644
index a51cf78ac8df..000000000000
--- a/sys-apps/iproute2/files/iproute2-2.6.35-no-iptables.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-diff --git a/tc/Makefile b/tc/Makefile
-index 3aa9f26..0a827da 100644
---- a/tc/Makefile
-+++ b/tc/Makefile
-@@ -58,7 +58,9 @@ else
- 	CFLAGS += -DTC_CONFIG_XT_H
- 	TCSO += m_xt_old.so
-     else
--      TCMODULES += m_ipt.o
-+      ifneq ($(TC_CONFIG_XT),n)
-+        TCMODULES += m_ipt.o
-+      endif
-     endif
-   endif
- endif
diff --git a/sys-apps/iproute2/files/iproute2-2.6.35-no-ipv6.patch b/sys-apps/iproute2/files/iproute2-2.6.35-no-ipv6.patch
deleted file mode 100644
index d82c8873344c..000000000000
--- a/sys-apps/iproute2/files/iproute2-2.6.35-no-ipv6.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-https://bugs.gentoo.org/326849
-
-allow ipv6 to be disabled
-
---- iproute2-2.6.31/ip/iptunnel.c
-+++ iproute2-2.6.31/ip/iptunnel.c
-@@ -456,13 +456,6 @@ int do_iptunnel(int argc, char **argv)
- 		break;
- 	case AF_INET:
- 		break;
--	/*
--	 * This is silly enough but we have no easy way to make it
--	 * protocol-independent because of unarranged structure between
--	 * IPv4 and IPv6.
--	 */
--	case AF_INET6:
--		return do_ip6tunnel(argc, argv);
- 	default:
- 		fprintf(stderr, "Unsupported family:%d\n", preferred_family);
- 		exit(-1);
---- iproute2-2.6.31/ip/Makefile
-+++ iproute2-2.6.31/ip/Makefile
-@@ -1,4 +1,4 @@
- IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o \
--    rtm_map.o iptunnel.o ip6tunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \
-+    rtm_map.o iptunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \
-     ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o \
diff --git a/sys-apps/iproute2/files/iproute2-2.6.35-xtables.patch b/sys-apps/iproute2/files/iproute2-2.6.35-xtables.patch
deleted file mode 100644
index 748c77bde828..000000000000
--- a/sys-apps/iproute2/files/iproute2-2.6.35-xtables.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-From 035ea3a8a1c9f67721fa0b53540620c7c49bc8ab Mon Sep 17 00:00:00 2001
-From: Mike Frysinger <vapier@gentoo.org>
-Date: Sun, 21 Nov 2010 16:07:26 -0500
-Subject: [PATCH] m_xt: stop using xtables_set_revision()
-
-iptables dropped the xtables_set_revision() function around version 1.4.9,
-so set the rev directly ourselves.  This should be compatible back to the
-original version m_xt itself is designed for.
-
-Signed-off-by: Mike Frysinger <vapier@gentoo.org>
----
- tc/m_xt.c |    2 +-
- 1 files changed, 1 insertions(+), 1 deletions(-)
-
-diff --git a/tc/m_xt.c b/tc/m_xt.c
-index bfc4937..ede9913 100644
---- a/tc/m_xt.c
-+++ b/tc/m_xt.c
-@@ -88,7 +88,7 @@ build_st(struct xtables_target *target, struct xt_entry_target *t)
- 		target->t = xtables_calloc(1, size);
- 		target->t->u.target_size = size;
- 		strcpy(target->t->u.user.name, target->name);
--		xtables_set_revision(target->t->u.user.name, target->revision);
-+		target->t->u.user.revision = target->revision;
- 
- 		if (target->init != NULL)
- 			target->init(target->t);
--- 
-1.7.3.1
-
diff --git a/sys-apps/iproute2/files/iproute2-2.6.38-parallel-build.patch b/sys-apps/iproute2/files/iproute2-2.6.38-parallel-build.patch
deleted file mode 100644
index 7966cfce5044..000000000000
--- a/sys-apps/iproute2/files/iproute2-2.6.38-parallel-build.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-sent upstream already
-
-From f8a783bbe98b0fe5aaedbf623bc70471b88c9187 Mon Sep 17 00:00:00 2001
-From: Mike Frysinger <vapier@gentoo.org>
-Date: Tue, 18 Oct 2011 17:36:55 -0400
-Subject: [PATCH] tc: fix parallel build file with lex/yacc
-
-Building iproute2 in parallel might hit the race failure:
-	emp_ematch.l:2:30: fatal error: emp_ematch.yacc.h:
-		No such file or directory
-	make[1]: *** [emp_ematch.lex.o] Error 1
-
-This is because we currently allow the yacc/lex files to generate and
-compile in parallel.  So add a simple dependency to make sure yacc has
-finished before we attempt to compile the lex output.
-
-Signed-off-by: Mike Frysinger <vapier@gentoo.org>
----
- tc/Makefile |    5 +++++
- 1 files changed, 5 insertions(+), 0 deletions(-)
-
-diff --git a/tc/Makefile b/tc/Makefile
-index 08aa4ce..b2ca165 100644
---- a/tc/Makefile
-+++ b/tc/Makefile
-@@ -136,6 +136,11 @@ m_xt_old.so: m_xt_old.c
- %.lex.c: %.l
- 	$(LEX) $(LEXFLAGS) -o$@ $<
- 
-+# our lexer includes the header from yacc, so make sure
-+# we don't attempt to compile it before the header has
-+# been generated as part of the yacc step.
-+emp_ematch.lex.o: emp_ematch.yacc.c
-+
- ifneq ($(SHARED_LIBS),y)
- 
- tc: static-syms.o
--- 
-1.7.6.1
-
diff --git a/sys-apps/iproute2/files/iproute2-3.1.0-no-ipv6.patch b/sys-apps/iproute2/files/iproute2-3.1.0-no-ipv6.patch
deleted file mode 100644
index 1282a1b59f9b..000000000000
--- a/sys-apps/iproute2/files/iproute2-3.1.0-no-ipv6.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-https://bugs.gentoo.org/326849
-
-allow ipv6 to be disabled
-
---- a/ip/iptunnel.c
-+++ b/ip/iptunnel.c
-@@ -456,13 +456,6 @@ int do_iptunnel(int argc, char **argv)
- 		break;
- 	case AF_INET:
- 		break;
--	/*
--	 * This is silly enough but we have no easy way to make it
--	 * protocol-independent because of unarranged structure between
--	 * IPv4 and IPv6.
--	 */
--	case AF_INET6:
--		return do_ip6tunnel(argc, argv);
- 	default:
- 		fprintf(stderr, "Unsupported family:%d\n", preferred_family);
- 		exit(-1);
---- a/ip/Makefile
-+++ b/ip/Makefile
-@@ -1,6 +1,6 @@
- IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o ipnetns.o \
--    rtm_map.o iptunnel.o ip6tunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \
--    ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o iptuntap.o \
-+    rtm_map.o iptunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \
-+    ipmaddr.o ipmonitor.o ipmroute.o iptuntap.o \
-     ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o \
-     iplink_vlan.o link_veth.o link_gre.o iplink_can.o \
-     iplink_macvlan.o iplink_macvtap.o ipl2tp.o
---- a/ip/ipmonitor.c
-+++ b/ip/ipmonitor.c
-@@ -76,7 +76,6 @@ int accept_msg(const struct sockaddr_nl *who,
- 	if (n->nlmsg_type == RTM_NEWPREFIX) {
- 		if (prefix_banner)
- 			fprintf(fp, "[PREFIX]");
--		print_prefix(who, n, arg);
- 		return 0;
- 	}
- 	if (n->nlmsg_type == RTM_NEWRULE || n->nlmsg_type == RTM_DELRULE) {
diff --git a/sys-apps/iproute2/files/iproute2-3.10.0-no-ipv6.patch b/sys-apps/iproute2/files/iproute2-3.10.0-no-ipv6.patch
deleted file mode 100644
index 86d80d2d8742..000000000000
--- a/sys-apps/iproute2/files/iproute2-3.10.0-no-ipv6.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-https://bugs.gentoo.org/326849
-
-allow ipv6 to be disabled
-
---- a/ip/iptunnel.c
-+++ b/ip/iptunnel.c
-@@ -629,13 +629,6 @@ int do_iptunnel(int argc, char **argv)
- 		break;
- 	case AF_INET:
- 		break;
--	/*
--	 * This is silly enough but we have no easy way to make it
--	 * protocol-independent because of unarranged structure between
--	 * IPv4 and IPv6.
--	 */
--	case AF_INET6:
--		return do_ip6tunnel(argc, argv);
- 	default:
- 		fprintf(stderr, "Unsupported protocol family: %d\n", preferred_family);
- 		exit(-1);
---- a/ip/Makefile
-+++ b/ip/Makefile
-@@ -1,6 +1,6 @@
- IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o ipnetns.o \
--    rtm_map.o iptunnel.o ip6tunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \
--    ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o iptuntap.o iptoken.o \
-+    rtm_map.o iptunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \
-+    ipmaddr.o ipmonitor.o ipmroute.o iptuntap.o iptoken.o \
-     ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o \
-     iplink_vlan.o link_veth.o link_gre.o iplink_can.o \
-     iplink_macvlan.o iplink_macvtap.o ipl2tp.o link_vti.o \
---- a/ip/ipmonitor.c
-+++ b/ip/ipmonitor.c
-@@ -96,7 +96,6 @@ static int accept_msg(const struct socka
- 	if (n->nlmsg_type == RTM_NEWPREFIX) {
- 		if (prefix_banner)
- 			fprintf(fp, "[PREFIX]");
--		print_prefix(who, n, arg);
- 		return 0;
- 	}
- 	if (n->nlmsg_type == RTM_NEWRULE || n->nlmsg_type == RTM_DELRULE) {
diff --git a/sys-apps/iproute2/files/iproute2-3.6.0-pkg-config.patch b/sys-apps/iproute2/files/iproute2-3.6.0-pkg-config.patch
deleted file mode 100644
index fcfee292994b..000000000000
--- a/sys-apps/iproute2/files/iproute2-3.6.0-pkg-config.patch
+++ /dev/null
@@ -1,67 +0,0 @@
-From 99762cbc216bb818e9fcbe37e1abf9b313968615 Mon Sep 17 00:00:00 2001
-From: Mike Frysinger <vapier@gentoo.org>
-Date: Thu, 8 Nov 2012 11:31:26 -0500
-Subject: [PATCH] allow pkg-config to be customized
-
-Rather than hard coding `pkg-config`, use ${PKG_CONFIG} so people can
-override it to their specific version (like when cross-compiling).
-
-This is the same way the upstream pkg-config code works.
-
-Signed-off-by: Mike Frysinger <vapier@gentoo.org>
----
- configure   | 6 ++++--
- tc/Makefile | 4 ++--
- 2 files changed, 6 insertions(+), 4 deletions(-)
-
-diff --git a/configure b/configure
-index 2c2d1c4..0bfedf9 100755
---- a/configure
-+++ b/configure
-@@ -2,6 +2,8 @@
- # This is not an autconf generated configure
- #
- INCLUDE=${1:-"$PWD/include"}
-+: ${PKG_CONFIG:=pkg-config}
-+echo "PKG_CONFIG:=${PKG_CONFIG}" >>Config
- 
- # Make a temp directory in build tree.
- TMPDIR=$(mktemp -d config.XXXXXX)
-@@ -51,7 +53,7 @@ int main(int argc, char **argv)
- 
- EOF
- 
--if gcc -I$INCLUDE $IPTC -o $TMPDIR/ipttest $TMPDIR/ipttest.c $IPTL $(pkg-config xtables --cflags --libs) -ldl >/dev/null 2>&1
-+if gcc -I$INCLUDE $IPTC -o $TMPDIR/ipttest $TMPDIR/ipttest.c $IPTL $(${PKG_CONFIG} xtables --cflags --libs) -ldl >/dev/null 2>&1
- then
- 	echo "TC_CONFIG_XT:=y" >>Config
- 	echo "using xtables"
-@@ -148,7 +150,7 @@ check_ipt()
- 
- check_ipt_lib_dir()
- {
--	IPT_LIB_DIR=$(pkg-config --variable=xtlibdir xtables)
-+	IPT_LIB_DIR=$(${PKG_CONFIG} --variable=xtlibdir xtables)
- 	if [ -n "$IPT_LIB_DIR" ]; then
- 		echo $IPT_LIB_DIR
- 		echo "IPT_LIB_DIR:=$IPT_LIB_DIR" >> Config
-diff --git a/tc/Makefile b/tc/Makefile
-index 389029d..696f891 100644
---- a/tc/Makefile
-+++ b/tc/Makefile
-@@ -135,10 +135,10 @@ q_atm.so: q_atm.c
- 	$(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o q_atm.so q_atm.c -latm
- 
- m_xt.so: m_xt.c
--	$(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt.so m_xt.c $$(pkg-config xtables --cflags --libs)
-+	$(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt.so m_xt.c $$($(PKG_CONFIG) xtables --cflags --libs)
- 
- m_xt_old.so: m_xt_old.c
--	$(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt_old.so m_xt_old.c $$(pkg-config xtables --cflags --libs)
-+	$(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt_old.so m_xt_old.c $$($(PKG_CONFIG) xtables --cflags --libs)
- 
- %.yacc.c: %.y
- 	$(YACC) $(YACCFLAGS) -o $@ $<
--- 
-1.7.12.4
-
diff --git a/sys-apps/iproute2/files/iproute2-3.7.0-clang.patch b/sys-apps/iproute2/files/iproute2-3.7.0-clang.patch
deleted file mode 100644
index 17bb6ac856b3..000000000000
--- a/sys-apps/iproute2/files/iproute2-3.7.0-clang.patch
+++ /dev/null
@@ -1,72 +0,0 @@
-From 048bff6e0206bca33ee70516521f3048e7714752 Mon Sep 17 00:00:00 2001
-From: Mike Frysinger <vapier@gentoo.org>
-Date: Thu, 17 Jan 2013 18:00:50 +0000
-Subject: [PATCH] ipxfrm: use alloca to allocate stack space
-
-Clang doesn't support the gcc extension for embeddeding flexible arrays
-inside of structures.  Use the slightly more portable alloca().
-
-Signed-off-by: Mike Frysinger <vapier@gentoo.org>
----
- ip/ipxfrm.c | 27 +++++++++++----------------
- 1 file changed, 11 insertions(+), 16 deletions(-)
-
-diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
-index c7b3420..dda4a7a 100644
---- a/ip/ipxfrm.c
-+++ b/ip/ipxfrm.c
-@@ -25,6 +25,7 @@
-  *	Masahide NAKAMURA @USAGI
-  */
- 
-+#include <alloca.h>
- #include <stdio.h>
- #include <stdlib.h>
- #include <string.h>
-@@ -555,16 +556,13 @@ static inline void xfrm_algo_print(struct xfrm_algo *algo, int type, int len,
- static void xfrm_aead_print(struct xfrm_algo_aead *algo, int len,
- 			    FILE *fp, const char *prefix)
- {
--	struct {
--		struct xfrm_algo algo;
--		char key[algo->alg_key_len / 8];
--	} base;
-+	struct xfrm_algo *base_algo = alloca(sizeof(*base_algo) + algo->alg_key_len / 8);
- 
--	memcpy(base.algo.alg_name, algo->alg_name, sizeof(base.algo.alg_name));
--	base.algo.alg_key_len = algo->alg_key_len;
--	memcpy(base.algo.alg_key, algo->alg_key, algo->alg_key_len / 8);
-+	memcpy(base_algo->alg_name, algo->alg_name, sizeof(base_algo->alg_name));
-+	base_algo->alg_key_len = algo->alg_key_len;
-+	memcpy(base_algo->alg_key, algo->alg_key, algo->alg_key_len / 8);
- 
--	__xfrm_algo_print(&base.algo, XFRMA_ALG_AEAD, len, fp, prefix, 0);
-+	__xfrm_algo_print(base_algo, XFRMA_ALG_AEAD, len, fp, prefix, 0);
- 
- 	fprintf(fp, " %d", algo->alg_icv_len);
- 
-@@ -574,16 +572,13 @@ static void xfrm_aead_print(struct xfrm_algo_aead *algo, int len,
- static void xfrm_auth_trunc_print(struct xfrm_algo_auth *algo, int len,
- 				  FILE *fp, const char *prefix)
- {
--	struct {
--		struct xfrm_algo algo;
--		char key[algo->alg_key_len / 8];
--	} base;
-+	struct xfrm_algo *base_algo = alloca(sizeof(*base_algo) + algo->alg_key_len / 8);
- 
--	memcpy(base.algo.alg_name, algo->alg_name, sizeof(base.algo.alg_name));
--	base.algo.alg_key_len = algo->alg_key_len;
--	memcpy(base.algo.alg_key, algo->alg_key, algo->alg_key_len / 8);
-+	memcpy(base_algo->alg_name, algo->alg_name, sizeof(base_algo->alg_name));
-+	base_algo->alg_key_len = algo->alg_key_len;
-+	memcpy(base_algo->alg_key, algo->alg_key, algo->alg_key_len / 8);
- 
--	__xfrm_algo_print(&base.algo, XFRMA_ALG_AUTH_TRUNC, len, fp, prefix, 0);
-+	__xfrm_algo_print(base_algo, XFRMA_ALG_AUTH_TRUNC, len, fp, prefix, 0);
- 
- 	fprintf(fp, " %d", algo->alg_trunc_len);
- 
--- 
-1.8.0.2
-
diff --git a/sys-apps/iproute2/files/iproute2-3.7.0-man7.patch b/sys-apps/iproute2/files/iproute2-3.7.0-man7.patch
deleted file mode 100644
index 947714adf832..000000000000
--- a/sys-apps/iproute2/files/iproute2-3.7.0-man7.patch
+++ /dev/null
@@ -1,55 +0,0 @@
-From 18c1de8d742792d43ff81ebff9af5389e5be7cae Mon Sep 17 00:00:00 2001
-From: Mike Frysinger <vapier@gentoo.org>
-Date: Fri, 11 Jan 2013 11:34:08 -0500
-Subject: [PATCH] [iproute2] add man7 to subdirs list
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The man dir misses the man7 as a subdir which means none of the pages
-get installed.
-
-URL: https://bugs.gentoo.org/451166
-Reported-by: Marcin Mirosław <bug@mejor.pl>
-Signed-off-by: Mike Frysinger <vapier@gentoo.org>
----
- man/Makefile      |  2 +-
- man/man7/Makefile | 13 +++++++++++++
- 2 files changed, 14 insertions(+), 1 deletion(-)
- create mode 100644 man/man7/Makefile
-
-diff --git a/man/Makefile b/man/Makefile
-index 67fea05..9a60fa7 100644
---- a/man/Makefile
-+++ b/man/Makefile
-@@ -2,7 +2,7 @@ INSTALL=install
- INSTALLDIR=install -m 0755 -d
- INSTALLMAN=install -m 0644
- 
--SUBDIRS = man3 man8
-+SUBDIRS = man3 man7 man8
- 
- all:
- 	@for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir; done
-diff --git a/man/man7/Makefile b/man/man7/Makefile
-new file mode 100644
-index 0000000..ccfd839
---- /dev/null
-+++ b/man/man7/Makefile
-@@ -0,0 +1,13 @@
-+MAN7PAGES = tc-hfsc.7
-+
-+all:
-+
-+distclean: clean
-+
-+clean:
-+
-+install:
-+	$(INSTALLDIR) $(DESTDIR)$(MANDIR)/man7
-+	$(INSTALLMAN) $(MAN7PAGES) $(DESTDIR)$(MANDIR)/man7
-+
-+.PHONY: install clean distclean
--- 
-1.8.0.2
-
diff --git a/sys-apps/iproute2/files/iproute2-3.8.0-old-mount-libc.patch b/sys-apps/iproute2/files/iproute2-3.8.0-old-mount-libc.patch
deleted file mode 100644
index 96280e042453..000000000000
--- a/sys-apps/iproute2/files/iproute2-3.8.0-old-mount-libc.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-From 03fdb011dd661315a83998af8af779d8f089e3fe Mon Sep 17 00:00:00 2001
-From: Stephen Hemminger <stephen@networkplumber.org>
-Date: Wed, 17 Apr 2013 13:33:26 -0700
-Subject: [PATCH] ipnetns: fix build on older systems
-
-Debian Squeeze has out of date <sys/mount.h> without the required flags.
----
- ip/ipnetns.c | 14 ++++++++++++++
- 1 file changed, 14 insertions(+)
-
-diff --git a/ip/ipnetns.c b/ip/ipnetns.c
-index b047b97..c9bc20a 100644
---- a/ip/ipnetns.c
-+++ b/ip/ipnetns.c
-@@ -29,6 +29,20 @@
- #define MNT_DETACH	0x00000002	/* Just detach from the tree */
- #endif /* MNT_DETACH */
- 
-+/* sys/mount.h may be out too old to have these */
-+#ifndef MS_REC
-+#define MS_REC		16384
-+#endif
-+
-+#ifndef MS_SLAVE
-+#define MS_SLAVE	(1 << 19)
-+#endif
-+
-+#ifndef MS_SHARED
-+#define MS_SHARED	(1 << 20)
-+#endif
-+
-+
- #ifndef HAVE_SETNS
- static int setns(int fd, int nstype)
- {
--- 
-1.8.2.1
-
diff --git a/sys-apps/iproute2/files/iproute2-4.0.0-tc-show-buffer-overflow.patch b/sys-apps/iproute2/files/iproute2-4.0.0-tc-show-buffer-overflow.patch
deleted file mode 100644
index 6c6c9a5c4308..000000000000
--- a/sys-apps/iproute2/files/iproute2-4.0.0-tc-show-buffer-overflow.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-https://bugs.gentoo.org/546928
-
-From 46679bbbe89699016d31486de7599590d02a5054 Mon Sep 17 00:00:00 2001
-From: Vadim Kochan <vadim4j@gmail.com>
-Date: Mon, 20 Apr 2015 08:33:32 +0300
-Subject: [PATCH] tc util: Fix possible buffer overflow when print class id
-
-Use correct handle buffer length.
-
-Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
----
- tc/tc_util.c | 19 ++++++++++---------
- 1 file changed, 10 insertions(+), 9 deletions(-)
-
-diff --git a/tc/tc_util.c b/tc/tc_util.c
-index 1d3153d..dc2b70f 100644
---- a/tc/tc_util.c
-+++ b/tc/tc_util.c
-@@ -128,30 +128,31 @@ ok:
- 	return 0;
- }
- 
--int print_tc_classid(char *buf, int len, __u32 h)
-+int print_tc_classid(char *buf, int blen, __u32 h)
- {
--	char handle[40] = {};
-+	SPRINT_BUF(handle) = {};
-+	int hlen = SPRINT_BSIZE - 1;
- 
- 	if (h == TC_H_ROOT)
- 		sprintf(handle, "root");
- 	else if (h == TC_H_UNSPEC)
--		snprintf(handle, len, "none");
-+		snprintf(handle, hlen, "none");
- 	else if (TC_H_MAJ(h) == 0)
--		snprintf(handle, len, ":%x", TC_H_MIN(h));
-+		snprintf(handle, hlen, ":%x", TC_H_MIN(h));
- 	else if (TC_H_MIN(h) == 0)
--		snprintf(handle, len, "%x:", TC_H_MAJ(h) >> 16);
-+		snprintf(handle, hlen, "%x:", TC_H_MAJ(h) >> 16);
- 	else
--		snprintf(handle, len, "%x:%x", TC_H_MAJ(h) >> 16, TC_H_MIN(h));
-+		snprintf(handle, hlen, "%x:%x", TC_H_MAJ(h) >> 16, TC_H_MIN(h));
- 
- 	if (use_names) {
- 		char clname[IDNAME_MAX] = {};
- 
- 		if (id_to_name(cls_names, h, clname))
--			snprintf(buf, len, "%s#%s", clname, handle);
-+			snprintf(buf, blen, "%s#%s", clname, handle);
- 		else
--			snprintf(buf, len, "%s", handle);
-+			snprintf(buf, blen, "%s", handle);
- 	} else {
--		snprintf(buf, len, "%s", handle);
-+		snprintf(buf, blen, "%s", handle);
- 	}
- 
- 	return 0;
--- 
-2.3.5
-