Re: sbin/pfctl: use TAILQ_CONCAT(3)
Hello, On Mon, Jan 27, 2020 at 08:54:19PM +0100, Björn Ketelaars wrote: > Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3). > > Comments/OK? looks good to me. OK sashan@
Re: Teach du(1) the -m flag, disk usage in megabytes
Florian Obser(flor...@openbsd.org) on 2020.01.27 19:57:41 +0100: > On Mon, Jan 27, 2020 at 10:33:49AM -0700, Todd C. Miller wrote: > > On Mon, 27 Jan 2020 10:05:41 +1100, Jonathan Gray wrote: > > > > > On Sun, Jan 26, 2020 at 11:59:33AM -0500, David Goerger wrote: > > > > This diff teaches du(1) the -m flag, report disk usage in megabytes. > > > > This brings us in line with implementations in the other BSDs, Linux, > > > > and Illumos. > > > > > > Why is it needed? -k is required by POSIX, adding arguments for > > > megabytes, gigabytes, terabytes, petabytes etc seems silly when > > > there is already 512 byte blocks, kilobytes and -h output. > > > > It is useful in conjunction with sort. For example, I often do: > > > > du -sk * | sort -rn | head > > > > to see the largest disk users. > > Me, too. Given its wide spread adoption I think we should implement it. > OK florian@ > > > > > However, output in kilobytes is less useful than it used to be due > > to larger files now being common. Using the BLOCKSIZE env var is > > more flexible but is cumbersome to use and not portable. > > > > - todd Every time my laptop disk gets full i use a horrible awk construct to make things readable. I would certainly like to see this. Do we need -B for that? I dont think so... I'm happy to commit this if nobody complains ;)
usr.sbin/snmpd: use TAILQ_CONCAT(3)
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git usr.sbin/snmpd/control.c usr.sbin/snmpd/control.c
index 54b58bbb7b6..dda18c1bad5 100644
--- usr.sbin/snmpd/control.c
+++ usr.sbin/snmpd/control.c
@@ -487,10 +487,7 @@ control_dispatch_agentx(int fd, short event, void *arg)
TAILQ_INSERT_TAIL(, miboid, o_list);
} while (++oid.bo_id[rhdr.subrange] <= ubound);
- while ((miboid = TAILQ_FIRST()) != NULL) {
- TAILQ_REMOVE(, miboid, o_list);
- TAILQ_INSERT_TAIL(>oids, miboid, o_list);
- }
+ TAILQ_CONCAT(>oids, , o_list);
dodone:
break;
}
usr.sbin/ldapd: use TAILQ_CONCAT(3)
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git usr.sbin/ldapd/search.c usr.sbin/ldapd/search.c
index 3033823eb18..887af5fb6a1 100644
--- usr.sbin/ldapd/search.c
+++ usr.sbin/ldapd/search.c
@@ -764,11 +764,8 @@ search_planner(struct namespace *ns, struct ber_element
*filter)
/* Select an index to use. */
TAILQ_FOREACH(arg, >args, next) {
if (arg->indexed) {
- while ((indx = TAILQ_FIRST(>indices))) {
- TAILQ_REMOVE(>indices, indx, next);
- TAILQ_INSERT_TAIL(>indices, indx,
- next);
- }
+ TAILQ_CONCAT(>indices, >indices,
+ next);
plan->indexed = arg->indexed;
break;
}
@@ -796,11 +793,9 @@ search_planner(struct namespace *ns, struct ber_element
*filter)
plan->indexed = 0;
break;
}
- while ((indx = TAILQ_FIRST(>indices))) {
- TAILQ_REMOVE(>indices, indx, next);
- TAILQ_INSERT_TAIL(>indices, indx,next);
+ TAILQ_FOREACH(indx, >indices, next)
plan->indexed++;
- }
+ TAILQ_CONCAT(>indices, >indices, next);
}
break;
case LDAP_FILT_NOT:
usr.sbin/bgpd: use TAILQ_CONCAT(3)
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git usr.sbin/bgpd/config.c usr.sbin/bgpd/config.c
index cb43afb81fe..fc81a3efd3b 100644
--- usr.sbin/bgpd/config.c
+++ usr.sbin/bgpd/config.c
@@ -195,7 +195,6 @@ void
merge_config(struct bgpd_config *xconf, struct bgpd_config *conf)
{
struct listen_addr *nla, *ola, *next;
- struct network *n;
struct peer *p, *np, *nextp;
/*
@@ -250,10 +249,7 @@ merge_config(struct bgpd_config *xconf, struct bgpd_config
*conf)
/* switch the network statements, but first remove the old ones */
free_networks(>networks);
- while ((n = TAILQ_FIRST(>networks)) != NULL) {
- TAILQ_REMOVE(>networks, n, entry);
- TAILQ_INSERT_TAIL(>networks, n, entry);
- }
+ TAILQ_CONCAT(>networks, >networks, entry);
/* switch the l3vpn configs, first remove the old ones */
free_l3vpns(>l3vpns);
Re: Teach du(1) the -m flag, disk usage in megabytes
On Mon, 27 Jan 2020 10:05:41 +1100, Jonathan Gray wrote: > On Sun, Jan 26, 2020 at 11:59:33AM -0500, David Goerger wrote: > > This diff teaches du(1) the -m flag, report disk usage in megabytes. > > This brings us in line with implementations in the other BSDs, Linux, > > and Illumos. > > Why is it needed? -k is required by POSIX, adding arguments for > megabytes, gigabytes, terabytes, petabytes etc seems silly when > there is already 512 byte blocks, kilobytes and -h output. It is useful in conjunction with sort. For example, I often do: du -sk * | sort -rn | head to see the largest disk users. However, output in kilobytes is less useful than it used to be due to larger files now being common. Using the BLOCKSIZE env var is more flexible but is cumbersome to use and not portable. - todd
Re: sys/ufs/ffs/ffs_softdep.c: use TAILQ_CONCAT(3)
On Mon, 27 Jan 2020 20:01:24 +0100, =?utf-8?B?QmrDtnJu?= Ketelaars wrote: > I build a kernel using the diff below and gave it a spin. So far it > didn't blow up. > > I was wondering if it makes sense to address these custom concatenations > and provide diffs, or is this considered nitpicking? I think these changes are useful as TAILQ_CONCAT doesn't require a loop like the hand-rolled versions do so it is O(1) instead of O(N). - todd
sbin/unwind: use TAILQ_CONCAT(3)
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git sbin/unwind/frontend.c sbin/unwind/frontend.c
index b64036c4332..d2b69084db7 100644
--- sbin/unwind/frontend.c
+++ sbin/unwind/frontend.c
@@ -1011,10 +1011,7 @@ merge_tas(struct trust_anchor_head *newh, struct
trust_anchor_head *oldh)
if (chg) {
free_tas(oldh);
- while((i = TAILQ_FIRST(newh)) != NULL) {
- TAILQ_REMOVE(newh, i, entry);
- TAILQ_INSERT_TAIL(oldh, i, entry);
- }
+ TAILQ_CONCAT(oldh, newh, entry);
} else {
free_tas(newh);
}
diff --git sbin/unwind/resolver.c sbin/unwind/resolver.c
index 15d2c90b1e8..c12bdbdab26 100644
--- sbin/unwind/resolver.c
+++ sbin/unwind/resolver.c
@@ -1650,10 +1650,7 @@ replace_forwarders(struct uw_forwarder_head *new_list,
struct
free(uw_forwarder);
}
- while ((uw_forwarder = TAILQ_FIRST(new_list)) != NULL) {
- TAILQ_REMOVE(new_list, uw_forwarder, entry);
- TAILQ_INSERT_TAIL(old_list, uw_forwarder, entry);
- }
+ TAILQ_CONCAT(old_list, new_list, entry);
}
int
Re: sbin/pfctl: use TAILQ_CONCAT(3)
On Mon, Jan 27, 2020 at 08:54:19PM +0100, Björn Ketelaars wrote: > Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3). OK kn
sys/ufs/ffs/ffs_softdep.c: use TAILQ_CONCAT(3)
cheloha@ recently replaced custom TAILQ concatenation loops in pool(9)
with TAILQ_CONCAT(3) [0]. I was curious as how often these custom
concatenations loops are used and grepped src. I found a couple of them.
One being in sys/ufs/ffs/ffs_softdep.c, and the others in userland.
I build a kernel using the diff below and gave it a spin. So far it
didn't blow up.
I was wondering if it makes sense to address these custom concatenations
and provide diffs, or is this considered nitpicking?
[0]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/subr_pool.c.diff?r1=1.229=1.230
diff --git sys/ufs/ffs/ffs_softdep.c sys/ufs/ffs/ffs_softdep.c
index 2f2a2edc224..d0fd3a15278 100644
--- sys/ufs/ffs/ffs_softdep.c
+++ sys/ufs/ffs/ffs_softdep.c
@@ -4486,10 +4486,7 @@ merge_inode_lists(struct inodedep *inodedep)
}
newadp = TAILQ_FIRST(>id_newinoupdt);
}
- while ((newadp = TAILQ_FIRST(>id_newinoupdt)) != NULL) {
- TAILQ_REMOVE(>id_newinoupdt, newadp, ad_next);
- TAILQ_INSERT_TAIL(>id_inoupdt, newadp, ad_next);
- }
+ TAILQ_CONCAT(>id_inoupdt, >id_newinoupdt, ad_next);
}
/*
sbin/pfctl: use TAILQ_CONCAT(3)
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git sbin/pfctl/parse.y sbin/pfctl/parse.y
index d524f9e92bc..67de79215e4 100644
--- sbin/pfctl/parse.y
+++ sbin/pfctl/parse.y
@@ -5637,16 +5637,11 @@ mv_rules(struct pf_ruleset *src, struct pf_ruleset *dst)
{
struct pf_rule *r;
- while ((r = TAILQ_FIRST(src->rules.active.ptr)) != NULL) {
- TAILQ_REMOVE(src->rules.active.ptr, r, entries);
- TAILQ_INSERT_TAIL(dst->rules.active.ptr, r, entries);
+ TAILQ_FOREACH(r, src->rules.active.ptr, entries)
dst->anchor->match++;
- }
+ TAILQ_CONCAT(dst->rules.active.ptr, src->rules.active.ptr, entries);
src->anchor->match = 0;
- while ((r = TAILQ_FIRST(src->rules.inactive.ptr)) != NULL) {
- TAILQ_REMOVE(src->rules.inactive.ptr, r, entries);
- TAILQ_INSERT_TAIL(dst->rules.inactive.ptr, r, entries);
- }
+ TAILQ_CONCAT(dst->rules.inactive.ptr, src->rules.inactive.ptr, entries);
}
void
diff --git sbin/pfctl/pfctl_optimize.c sbin/pfctl/pfctl_optimize.c
index 3526dcce962..fe74c435980 100644
--- sbin/pfctl/pfctl_optimize.c
+++ sbin/pfctl/pfctl_optimize.c
@@ -687,11 +687,7 @@ reorder_rules(struct pfctl *pf, struct superblock *block,
int depth)
* it based on a more optimal skipstep order.
*/
TAILQ_INIT();
- while ((por = TAILQ_FIRST(>sb_rules))) {
- TAILQ_REMOVE(>sb_rules, por, por_entry);
- TAILQ_INSERT_TAIL(, por, por_entry);
- }
-
+ TAILQ_CONCAT(, >sb_rules, por_entry);
while (!TAILQ_EMPTY()) {
largest = 1;
@@ -712,11 +708,7 @@ reorder_rules(struct pfctl *pf, struct superblock *block,
int depth)
* Nothing useful left. Leave remaining rules in order.
*/
DEBUG("(%d) no more commonality for skip steps", depth);
- while ((por = TAILQ_FIRST())) {
- TAILQ_REMOVE(, por, por_entry);
- TAILQ_INSERT_TAIL(>sb_rules, por,
- por_entry);
- }
+ TAILQ_CONCAT(>sb_rules, , por_entry);
} else {
/*
* There is commonality. Extract those common rules
@@ -830,10 +822,7 @@ block_feedback(struct pfctl *pf, struct superblock *block)
*/
TAILQ_INIT();
- while ((por1 = TAILQ_FIRST(>sb_rules)) != NULL) {
- TAILQ_REMOVE(>sb_rules, por1, por_entry);
- TAILQ_INSERT_TAIL(, por1, por_entry);
- }
+ TAILQ_CONCAT(, >sb_rules, por_entry);
while ((por1 = TAILQ_FIRST()) != NULL) {
TAILQ_REMOVE(, por1, por_entry);
ospf6d: rework rde_lsdb.c
3 changes in rde_lsdb.c
- lsa_find_lsid() has redondant parameters
- call to lsa_self() can be simplified (== ospfd)
- update debug messages to be more suitable
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/rde.c,v
retrieving revision 1.83
diff -u -p -r1.83 rde.c
--- rde.c 21 Jan 2020 15:17:12 - 1.83
+++ rde.c 27 Jan 2020 17:11:52 -
@@ -455,17 +455,10 @@ rde_dispatch_imsg(int fd, short event, v
rde_req_list_del(nbr, >hdr);
- self = lsa_self(lsa);
- if (self) {
- if (v == NULL)
- /* LSA is no longer announced,
-* remove by premature aging. */
- lsa_flush(nbr, lsa);
- else
- lsa_reflood(v, lsa);
- } else if (lsa_add(nbr, lsa))
- /* delayed lsa, don't flood yet */
- break;
+ if (!(self = lsa_self(nbr, lsa, v)))
+ if (lsa_add(nbr, lsa))
+ /* delayed lsa */
+ break;
/* flood and perhaps ack LSA */
imsg_compose_event(iev_ospfe, IMSG_LS_FLOOD,
@@ -1683,8 +1676,7 @@ orig_asext_lsa(struct kroute *kr, u_int1
memcpy((char *)lsa + sizeof(struct lsa_hdr) + sizeof(struct lsa_asext),
>prefix, LSA_PREFIXSIZE(kr->prefixlen));
- lsa->hdr.ls_id = lsa_find_lsid(_tree, lsa->hdr.type,
- lsa->hdr.adv_rtr, comp_asext, lsa);
+ lsa->hdr.ls_id = lsa_find_lsid(_tree, comp_asext, lsa);
if (age == MAX_AGE) {
/* inherit metric and ext_tag from the current LSA,
Index: rde.h
===
RCS file: /cvs/src/usr.sbin/ospf6d/rde.h,v
retrieving revision 1.24
diff -u -p -r1.24 rde.h
--- rde.h 21 Jan 2020 15:17:12 - 1.24
+++ rde.h 27 Jan 2020 17:11:52 -
@@ -145,9 +145,7 @@ void vertex_nexthop_add(struct vertex
const struct in6_addr *, u_int32_t);
int lsa_newer(struct lsa_hdr *, struct lsa_hdr *);
int lsa_check(struct rde_nbr *, struct lsa *, u_int16_t);
-int lsa_self(struct lsa *);
-voidlsa_flush(struct rde_nbr *, struct lsa *);
-voidlsa_reflood(struct vertex *, struct lsa*);
+int lsa_self(struct rde_nbr *, struct lsa *, struct vertex *);
int lsa_add(struct rde_nbr *, struct lsa *);
voidlsa_del(struct rde_nbr *, struct lsa_hdr *);
voidlsa_age(struct vertex *);
@@ -156,7 +154,7 @@ struct vertex *lsa_find_rtr(struct area
struct vertex *lsa_find_rtr_frag(struct area *, u_int32_t, unsigned int);
struct vertex *lsa_find_tree(struct lsa_tree *, u_int16_t, u_int32_t,
u_int32_t);
-u_int32_t lsa_find_lsid(struct lsa_tree *, u_int16_t, u_int32_t,
+u_int32_t lsa_find_lsid(struct lsa_tree *,
int (*)(struct lsa *, struct lsa *), struct lsa *);
u_int16_t lsa_num_links(struct vertex *);
voidlsa_snap(struct rde_nbr *);
Index: rde_lsdb.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/rde_lsdb.c,v
retrieving revision 1.42
diff -u -p -r1.42 rde_lsdb.c
--- rde_lsdb.c 21 Jan 2020 15:17:13 - 1.42
+++ rde_lsdb.c 27 Jan 2020 17:11:52 -
@@ -192,7 +192,7 @@ lsa_check(struct rde_nbr *nbr, struct ls
return (0);
}
if (ntohs(lsa->hdr.len) != len) {
- log_warnx("lsa_check: bad packet size");
+ log_warnx("lsa_check: bad packet length");
return (0);
}
@@ -244,7 +244,7 @@ lsa_check(struct rde_nbr *nbr, struct ls
}
metric = ntohl(lsa->data.pref_sum.metric);
if (metric & ~LSA_METRIC_MASK) {
- log_warnx("lsa_check: bad LSA summary metric");
+ log_warnx("lsa_check: bad LSA prefix summary metric");
return (0);
}
if (lsa_get_prefix(((char *)lsa) + sizeof(lsa->hdr) +
@@ -263,7 +263,7 @@ lsa_check(struct rde_nbr *nbr, struct ls
}
metric = ntohl(lsa->data.rtr_sum.metric);
if (metric & ~LSA_METRIC_MASK) {
- log_warnx("lsa_check: bad LSA summary metric");
+ log_warnx("lsa_check: bad LSA router summary metric");
return (0);
Re: Teach du(1) the -m flag, disk usage in megabytes
On Mon, Jan 27, 2020 at 10:33:49AM -0700, Todd C. Miller wrote: > On Mon, 27 Jan 2020 10:05:41 +1100, Jonathan Gray wrote: > > > On Sun, Jan 26, 2020 at 11:59:33AM -0500, David Goerger wrote: > > > This diff teaches du(1) the -m flag, report disk usage in megabytes. > > > This brings us in line with implementations in the other BSDs, Linux, > > > and Illumos. > > > > Why is it needed? -k is required by POSIX, adding arguments for > > megabytes, gigabytes, terabytes, petabytes etc seems silly when > > there is already 512 byte blocks, kilobytes and -h output. > > It is useful in conjunction with sort. For example, I often do: > > du -sk * | sort -rn | head > > to see the largest disk users. Me, too. Given its wide spread adoption I think we should implement it. OK florian@ > > However, output in kilobytes is less useful than it used to be due > to larger files now being common. Using the BLOCKSIZE env var is > more flexible but is cumbersome to use and not portable. > > - todd > -- I'm not entirely sure you are real.
ipsec flow type changes, use->require
On 2019/11/29 iked and isakmpd were changed from installing "USE" flows for inbound IPsec to "REQUIRE" flows, so that unencrypted packets are rejected. Normally this is good but I ran into a corner case. I have a tunnel from my workstation to private subnets behind a remote router. That remote router also has some rdr-to from one of its public IPs to machines in the subnet: flow esp in from 10.71.0.0/18 to $myworkstation peer $whatever type require flow esp out from $myworkstation to 10.71.0.0/18 peer $whatever type require pass in quick on egress proto tcp to $EXTERNAL_IP port smtp rdr-to 10.71.12.5 ($EXTERNAL_IP is a normal internet-routable IP, not one of the private ones in 10.71/18. $myworkstation is also a normal internet-routable IP, not natted). If I try to connect from $myworkstation to $EXTERNAL_IP this obviously isn't covered by the flow on my workstation so is sent in cleartext. But, because flows match *translated* addresses, it *is* covered by the flow on the remote router and so now that this is a 'require' flow it gets dropped. This at least needs documenting in current.html/upgrade67.html so that people aren't caught by surprise (it took me several days to figure out as I'd forgotten about this commit!) but this would be better if we can show a workaround for people affected by the change. I tried adding a 'type use' flow with ipsecctl but this failed with "writev failed: Invalid argument" (same if I removed the existing 'type require' flow first) - not sure if there's another way to do this. Workarounds on $myworkstation side (split horizon DNS, natting $myworkstation's non-tunnel traffic to $EXTERNAL_IP to another IP) are possible I suppose, but not very appealing. Does anyone have other ideas? (I've just got the commit backed-out for now but that's not good long-term or for users..)
Re: Teach du(1) the -m flag, disk usage in megabytes
On Mon, Jan 27, 2020 at 10:34:56PM +0100, Sebastian Benoit wrote: > Florian Obser(flor...@openbsd.org) on 2020.01.27 19:57:41 +0100: > > On Mon, Jan 27, 2020 at 10:33:49AM -0700, Todd C. Miller wrote: > > > On Mon, 27 Jan 2020 10:05:41 +1100, Jonathan Gray wrote: > > > > > > > On Sun, Jan 26, 2020 at 11:59:33AM -0500, David Goerger wrote: > > > > > This diff teaches du(1) the -m flag, report disk usage in megabytes. > > > > > This brings us in line with implementations in the other BSDs, Linux, > > > > > and Illumos. > > > > > > > > Why is it needed? -k is required by POSIX, adding arguments for > > > > megabytes, gigabytes, terabytes, petabytes etc seems silly when > > > > there is already 512 byte blocks, kilobytes and -h output. > > > > > > It is useful in conjunction with sort. For example, I often do: > > > > > > du -sk * | sort -rn | head > > > > > > to see the largest disk users. > > > > Me, too. Given its wide spread adoption I think we should implement it. > > OK florian@ > > > > > > > > However, output in kilobytes is less useful than it used to be due > > > to larger files now being common. Using the BLOCKSIZE env var is > > > more flexible but is cumbersome to use and not portable. > > > > > > - todd > > Every time my laptop disk gets full i use a horrible awk construct > to make things readable. I would certainly like to see this. > > Do we need -B for that? I dont think so... > > I'm happy to commit this if nobody complains ;) There are several commands which have a -k flag for scaling to kilobytes. For example: df du ls pstat quot swapctl Going down the list of unit names kmgtpezy some of these flags are already used. So it would be hard to consistently use -m where -k is used. Adding a flag to take a scalling factor, even if just using an additional char like 'm' to index into a table of scaling factors would use less flags. Though not all of these combinations and uses make sense, and commands could be left inconsistent and not use additional scaling factors other commands use.
Re: usr.sbin/snmpd: use TAILQ_CONCAT(3)
Bj??rn Ketelaars(bjorn.ketela...@hydroxide.nl) on 2020.01.27 20:53:52 +0100:
> Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
>
> Comments/OK?
reads ok benno@
> diff --git usr.sbin/snmpd/control.c usr.sbin/snmpd/control.c
> index 54b58bbb7b6..dda18c1bad5 100644
> --- usr.sbin/snmpd/control.c
> +++ usr.sbin/snmpd/control.c
> @@ -487,10 +487,7 @@ control_dispatch_agentx(int fd, short event, void *arg)
> TAILQ_INSERT_TAIL(, miboid, o_list);
> } while (++oid.bo_id[rhdr.subrange] <= ubound);
>
> - while ((miboid = TAILQ_FIRST()) != NULL) {
> - TAILQ_REMOVE(, miboid, o_list);
> - TAILQ_INSERT_TAIL(>oids, miboid, o_list);
> - }
> + TAILQ_CONCAT(>oids, , o_list);
> dodone:
> break;
> }
>
Re: Teach du(1) the -m flag, disk usage in megabytes
On Tue, 28 Jan 2020 15:00:39 +1100, Jonathan Gray wrote: > There are several commands which have a -k flag for scaling to > kilobytes. > > For example: > df > du > ls > pstat > quot > swapctl > > Going down the list of unit names kmgtpezy some of these flags are > already used. So it would be hard to consistently use -m where -k is > used. Adding a flag to take a scalling factor, even if just using an > additional char like 'm' to index into a table of scaling factors would > use less flags. That's a fair point. It's not really reasonable to use a separate option letter for every possible scaling factor. The Linux du -B option seems close to what we want, though it also appends a unit for things like "du -Bm" which breaks sorting (though du -B1m works). - todd
Re: sbin/unwind: use TAILQ_CONCAT(3)
Bj??rn Ketelaars(bjorn.ketela...@hydroxide.nl) on 2020.01.27 20:52:36 +0100:
> Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
>
> Comments/OK?
reads ok benno@
> diff --git sbin/unwind/frontend.c sbin/unwind/frontend.c
> index b64036c4332..d2b69084db7 100644
> --- sbin/unwind/frontend.c
> +++ sbin/unwind/frontend.c
> @@ -1011,10 +1011,7 @@ merge_tas(struct trust_anchor_head *newh, struct
> trust_anchor_head *oldh)
>
> if (chg) {
> free_tas(oldh);
> - while((i = TAILQ_FIRST(newh)) != NULL) {
> - TAILQ_REMOVE(newh, i, entry);
> - TAILQ_INSERT_TAIL(oldh, i, entry);
> - }
> + TAILQ_CONCAT(oldh, newh, entry);
> } else {
> free_tas(newh);
> }
> diff --git sbin/unwind/resolver.c sbin/unwind/resolver.c
> index 15d2c90b1e8..c12bdbdab26 100644
> --- sbin/unwind/resolver.c
> +++ sbin/unwind/resolver.c
> @@ -1650,10 +1650,7 @@ replace_forwarders(struct uw_forwarder_head *new_list,
> struct
> free(uw_forwarder);
> }
>
> - while ((uw_forwarder = TAILQ_FIRST(new_list)) != NULL) {
> - TAILQ_REMOVE(new_list, uw_forwarder, entry);
> - TAILQ_INSERT_TAIL(old_list, uw_forwarder, entry);
> - }
> + TAILQ_CONCAT(old_list, new_list, entry);
> }
>
> int
>
Re: usr.sbin/bgpd: use TAILQ_CONCAT(3)
Bj??rn Ketelaars(bjorn.ketela...@hydroxide.nl) on 2020.01.27 20:53:06 +0100:
> Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
>
> Comments/OK?
ok benno@
> diff --git usr.sbin/bgpd/config.c usr.sbin/bgpd/config.c
> index cb43afb81fe..fc81a3efd3b 100644
> --- usr.sbin/bgpd/config.c
> +++ usr.sbin/bgpd/config.c
> @@ -195,7 +195,6 @@ void
> merge_config(struct bgpd_config *xconf, struct bgpd_config *conf)
> {
> struct listen_addr *nla, *ola, *next;
> - struct network *n;
> struct peer *p, *np, *nextp;
>
> /*
> @@ -250,10 +249,7 @@ merge_config(struct bgpd_config *xconf, struct
> bgpd_config *conf)
>
> /* switch the network statements, but first remove the old ones */
> free_networks(>networks);
> - while ((n = TAILQ_FIRST(>networks)) != NULL) {
> - TAILQ_REMOVE(>networks, n, entry);
> - TAILQ_INSERT_TAIL(>networks, n, entry);
> - }
> + TAILQ_CONCAT(>networks, >networks, entry);
>
> /* switch the l3vpn configs, first remove the old ones */
> free_l3vpns(>l3vpns);
>
Re: Teach du(1) the -m flag, disk usage in megabytes
On Mon, 27 Jan 2020 10:33:49 -0700, Todd C. Miller wrote: > For example, I often do: > > du -sk * | sort -rn | head > > to see the largest disk users. > > However, output in kilobytes is less useful than it used to be due > to larger files now being common. Can't you achieve what you want with `du -sh * | sort -h`? du(1)'s -h options will automatically select the best suffix and sort(1)'s -h will sort first using the suffix then the numerical value. Also if you don't sort -r, you don't need to `| head`. Cheers, Daniel
