diff options
author | Robin H. Johnson <robbat2@gentoo.org> | 2015-08-08 13:49:04 -0700 |
---|---|---|
committer | Robin H. Johnson <robbat2@gentoo.org> | 2015-08-08 17:38:18 -0700 |
commit | 56bd759df1d0c750a065b8c845e93d5dfa6b549d (patch) | |
tree | 3f91093cdb475e565ae857f1c5a7fd339e2d781e /sys-apps/iproute2/files | |
download | gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.tar.gz gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.tar.bz2 gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.zip |
proj/gentoo: Initial commit
This commit represents a new era for Gentoo:
Storing the gentoo-x86 tree in Git, as converted from CVS.
This commit is the start of the NEW history.
Any historical data is intended to be grafted onto this point.
Creation process:
1. Take final CVS checkout snapshot
2. Remove ALL ChangeLog* files
3. Transform all Manifests to thin
4. Remove empty Manifests
5. Convert all stale $Header$/$Id$ CVS keywords to non-expanded Git $Id$
5.1. Do not touch files with -kb/-ko keyword flags.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
X-Thanks: Alec Warner <antarus@gentoo.org> - did the GSoC 2006 migration tests
X-Thanks: Robin H. Johnson <robbat2@gentoo.org> - infra guy, herding this project
X-Thanks: Nguyen Thai Ngoc Duy <pclouds@gentoo.org> - Former Gentoo developer, wrote Git features for the migration
X-Thanks: Brian Harring <ferringb@gentoo.org> - wrote much python to improve cvs2svn
X-Thanks: Rich Freeman <rich0@gentoo.org> - validation scripts
X-Thanks: Patrick Lauer <patrick@gentoo.org> - Gentoo dev, running new 2014 work in migration
X-Thanks: Michał Górny <mgorny@gentoo.org> - scripts, QA, nagging
X-Thanks: All of other Gentoo developers - many ideas and lots of paint on the bikeshed
Diffstat (limited to 'sys-apps/iproute2/files')
16 files changed, 1694 insertions, 0 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 new file mode 100644 index 000000000000..39e07995da5c --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-2.6.26-ldflags.patch @@ -0,0 +1,15 @@ +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 new file mode 100644 index 000000000000..8eb32280986e --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-2.6.29.1-flush.patch @@ -0,0 +1,224 @@ +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 new file mode 100644 index 000000000000..4f39ded905c1 --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-2.6.29.1-hfsc.patch @@ -0,0 +1,885 @@ +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 new file mode 100644 index 000000000000..821d8c3fae5a --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-2.6.35-cached-routes.patch @@ -0,0 +1,34 @@ +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 new file mode 100644 index 000000000000..a51cf78ac8df --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-2.6.35-no-iptables.patch @@ -0,0 +1,15 @@ +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 new file mode 100644 index 000000000000..d82c8873344c --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-2.6.35-no-ipv6.patch @@ -0,0 +1,27 @@ +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 new file mode 100644 index 000000000000..748c77bde828 --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-2.6.35-xtables.patch @@ -0,0 +1,30 @@ +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 new file mode 100644 index 000000000000..7966cfce5044 --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-2.6.38-parallel-build.patch @@ -0,0 +1,40 @@ +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-mtu.patch b/sys-apps/iproute2/files/iproute2-3.1.0-mtu.patch new file mode 100644 index 000000000000..fa12dad2d79e --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-3.1.0-mtu.patch @@ -0,0 +1,48 @@ +http://bugs.gentoo.org/291907 + +This patch was merged from two patches extracted from this thread: +http://markmail.org/thread/qkd76gpdgefpjlfn + +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/tc/tc_core.c ++++ iproute2/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/tc/tc_stab.c +@@ -32,7 +32,7 @@ + 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" ++ " 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" 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 new file mode 100644 index 000000000000..1282a1b59f9b --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-3.1.0-no-ipv6.patch @@ -0,0 +1,41 @@ +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 new file mode 100644 index 000000000000..86d80d2d8742 --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-3.10.0-no-ipv6.patch @@ -0,0 +1,41 @@ +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 new file mode 100644 index 000000000000..fcfee292994b --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-3.6.0-pkg-config.patch @@ -0,0 +1,67 @@ +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 new file mode 100644 index 000000000000..17bb6ac856b3 --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-3.7.0-clang.patch @@ -0,0 +1,72 @@ +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 new file mode 100644 index 000000000000..947714adf832 --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-3.7.0-man7.patch @@ -0,0 +1,55 @@ +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 new file mode 100644 index 000000000000..96280e042453 --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-3.8.0-old-mount-libc.patch @@ -0,0 +1,38 @@ +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 new file mode 100644 index 000000000000..6c6c9a5c4308 --- /dev/null +++ b/sys-apps/iproute2/files/iproute2-4.0.0-tc-show-buffer-overflow.patch @@ -0,0 +1,62 @@ +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 + |