Re: replacing timeout_add() with timeout_add_msec()
On Sun, Jan 06, 2019 at 01:43:19PM -0600, Amit Kulkarni wrote:
> Hi,
>
> Referring to the end of mpi's message, and also mlarkin@ later comment
> https://marc.info/?l=openbsd-tech&m=154577028830964&w=2
>
> I am trying to replace some easy timeout_add() calls with timeout_add_msec().
>
> My current understanding with the occurences of timeout_add() in the tree is
> that: if there is a hardcoded call like timeout_add(struct timeout, 1), then
> replace with timeout_add_msec(struct timeout, 10). That is, 1 tick = 10 msec.
>
> So if there's a hardcoded call like timeout_add(struct timeout, 5), then
> replace with timeout_add_msec(struct timeout, 50).
>
> If there are hz calculations which I don't understand like for example in
> /sys/arch/alpha/tc/ioasic.c, then I am skipping these for now.
> if (alpha_led_blink != 0) {
> timeout_set(&led_blink_state.tmo, ioasic_led_blink, NULL);
> timeout_add(&led_blink_state.tmo,
> (((averunnable.ldavg[0] + FSCALE) * hz) >> (FSHIFT + 3)));
> }
>
> A call like timeout_add(struct timeout, 0) is replaced by an equivalent call
> to timeout_add_msec(struct timeout, 0).
>
> Both the above scenarios are in the following diff and un-tested (not
> compiled also, for now), no way I can test some of these, as I don't have
> access to hardware. Mainly looking for critical review and feedback to get
> this going in the right direction.
>
> Thanks for your time!
You started to convert the wrong timeout_add() calls. Doing a blind
timeout_add() to timeout_add_msec() conversion especially on calls with 0
or 1 tick sleep time is the wrong approach.
The right approach is to identify calls that do sleep for a well defined time
(1sec, 50ms or whatever) and convert those. Most of the timeouts you
changes are not in that category. First I would look at timeouts that have
a multiplication with hz in them since those wait for a specific time.
> diff --git arch/alpha/alpha/promcons.c arch/alpha/alpha/promcons.c
> index 9efabd3bf1c..b872f6e3931 100644
> --- arch/alpha/alpha/promcons.c
> +++ arch/alpha/alpha/promcons.c
> @@ -100,7 +100,7 @@ promopen(dev, flag, mode, p)
> error = (*linesw[tp->t_line].l_open)(dev, tp, p);
> if (error == 0 && setuptimeout) {
> timeout_set(&prom_to, promtimeout, tp);
> - timeout_add(&prom_to, 1);
> + timeout_add_msec(&prom_to, 10);
> }
> return error;
> }
> @@ -220,7 +220,7 @@ promtimeout(v)
> if (tp->t_state & TS_ISOPEN)
> (*linesw[tp->t_line].l_rint)(c, tp);
> }
> - timeout_add(&prom_to, 1);
> + timeout_add_msec(&prom_to, 10);
> }
>
> struct tty *
> diff --git arch/amd64/isa/clock.c arch/amd64/isa/clock.c
> index db516d9ecde..9d5934e6817 100644
> --- arch/amd64/isa/clock.c
> +++ arch/amd64/isa/clock.c
> @@ -326,7 +326,7 @@ rtcstart(void)
> mc146818_write(NULL, MC_REGB, MC_REGB_24HR | MC_REGB_PIE);
>
> /*
> - * On a number of i386 systems, the rtc will fail to start when booting
> + * On a number of amd64 systems, the rtc will fail to start when booting
>* the system. This is due to us missing to acknowledge an interrupt
>* during early stages of the boot process. If we do not acknowledge
>* the interrupt, the rtc clock will not generate further interrupts.
> @@ -334,7 +334,7 @@ rtcstart(void)
>* to drain any un-acknowledged rtc interrupt(s).
>*/
> timeout_set(&rtcdrain_timeout, rtcdrain, (void *)&rtcdrain_timeout);
> - timeout_add(&rtcdrain_timeout, 1);
> + timeout_add_msec(&rtcdrain_timeout, 10);
> }
>
> void
> diff --git arch/amd64/pci/pchb.c arch/amd64/pci/pchb.c
> index 6e599d7be4a..80b5ada1cb4 100644
> --- arch/amd64/pci/pchb.c
> +++ arch/amd64/pci/pchb.c
> @@ -332,7 +332,7 @@ pchb_rnd(void *v)
> }
> }
>
> - timeout_add(&sc->sc_rng_to, 1);
> + timeout_add(&sc->sc_rng_to, 10);
> }
>
> void
> diff --git dev/ic/vga.c dev/ic/vga.c
> index 74cc3e07bf8..2cebb65d2d5 100644
> --- dev/ic/vga.c
> +++ dev/ic/vga.c
> @@ -765,7 +765,7 @@ vga_show_screen(void *v, void *cookie, int waitok, void
> (*cb)(void *, int, int),
> if (cb) {
> timeout_set(&vc->vc_switch_timeout,
> (void(*)(void *))vga_doswitch, vc);
> - timeout_add(&vc->vc_switch_timeout, 0);
> + timeout_add(&vc->vc_switch_timeout, 10);
> return (EAGAIN);
> }
>
> diff --git net/if_pfsync.c net/if_pfsync.c
> index 8d842e48466..dc8d2f41466 100644
> --- net/if_pfsync.c
> +++ net/if_pfsync.c
> @@ -2318,7 +2318,7 @@ pfsync_bulk_start(void)
> sc->sc_bulk_last = sc->sc_bulk_next;
>
> pfsync_bulk_status(PFSYNC_BUS_START);
> - timeout_add(&sc->sc_bulk_tmo, 0);
> + timeout_add_msec(&sc->sc_bulk_tmo, 0);
> }
> }
>
>
>
>
--
:wq Claudio
Re: replacing timeout_add() with timeout_add_msec()
> > Even on amd64, I won't be able to test, because of missing hardware. > > If you think something is wrong, please will you let me have your > > feedback? > > I'm a bit stunned at the zeal to push untested diffs into the tree > > (you didn't ask anyone to test it for you) I requested for critical review or feedback in the initial email, to know if I am going down the right path. If the approach is ok, then I was planning to sit down to try converting all the straightforward of timeout_add() to timeout_add_msec() calls in the tree, then a review again, before finally requesting a test run. Requesting a test, when I am unsure of the approach in code, would lead to low or zero confidence from others when asked in future.
Re: replacing timeout_add() with timeout_add_msec()
Amit Kulkarni wrote: > Even on amd64, I won't be able to test, because of missing hardware. > If you think something is wrong, please will you let me have your > feedback? I'm a bit stunned at the zeal to push untested diffs into the tree (you didn't ask anyone to test it for you)
Re: replacing timeout_add() with timeout_add_msec()
Even on amd64, I won't be able to test, because of missing hardware.
If you think something is wrong, please will you let me have your
feedback?
Thanks
On Sun, Jan 6, 2019 at 4:56 PM Theo de Raadt wrote:
>
> Amit Kulkarni wrote:
>
> > Hi,
> >
> > Referring to the end of mpi's message, and also mlarkin@ later comment
> > https://marc.info/?l=openbsd-tech&m=154577028830964&w=2
> >
> > I am trying to replace some easy timeout_add() calls with
> > timeout_add_msec().
> >
> > My current understanding with the occurences of timeout_add() in the tree
> > is that: if there is a hardcoded call like timeout_add(struct timeout, 1),
> > then replace with timeout_add_msec(struct timeout, 10). That is, 1 tick =
> > 10 msec.
> >
> > So if there's a hardcoded call like timeout_add(struct timeout, 5), then
> > replace with timeout_add_msec(struct timeout, 50).
> >
> > If there are hz calculations which I don't understand like for example in
> > /sys/arch/alpha/tc/ioasic.c, then I am skipping these for now.
> > if (alpha_led_blink != 0) {
> > timeout_set(&led_blink_state.tmo, ioasic_led_blink, NULL);
> > timeout_add(&led_blink_state.tmo,
> > (((averunnable.ldavg[0] + FSCALE) * hz) >> (FSHIFT +
> > 3)));
> > }
> >
> > A call like timeout_add(struct timeout, 0) is replaced by an equivalent
> > call to timeout_add_msec(struct timeout, 0).
> >
> > Both the above scenarios are in the following diff and un-tested (not
> > compiled also, for now), no way I can test some of these, as I don't have
> > access to hardware. Mainly looking for critical review and feedback to get
> > this going in the right direction.
> >
> > Thanks for your time!
> >
> > diff --git arch/alpha/alpha/promcons.c arch/alpha/alpha/promcons.c
> > index 9efabd3bf1c..b872f6e3931 100644
> > --- arch/alpha/alpha/promcons.c
> > +++ arch/alpha/alpha/promcons.c
> > @@ -100,7 +100,7 @@ promopen(dev, flag, mode, p)
> > error = (*linesw[tp->t_line].l_open)(dev, tp, p);
> > if (error == 0 && setuptimeout) {
> > timeout_set(&prom_to, promtimeout, tp);
> > - timeout_add(&prom_to, 1);
> > + timeout_add_msec(&prom_to, 10);
> > }
> > return error;
> > }
> > @@ -220,7 +220,7 @@ promtimeout(v)
> > if (tp->t_state & TS_ISOPEN)
> > (*linesw[tp->t_line].l_rint)(c, tp);
> > }
> > - timeout_add(&prom_to, 1);
> > + timeout_add_msec(&prom_to, 10);
> > }
> >
> > struct tty *
>
> I am glad you have an alpha, and will be able to test your proposed change.
Re: vmd console freeze and locked (?) qcow2 image
On Sat, 5 Jan 2019 17:56:01 -0800 Mike Larkin wrote: > Did you kill all the old vmd processes? > > -ml > I tested again and it works now. There were restarts in between. I will try killing vmd processes if this happens again, thanks. Kind regards, Thomas
Re: relayd and TLS client cert verification
On 18 Dec 2018, at 11:34, Ashe Connor wrote: > Revised patch follows (includes mandoc changes). Last bump. Happy new year!
Re: pfctl: zap unused function parameter
Hello,
On Sat, Jan 05, 2019 at 10:10:07PM +0100, Klemens Nanni wrote:
> Never used, probably just copy/pasta since introduction in 2006.
>
> `-i' and other flags are completely ignored with `-K' anyway.
>
> OK?
>
OK sashan@
> Index: pfctl.c
> ===
> RCS file: /cvs/src/sbin/pfctl/pfctl.c,v
> retrieving revision 1.362
> diff -u -p -r1.362 pfctl.c
> --- pfctl.c 2 Jan 2019 23:08:00 - 1.362
> +++ pfctl.c 5 Jan 2019 20:55:11 -
> @@ -67,7 +67,7 @@ void pfctl_clear_rules(int, int, char *
> void pfctl_clear_src_nodes(int, int);
> void pfctl_clear_states(int, const char *, int);
> void pfctl_addrprefix(char *, struct pf_addr *);
> -void pfctl_kill_src_nodes(int, const char *, int);
> +void pfctl_kill_src_nodes(int, int);
> void pfctl_net_kill_states(int, const char *, int, int);
> void pfctl_label_kill_states(int, const char *, int, int);
> void pfctl_id_kill_states(int, int);
> @@ -405,7 +405,7 @@ pfctl_addrprefix(char *addr, struct pf_a
> }
>
> void
> -pfctl_kill_src_nodes(int dev, const char *iface, int opts)
> +pfctl_kill_src_nodes(int dev, int opts)
> {
> struct pfioc_src_node_kill psnk;
> struct addrinfo *res[2], *resp[2];
> @@ -2661,7 +2661,7 @@ main(int argc, char *argv[])
> }
>
> if (src_node_killers)
> - pfctl_kill_src_nodes(dev, ifaceopt, opts);
> + pfctl_kill_src_nodes(dev, opts);
>
> if (tblcmdopt != NULL) {
> error = pfctl_table(argc, argv, tableopt,
>
Re: pfctl: defuse `-F all -i ...'
Hello,
> mcbride introduced this code with r1.298 in 2010 but used
>
> if (*ifaceopt) {
>
> only to have stsp fix a segfault in r1.299 by changing it to the current
> form.
>
> One might as well assume that my proposed condition was the originally
> intended behaviour after all and stsp's fix should've just removed the
> derefence.
>
> OK?
OK sashan@
>
> Index: pfctl.c
> ===
> RCS file: /cvs/src/sbin/pfctl/pfctl.c,v
> retrieving revision 1.362
> diff -u -p -r1.362 pfctl.c
> --- pfctl.c 2 Jan 2019 23:08:00 - 1.362
> +++ pfctl.c 5 Jan 2019 22:01:56 -
> @@ -2626,13 +2626,13 @@ main(int argc, char *argv[])
> pfctl_clear_stats(dev, ifaceopt, opts);
> break;
> case 'a':
> - pfctl_clear_tables(anchorname, opts);
> - pfctl_clear_rules(dev, opts, anchorname);
> - if (ifaceopt && *ifaceopt) {
> + if (ifaceopt) {
> warnx("don't specify an interface with -Fall");
> usage();
> /* NOTREACHED */
> }
> + pfctl_clear_tables(anchorname, opts);
> + pfctl_clear_rules(dev, opts, anchorname);
> if (!*anchorname) {
> pfctl_clear_states(dev, ifaceopt, opts);
> pfctl_clear_src_nodes(dev, opts);
>
Re: pfctl: tables: improve namespace collision warnings
Hello, > > > As I've said I don't object your change. I agree it does, > > what you intend, however I'm not sure how much it buys. > My intention is to make warnings clear and unambiguous, such that > referred table and anchor names can be copied and pasted into successive > pfctl invocations to fix things right away. I agree the better warnings don't hurt. I'm OK with your changes. sashan
Re: replacing timeout_add() with timeout_add_msec()
Amit Kulkarni wrote:
> Hi,
>
> Referring to the end of mpi's message, and also mlarkin@ later comment
> https://marc.info/?l=openbsd-tech&m=154577028830964&w=2
>
> I am trying to replace some easy timeout_add() calls with timeout_add_msec().
>
> My current understanding with the occurences of timeout_add() in the tree is
> that: if there is a hardcoded call like timeout_add(struct timeout, 1), then
> replace with timeout_add_msec(struct timeout, 10). That is, 1 tick = 10 msec.
>
> So if there's a hardcoded call like timeout_add(struct timeout, 5), then
> replace with timeout_add_msec(struct timeout, 50).
>
> If there are hz calculations which I don't understand like for example in
> /sys/arch/alpha/tc/ioasic.c, then I am skipping these for now.
> if (alpha_led_blink != 0) {
> timeout_set(&led_blink_state.tmo, ioasic_led_blink, NULL);
> timeout_add(&led_blink_state.tmo,
> (((averunnable.ldavg[0] + FSCALE) * hz) >> (FSHIFT + 3)));
> }
>
> A call like timeout_add(struct timeout, 0) is replaced by an equivalent call
> to timeout_add_msec(struct timeout, 0).
>
> Both the above scenarios are in the following diff and un-tested (not
> compiled also, for now), no way I can test some of these, as I don't have
> access to hardware. Mainly looking for critical review and feedback to get
> this going in the right direction.
>
> Thanks for your time!
>
> diff --git arch/alpha/alpha/promcons.c arch/alpha/alpha/promcons.c
> index 9efabd3bf1c..b872f6e3931 100644
> --- arch/alpha/alpha/promcons.c
> +++ arch/alpha/alpha/promcons.c
> @@ -100,7 +100,7 @@ promopen(dev, flag, mode, p)
> error = (*linesw[tp->t_line].l_open)(dev, tp, p);
> if (error == 0 && setuptimeout) {
> timeout_set(&prom_to, promtimeout, tp);
> - timeout_add(&prom_to, 1);
> + timeout_add_msec(&prom_to, 10);
> }
> return error;
> }
> @@ -220,7 +220,7 @@ promtimeout(v)
> if (tp->t_state & TS_ISOPEN)
> (*linesw[tp->t_line].l_rint)(c, tp);
> }
> - timeout_add(&prom_to, 1);
> + timeout_add_msec(&prom_to, 10);
> }
>
> struct tty *
I am glad you have an alpha, and will be able to test your proposed change.
[patch] cwm: tile only within active monitor
Hi all,
I'm new around here, so apologies in advance if I miss something
obvious.
I have written a patch to cwm so that the htile/vtile functionality
only affect windows within the same monitor as the active window. For
single monitor setups, this will have no effect. For multi-monitor
setups, this will allow multiple different monitors to have windows
tiled independently from one another (within the same group).
This is implemented by modifying the relevant checks to ignore any
clients (ci) where the client is outside of the area of the current
display as returned by screen_area() (ci->geom not within area).
Testing and feedback are welcome and appreciated!
Regards,
~ Charles
P.S. I would be curious to heard about others' development workflows
for window managers. I've been compiling cwm, copying it to
/usr/X11R6/bin, logging out, and logging back in. This is really un-
ergonomic, and I'd like to have a better setup, but I've never
developed a window manager before so I'm unsure how to improve.
diff --git a/client.c.orig b/client.c
index 27658e6..05e18ab 100644
--- a/client.c.orig
+++ b/client.c
@@ -986,19 +986,23 @@ client_htile(struct client_ctx *cc)
return;
i = n = 0;
+ area = screen_area(sc,
+ cc->geom.x + cc->geom.w / 2,
+ cc->geom.y + cc->geom.h / 2, CWM_GAP);
+
TAILQ_FOREACH(ci, &gc->clientq, group_entry) {
if (ci->flags & CLIENT_HIDDEN ||
- ci->flags & CLIENT_IGNORE || (ci == cc))
+ ci->flags & CLIENT_IGNORE || (ci == cc) ||
+ ci->geom.x < area.x ||
+ ci->geom.x > (area.x + area.w) ||
+ ci->geom.y < area.y ||
+ ci->geom.y > (area.y + area.h))
continue;
n++;
}
if (n == 0)
return;
- area = screen_area(sc,
- cc->geom.x + cc->geom.w / 2,
- cc->geom.y + cc->geom.h / 2, CWM_GAP);
-
if (cc->flags & CLIENT_VMAXIMIZED ||
cc->geom.h + (cc->bwidth * 2) >= area.h)
return;
@@ -1017,7 +1021,11 @@ client_htile(struct client_ctx *cc)
h = area.h - mh;
TAILQ_FOREACH(ci, &gc->clientq, group_entry) {
if (ci->flags & CLIENT_HIDDEN ||
- ci->flags & CLIENT_IGNORE || (ci == cc))
+ ci->flags & CLIENT_IGNORE || (ci == cc) ||
+ ci->geom.x < area.x ||
+ ci->geom.x > (area.x + area.w) ||
+ ci->geom.y < area.y ||
+ ci->geom.y > (area.y + area.h))
continue;
ci->bwidth = Conf.bwidth;
ci->geom.x = x;
@@ -1044,21 +1052,26 @@ client_vtile(struct client_ctx *cc)
if (!gc)
return;
+
+ area = screen_area(sc,
+ cc->geom.x + cc->geom.w / 2,
+ cc->geom.y + cc->geom.h / 2, CWM_GAP);
+
i = n = 0;
TAILQ_FOREACH(ci, &gc->clientq, group_entry) {
if (ci->flags & CLIENT_HIDDEN ||
- ci->flags & CLIENT_IGNORE || (ci == cc))
+ ci->flags & CLIENT_IGNORE || (ci == cc) ||
+ ci->geom.x < area.x ||
+ ci->geom.x > (area.x + area.w) ||
+ ci->geom.y < area.y ||
+ ci->geom.y > (area.y + area.h))
continue;
n++;
}
if (n == 0)
return;
- area = screen_area(sc,
- cc->geom.x + cc->geom.w / 2,
- cc->geom.y + cc->geom.h / 2, CWM_GAP);
-
if (cc->flags & CLIENT_HMAXIMIZED ||
cc->geom.w + (cc->bwidth * 2) >= area.w)
return;
@@ -1077,7 +1090,11 @@ client_vtile(struct client_ctx *cc)
w = area.w - mw;
TAILQ_FOREACH(ci, &gc->clientq, group_entry) {
if (ci->flags & CLIENT_HIDDEN ||
- ci->flags & CLIENT_IGNORE || (ci == cc))
+ ci->flags & CLIENT_IGNORE || (ci == cc) ||
+ ci->geom.x < area.x ||
+ ci->geom.x > (area.x + area.w) ||
+ ci->geom.y < area.y ||
+ ci->geom.y > (area.y + area.h))
continue;
ci->bwidth = Conf.bwidth;
ci->geom.x = area.x + mw;
replacing timeout_add() with timeout_add_msec()
Hi,
Referring to the end of mpi's message, and also mlarkin@ later comment
https://marc.info/?l=openbsd-tech&m=154577028830964&w=2
I am trying to replace some easy timeout_add() calls with timeout_add_msec().
My current understanding with the occurences of timeout_add() in the tree is
that: if there is a hardcoded call like timeout_add(struct timeout, 1), then
replace with timeout_add_msec(struct timeout, 10). That is, 1 tick = 10 msec.
So if there's a hardcoded call like timeout_add(struct timeout, 5), then
replace with timeout_add_msec(struct timeout, 50).
If there are hz calculations which I don't understand like for example in
/sys/arch/alpha/tc/ioasic.c, then I am skipping these for now.
if (alpha_led_blink != 0) {
timeout_set(&led_blink_state.tmo, ioasic_led_blink, NULL);
timeout_add(&led_blink_state.tmo,
(((averunnable.ldavg[0] + FSCALE) * hz) >> (FSHIFT + 3)));
}
A call like timeout_add(struct timeout, 0) is replaced by an equivalent call to
timeout_add_msec(struct timeout, 0).
Both the above scenarios are in the following diff and un-tested (not compiled
also, for now), no way I can test some of these, as I don't have access to
hardware. Mainly looking for critical review and feedback to get this going in
the right direction.
Thanks for your time!
diff --git arch/alpha/alpha/promcons.c arch/alpha/alpha/promcons.c
index 9efabd3bf1c..b872f6e3931 100644
--- arch/alpha/alpha/promcons.c
+++ arch/alpha/alpha/promcons.c
@@ -100,7 +100,7 @@ promopen(dev, flag, mode, p)
error = (*linesw[tp->t_line].l_open)(dev, tp, p);
if (error == 0 && setuptimeout) {
timeout_set(&prom_to, promtimeout, tp);
- timeout_add(&prom_to, 1);
+ timeout_add_msec(&prom_to, 10);
}
return error;
}
@@ -220,7 +220,7 @@ promtimeout(v)
if (tp->t_state & TS_ISOPEN)
(*linesw[tp->t_line].l_rint)(c, tp);
}
- timeout_add(&prom_to, 1);
+ timeout_add_msec(&prom_to, 10);
}
struct tty *
diff --git arch/amd64/isa/clock.c arch/amd64/isa/clock.c
index db516d9ecde..9d5934e6817 100644
--- arch/amd64/isa/clock.c
+++ arch/amd64/isa/clock.c
@@ -326,7 +326,7 @@ rtcstart(void)
mc146818_write(NULL, MC_REGB, MC_REGB_24HR | MC_REGB_PIE);
/*
-* On a number of i386 systems, the rtc will fail to start when booting
+* On a number of amd64 systems, the rtc will fail to start when booting
* the system. This is due to us missing to acknowledge an interrupt
* during early stages of the boot process. If we do not acknowledge
* the interrupt, the rtc clock will not generate further interrupts.
@@ -334,7 +334,7 @@ rtcstart(void)
* to drain any un-acknowledged rtc interrupt(s).
*/
timeout_set(&rtcdrain_timeout, rtcdrain, (void *)&rtcdrain_timeout);
- timeout_add(&rtcdrain_timeout, 1);
+ timeout_add_msec(&rtcdrain_timeout, 10);
}
void
diff --git arch/amd64/pci/pchb.c arch/amd64/pci/pchb.c
index 6e599d7be4a..80b5ada1cb4 100644
--- arch/amd64/pci/pchb.c
+++ arch/amd64/pci/pchb.c
@@ -332,7 +332,7 @@ pchb_rnd(void *v)
}
}
- timeout_add(&sc->sc_rng_to, 1);
+ timeout_add(&sc->sc_rng_to, 10);
}
void
diff --git dev/ic/vga.c dev/ic/vga.c
index 74cc3e07bf8..2cebb65d2d5 100644
--- dev/ic/vga.c
+++ dev/ic/vga.c
@@ -765,7 +765,7 @@ vga_show_screen(void *v, void *cookie, int waitok, void
(*cb)(void *, int, int),
if (cb) {
timeout_set(&vc->vc_switch_timeout,
(void(*)(void *))vga_doswitch, vc);
- timeout_add(&vc->vc_switch_timeout, 0);
+ timeout_add(&vc->vc_switch_timeout, 10);
return (EAGAIN);
}
diff --git net/if_pfsync.c net/if_pfsync.c
index 8d842e48466..dc8d2f41466 100644
--- net/if_pfsync.c
+++ net/if_pfsync.c
@@ -2318,7 +2318,7 @@ pfsync_bulk_start(void)
sc->sc_bulk_last = sc->sc_bulk_next;
pfsync_bulk_status(PFSYNC_BUS_START);
- timeout_add(&sc->sc_bulk_tmo, 0);
+ timeout_add_msec(&sc->sc_bulk_tmo, 0);
}
}
Re: grep: convert fgetln to getline
Lauri Tirkkonen wrote: > Hi, another simple diff converting fgetln usage to getline. > > I also considered converting grep_fgetln to grep_getline, but that would > mean that for FILE_MMAP we'd have to copy the string. So this diff keeps > the grep_fgetln interface as is, but avoids using fgetln from libc (and > adds error handling for FILE_STDIO). this looks good and seems to work. thanks.
Re: sbin/wsconsctl: show more data
Thank you Frederic for the new console font. I agree with Mischa and Paul and find it very clean and readable, a definite improvement. -- Robert W. Curry
Re: adjust rdate example
Ingo Schwarze wrote: > Hm, you have a point. > > I guess i got confused by my experience with LC_CTYPE; even though > that is also a standard variable, its effects on different programs > vary wildly, so the text for LC_CTYPE reads very differently in > different utility manual pages, and it is often relevant which > aspects are supported and which are not. I think the ENVIRONMENT section should only describe non-default divergent behaviour, and environ(7) covers the default behaviour. > So the full explanation is probably best placed > located in environ(7). Utilities where it is unusually important, > like date(1), might benefit from a short pointer below ENVIRONMENT, > though, to help beginners, like it exists in ls(1). I disagree on ls(1). Please explain why you think this is the place to point people at environ(7). It is a strongly known part of Unix, meaning the moment people become aware of any aspect of Unix timezone handling, they immediately understand it applies to all utilities and seeing a note burried in the bottom of ls(1) isn't going to help them. >$ man -M /usr/share/man -k Ev=TZ > date(1) - display or set date and time date is fine, TZ documentation should stay due to -l and -j being weird. > ssh(1) - OpenSSH SSH client (remote login program) this talks about how TZ is replicated, so it should stay. > mail.local(8) - store mail in a mailbox I concur, this one should stay. > tzset, tzsetwall(3) - initialize time conversion information > environ(7) - user environment those should stay. > ls(1) - list directory contents > ps(1) - display process status But I think it should TZ documentation should be deleted from ls(1) and ps(1)
Re: sbin/wsconsctl: show more data
I have to concur with Paul!
Saw the new font yesterday and was pleasantly surprised. Very nice!
Mischa
--
> On 6 Jan 2019, at 15:51, Paul de Weerd wrote:
>
> Lots of negativity here, so I just wanted to chime in - really love
> the new console font! Crisp and easily readable letters, big enough
> to be readable, with a reasonable number of letters per line
> (${COLUMNS}) en lines per screen (${LINES}). It does mean pretty big
> characters on big screens when in console mode, but on big screens I
> want to run X anyway, so it's all good. What I understand of the
> algorithm to pick the font size makes a lot of sense to me.
>
> Thank you Frederic for all the effort you put into this font and
> making it happen on the console and in X through the fonts/spleen
> port!
>
> Cheers,
>
> Paul 'WEiRD' de Weerd
>
> --
>> [<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
>
Re: sbin/wsconsctl: show more data
Lots of negativity here, so I just wanted to chime in - really love
the new console font! Crisp and easily readable letters, big enough
to be readable, with a reasonable number of letters per line
(${COLUMNS}) en lines per screen (${LINES}). It does mean pretty big
characters on big screens when in console mode, but on big screens I
want to run X anyway, so it's all good. What I understand of the
algorithm to pick the font size makes a lot of sense to me.
Thank you Frederic for all the effort you put into this font and
making it happen on the console and in X through the fonts/spleen
port!
Cheers,
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
grep: convert fgetln to getline
Hi, another simple diff converting fgetln usage to getline.
I also considered converting grep_fgetln to grep_getline, but that would
mean that for FILE_MMAP we'd have to copy the string. So this diff keeps
the grep_fgetln interface as is, but avoids using fgetln from libc (and
adds error handling for FILE_STDIO).
diff --git a/usr.bin/grep/file.c b/usr.bin/grep/file.c
index 4b3c689e4ab..87c49dd5cc0 100644
--- a/usr.bin/grep/file.c
+++ b/usr.bin/grep/file.c
@@ -34,10 +34,8 @@
#include "grep.h"
static char fname[PATH_MAX];
-#ifndef NOZ
static char*lnbuf;
-static size_t lnbuflen;
-#endif
+static size_t lnbufsize;
#define FILE_STDIO 0
#define FILE_MMAP 1
@@ -73,9 +71,9 @@ gzfgetln(gzFile *f, size_t *len)
else
errx(2, "%s: %s", fname, gzerrstr);
}
- if (n >= lnbuflen) {
- lnbuflen *= 2;
- lnbuf = grep_realloc(lnbuf, ++lnbuflen);
+ if (n >= lnbufsize) {
+ lnbufsize *= 2;
+ lnbuf = grep_realloc(lnbuf, ++lnbufsize);
}
if (c == '\n')
break;
@@ -182,7 +180,13 @@ grep_fgetln(file_t *f, size_t *l)
{
switch (f->type) {
case FILE_STDIO:
- return fgetln(f->f, l);
+ if ((*l = getline(&lnbuf, &lnbufsize, f->f)) == -1) {
+ if (ferror(f->f))
+ err(2, "%s: getline", fname);
+ else
+ return NULL;
+ }
+ return lnbuf;
#ifndef SMALL
case FILE_MMAP:
return mmfgetln(f->mmf, l);
diff --git a/usr.bin/grep/grep.c b/usr.bin/grep/grep.c
index 913cc97a0f3..cfac24b12aa 100644
--- a/usr.bin/grep/grep.c
+++ b/usr.bin/grep/grep.c
@@ -224,15 +224,19 @@ read_patterns(const char *fn)
{
FILE *f;
char *line;
- size_t len;
+ ssize_t len;
+ size_t linesize;
if ((f = fopen(fn, "r")) == NULL)
err(2, "%s", fn);
- while ((line = fgetln(f, &len)) != NULL)
+ line = NULL;
+ linesize = 0;
+ while ((len = getline(&line, &linesize, f)) != -1)
add_pattern(line, *line == '\n' ? 0 : len);
if (ferror(f))
err(2, "%s", fn);
fclose(f);
+ free(line);
}
int
--
Lauri Tirkkonen | lotheac @ IRCnet
ehci(4): interrupt transfer fix
Hello,
RL (NAK count reload) field in QH should be zero when using periodic
(interrupt) transfer.
Currently it is always set 8, but this causes high-speed interrupt transfer
malfunction in my machines, Hudson-D2 chipset(amd64) and Allwinner A10(armv7).
This causes USB2.0 hub cannot detect device attach/detach.
Here is a remedy, Linux sets the value 4 when asynchronous transfer so
I copied it.
Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.200
diff -u -p -r1.200 ehci.c
--- ehci.c 15 May 2017 10:52:08 - 1.200
+++ ehci.c 6 Jan 2019 06:08:37 -
@@ -1406,7 +1406,12 @@ ehci_open(struct usbd_pipe *pipe)
panic("ehci_open: bad device speed %d", dev->speed);
}
- naks = 8; /* XXX */
+ /*
+* NAK reload count:
+* must be zero with using periodic transfer.
+* Linux 4.20's driver (ehci-q.c) sets 4, we use same value.
+*/
+ naks = ((xfertype == UE_CONTROL) || (xfertype == UE_BULK)) ? 4 : 0;
/* Allocate sqh for everything, save isoc xfers */
if (xfertype != UE_ISOCHRONOUS) {
--
SASANO Takayoshi (JG1UAA)
