Re: -current packages that need rebuilding from recent ABI break

[Daniel Wilkins]

> Stuart Henderson said:
> > Are you sure it's errno related and not something else (e.g. lack of
> > following http://www.openbsd.org/faq/current.html#r20160527 ("2016/05/27
> > - fstab needs wxallowed flag on /usr/local")?

It may have been. I just went through a fresh install (had some nastiness 
happen)
and now mpv is running fine. I am having an issue with packages linking against
old major versions of Xenocara libs, but that should be taken care of in the
next rebuild of packages anyway.

make nd6_llinfo_settimer use seconds, not ticks

[David Gwynne]

internally, nd6 llinfo keeps track of seconds, and the majority of
the callers work in seconds.

the exception is the nd_ifinfo retrans stuff which is msec, not
seconds.

i believe there is a bug fix in here too relating to the use of
nd_defrouter.expire handling in nd6_free. from what i can tell,
nd_defrouter.expire measures seconds, and is compared against
time_seconds. ticks and hz shouldnt be mixed into the comparisons
of it.

ok?

Index: nd6.c
===
RCS file: /cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.180
diff -u -p -r1.180 nd6.c
--- nd6.c   30 May 2016 23:37:37 -  1.180
+++ nd6.c   31 May 2016 01:48:39 -
@@ -304,18 +304,18 @@ skip1:
  * ND6 timer routine to handle ND6 entries
  */
 void
-nd6_llinfo_settimer(struct llinfo_nd6 *ln, long tick)
+nd6_llinfo_settimer(struct llinfo_nd6 *ln, int secs)
 {
int s;
 
s = splsoftnet();
 
-   if (tick < 0) {
+   if (secs < 0) {
ln->ln_expire = 0;
timeout_del(>ln_timer_ch);
} else {
-   ln->ln_expire = time_second + tick / hz;
-   timeout_add(>ln_timer_ch, tick);
+   ln->ln_expire = time_second + secs;
+   timeout_add_sec(>ln_timer_ch, secs);
}
 
splx(s);
@@ -355,7 +355,7 @@ nd6_llinfo_timer(void *arg)
case ND6_LLINFO_INCOMPLETE:
if (ln->ln_asked < nd6_mmaxtries) {
ln->ln_asked++;
-   nd6_llinfo_settimer(ln, (long)ndi->retrans * hz / 1000);
+   nd6_llinfo_settimer(ln, ndi->retrans / 1000);
nd6_ns_output(ifp, NULL, >sin6_addr, ln, 0);
} else {
struct mbuf *m = ln->ln_hold;
@@ -385,7 +385,7 @@ nd6_llinfo_timer(void *arg)
case ND6_LLINFO_REACHABLE:
if (!ND6_LLINFO_PERMANENT(ln)) {
ln->ln_state = ND6_LLINFO_STALE;
-   nd6_llinfo_settimer(ln, (long)nd6_gctimer * hz);
+   nd6_llinfo_settimer(ln, nd6_gctimer);
}
break;
 
@@ -403,18 +403,18 @@ nd6_llinfo_timer(void *arg)
/* We need NUD */
ln->ln_asked = 1;
ln->ln_state = ND6_LLINFO_PROBE;
-   nd6_llinfo_settimer(ln, (long)ndi->retrans * hz / 1000);
+   nd6_llinfo_settimer(ln, ndi->retrans / 1000);
nd6_ns_output(ifp, >sin6_addr,
>sin6_addr, ln, 0);
} else {
ln->ln_state = ND6_LLINFO_STALE; /* XXX */
-   nd6_llinfo_settimer(ln, (long)nd6_gctimer * hz);
+   nd6_llinfo_settimer(ln, nd6_gctimer);
}
break;
case ND6_LLINFO_PROBE:
if (ln->ln_asked < nd6_umaxtries) {
ln->ln_asked++;
-   nd6_llinfo_settimer(ln, (long)ndi->retrans * hz / 1000);
+   nd6_llinfo_settimer(ln, ndi->retrans / 1000);
nd6_ns_output(ifp, >sin6_addr,
>sin6_addr, ln, 0);
} else {
@@ -751,11 +751,11 @@ nd6_free(struct rtentry *rt, int gc)
 * XXX: the check for ln_state would be redundant,
 *  but we intentionally keep it just in case.
 */
-   if (dr->expire > time_second * hz) {
+   if (dr->expire > time_second) {
nd6_llinfo_settimer(ln,
-   dr->expire - time_second * hz);
+   dr->expire - time_second);
} else
-   nd6_llinfo_settimer(ln, (long)nd6_gctimer * hz);
+   nd6_llinfo_settimer(ln, nd6_gctimer);
splx(s);
if_put(ifp);
return (TAILQ_NEXT(ln, ln_list));
@@ -860,7 +860,7 @@ nd6_nud_hint(struct rtentry *rt)
 
ln->ln_state = ND6_LLINFO_REACHABLE;
if (!ND6_LLINFO_PERMANENT(ln))
-   nd6_llinfo_settimer(ln, (long)ND_IFINFO(ifp)->reachable * hz);
+   nd6_llinfo_settimer(ln, ND_IFINFO(ifp)->reachable);
 out:
if_put(ifp);
 }
@@ -1350,7 +1350,7 @@ fail:
 * we must set the timer now, although it is actually
 * meaningless.
 */
-   nd6_llinfo_settimer(ln, (long)nd6_gctimer * hz);
+   nd6_llinfo_settimer(ln, nd6_gctimer);
 
if (ln->ln_hold) {
struct mbuf *n = ln->ln_hold;
@@ -1568,7 +1568,7 @@ nd6_output(struct ifnet *ifp, struct mbu
if (ln->ln_state == ND6_LLINFO_STALE) {
   

small glitch in pfctl_show_rules()

[Alexandr Nedvedicky]

Hello,

Petr Hoffmann discovered glitch in 'pfctl -a "*" -sr' command when it is
recursively dumping rulesets from PF kernel module. The ruleset in kernel
got created by screw-it.sh shell script:

#!/bin/sh

pfctl -d
echo 'anchor "../bar/*"\nanchor "bar/*"' |pfctl -a foo -f -
echo pass | pfctl -f - -a foo/bar
echo 'anchor "foo"\nanchor "bar" ' | pfctl -f -

Now if we use 'pfctl -a "*" -sr' we get output as follows:

# pfctl -a "*" -sr
anchor "foo" all {
  anchor "../bar/*" all {
pfctl: DIOCGETRULES: Invalid argument
  }
  anchor "bar/*" all {
pass all flags S/SA
  }
}
anchor "bar" all {
}

The problem comes from pfctl_show_rules(), which is going to descend
to "../bar/" anchor at line 845:

 828 case PFCTL_SHOW_RULES:
 829 if (pr.rule.label[0] && (opts & PF_OPT_SHOWALL))
 830 labels = 1;
 839 if (pr.anchor_call[0] &&
 ...
 840 (((p = strrchr(pr.anchor_call, '/')) ?
 841 p[1] == '_' : pr.anchor_call[0] == '_') ||
 842 opts & PF_OPT_RECURSE)) {
 843 printf(" {\n");
 844 pfctl_print_rule_counters(, opts);
 845 pfctl_show_rules(dev, npath, opts, format,
 846 pr.anchor_call, depth + 1,
 847 pr.rule.anchor_wildcard, -1);
 848 INDENT(depth, !(opts & PF_OPT_VERBOSE));
 849 printf("}\n");

The simplest fix here is not to allow pfctl_show_rules() to descend
to anchor specified by relative path.

patched pfctl gives output as follows:

# ./pfctl -a "*" -sr 
anchor "foo" all {
  anchor "../bar/*" all
  anchor "bar/*" all {
pass all flags S/SA
  }
}
anchor "bar" all {
}

OK?

thanks a lot
regards
sasha

8<---8<---8<--8<
diff -r d0c6296079db src/sbin/pfctl/pfctl.c
--- a/src/sbin/pfctl/pfctl.cMon May 30 20:12:24 2016 +0200
+++ b/src/sbin/pfctl/pfctl.cMon May 30 20:41:11 2016 +0200
@@ -835,11 +835,14 @@
 * If this is an 'unnamed' brace notation anchor OR
 * the user has explicitly requested recursion,
 * print it recursively.
+*
+* Note: we don't descend to relative anchors.
 */
if (pr.anchor_call[0] &&
(((p = strrchr(pr.anchor_call, '/')) ?
p[1] == '_' : pr.anchor_call[0] == '_') ||
-   opts & PF_OPT_RECURSE)) {
+   ((opts & PF_OPT_RECURSE) &&
+   (strncmp(pr.anchor_call, "../", 3) != 0 {
printf(" {\n");
pfctl_print_rule_counters(, opts);
pfctl_show_rules(dev, npath, opts, format,

bgpd: filter as path with operators

[Sebastian Benoit]

Hi,

this allows to have

  allow from any AS 64512 - 65534 ...
  allow from any AS > 100

etc in bgpd.conf.

Ignore the example file for now, i will commit that seperatly anyway.

One obvious improvment would be to be able to use this in bgpctl to restrict
the output of "show rib" a bit more. However, that is for another commit i
think, the bgpctl bit in this diff is just to make it compile and work.

ok?

/Benno

diff --git etc/examples/bgpd.conf etc/examples/bgpd.conf
index 8ffa8a8..02a31f9 100644
--- etc/examples/bgpd.conf
+++ etc/examples/bgpd.conf
@@ -119,3 +119,14 @@ deny from any prefix fc00::/7 prefixlen >= 7   
# unique local unicast
 deny from any prefix fe80::/10 prefixlen >= 10 # link local unicast
 deny from any prefix fec0::/10 prefixlen >= 10 # old site local unicast
 deny from any prefix ff00::/8 prefixlen >= 8   # multicast
+
+# filter bogon AS numbers
+# http://www.iana.org/assignments/as-numbers/as-numbers.xhtml
+deny from any AS 23456 # AS_TRANS
+deny from any AS 64496 - 64511 # Reserved for use in docs and 
code RFC5398
+deny from any AS 64512 - 65534 # Reserved for Private Use 
RFC6996
+deny from any AS 65535 # Reserved RFC7300
+deny from any AS 65536 - 65551 # Reserved for use in docs and 
code RFC5398 
+deny from any AS 65552 - 131071# Reserved
+deny from any AS 42 - 4294967294   # Reserved for Private Use 
RFC6996
+deny from any AS 4294967295# Reserved RFC7300
diff --git usr.sbin/bgpctl/bgpctl.c usr.sbin/bgpctl/bgpctl.c
index 62569bf..afdcf2c 100644
--- usr.sbin/bgpctl/bgpctl.c
+++ usr.sbin/bgpctl/bgpctl.c
@@ -1788,7 +1788,7 @@ show_mrt_dump(struct mrt_rib *mr, struct mrt_peer *mp, 
void *arg)
/* filter by AS */
if (req->as.type != AS_NONE &&
   !aspath_match(mre->aspath, mre->aspath_len,
-  req->as.type, req->as.as))
+  >as, req->as.as))
continue;
 
if (req->flags & F_CTL_DETAIL) {
@@ -1853,7 +1853,7 @@ network_mrt_dump(struct mrt_rib *mr, struct mrt_peer *mp, 
void *arg)
/* filter by AS */
if (req->as.type != AS_NONE &&
   !aspath_match(mre->aspath, mre->aspath_len,
-  req->as.type, req->as.as))
+  >as, req->as.as))
continue;
 
bzero(, sizeof(net));
diff --git usr.sbin/bgpd/bgpd.conf.5 usr.sbin/bgpd/bgpd.conf.5
index 84a01ed..0017124 100644
--- usr.sbin/bgpd/bgpd.conf.5
+++ usr.sbin/bgpd/bgpd.conf.5
@@ -1027,7 +1027,10 @@ If a parameter is specified, the rule only applies to 
packets with
 matching attributes.
 .Pp
 .Bl -tag -width Ds -compact
-.It Ar as-type as-number
+.It Xo
+.Ar as-type Op Ar operator
+.Ar as-number
+.Xc
 This rule applies only to
 .Em UPDATES
 where the
@@ -1038,13 +1041,7 @@ The
 is matched against a part of the
 .Em AS path
 specified by the
-.Ar as-type .
-.Ar as-number
-may be set to
-.Ic neighbor-as ,
-which is expanded to the current neighbor remote AS number.
-.Ar as-type
-is one of the following operators:
+.Ar as-type :
 .Pp
 .Bl -tag -width transmit-as -compact
 .It Ic AS
@@ -1057,6 +1054,33 @@ is one of the following operators:
 (all but the rightmost AS number)
 .El
 .Pp
+.Ar as-number
+is an AS number as explained above under
+.Sx GLOBAL CONFIGURATION .
+It may be set to
+.Ic neighbor-as ,
+which is expanded to the current neighbor remote AS number.
+.Pp
+The
+.Ar operator
+can be unspecified (this case is identical to the equality operator), or one 
of the numerical operators
+.Bd -literal -offset indent
+=  (equal)
+!= (unequal)
+<  (less than)
+<= (less than or equal)
+>  (greater than)
+>= (greater than or equal)
+-  (range including boundaries)
+>< (except range)
+.Ed
+.Pp
+>< and -
+are binary operators (they take two arguments), with these,
+.Ar as-number
+cannot be set to
+.Ic neighbor-as .
+.Pp
 Multiple
 .Ar as-number
 entries for a given type or
diff --git usr.sbin/bgpd/bgpd.h usr.sbin/bgpd/bgpd.h
index 86dfee9..9c635a8 100644
--- usr.sbin/bgpd/bgpd.h
+++ usr.sbin/bgpd/bgpd.h
@@ -625,6 +625,9 @@ struct filter_as {
u_int32_t   as;
u_int16_t   flags;
enum as_spectype;
+   u_int8_top;
+   u_int32_t   as_min;
+   u_int32_t   as_max;
 };
 
 struct filter_aslen {
@@ -660,7 +663,6 @@ struct filter_extcommunity {
}   data;
 };
 
-
 struct ctl_show_rib_request {
charrib[PEER_DESCR_LEN];
struct ctl_neighbor neighbor;
@@ -1051,7 +1053,8 @@ const char*log_ext_subtype(u_int8_t);
 int aspath_snprint(char *, size_t, void *, u_int16_t);
 int aspath_asprint(char **, void *, u_int16_t);
 size_t  aspath_strlen(void *, u_int16_t);
-int   

Re: video(1) mmap support

[Marcus Glocker]

On Mon, May 30, 2016 at 09:34:32PM +0200, Theo Buehler wrote:

> The same tests went fine with these changes.  Diff reads ok to me, it's
> really easy to follow what is happening.
> 
> Very minor comments inline.

Thanks for your comments.  I agree to all :-)  Attached new diff.


Index: video.1
===
RCS file: /cvs/xenocara/app/video/video.1,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 video.1
--- video.1 30 Nov 2014 01:40:26 -  1.11
+++ video.1 30 May 2016 20:11:16 -
@@ -25,7 +25,7 @@
 .Sh SYNOPSIS
 .Nm
 .Bk -words
-.Op Fl \
+.Op Fl \
 .Op Fl a Ar adaptor
 .Op Fl e Ar encoding
 .Op Fl f Ar file
@@ -101,6 +101,11 @@ will be used by default.
 device from which frames will be read.
 The default is
 .Pa /dev/video .
+.It Fl g
+Use
+.Xr read 2
+method to grab frames instead of
+.Xr mmap 2 .
 .It Fl i Ar input
 File from which frames will be read.
 If
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 video.c
--- video.c 23 Oct 2014 07:36:06 -  1.12
+++ video.c 30 May 2016 20:11:17 -
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -145,6 +146,9 @@ struct encodings {
 struct video {
struct xdsp  xdsp;
struct dev   dev;
+#define MMAP_NUM_BUFS  4
+   uint8_t  mmap_on;
+   void*mmap_buffer[MMAP_NUM_BUFS];
uint8_t *frame_buffer;
size_t   frame_bufsz;
uint8_t *conv_buffer;
@@ -189,8 +193,11 @@ void dev_reset_ctrls(struct video *);
 int parse_size(struct video *);
 int choose_size(struct video *);
 int choose_enc(struct video *);
+int mmap_init(struct video *);
+int mmap_stop(struct video *);
 int setup(struct video *);
 void cleanup(struct video *, int);
+int ioctl_input(struct video *);
 int poll_input(struct video *);
 int grab_frame(struct video *);
 int stream(struct video *);
@@ -206,7 +213,7 @@ extern char *__progname;
 void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-Rv] "
+   fprintf(stderr, "usage: %s [-gRv] "
"[-a adaptor] [-e encoding] [-f file] [-i input] [-O output]\n"
"   %*s [-o output] [-r rate] [-s size]\n", __progname,
(int)strlen(__progname), "");
@@ -668,10 +675,14 @@ dev_check_caps(struct video *vid)
warnx("%s is not a capture device", d->path);
return 0;
}
-   if (!(cap.capabilities & V4L2_CAP_READWRITE)) {
+   if (!(cap.capabilities & V4L2_CAP_READWRITE) && !vid->mmap_on) {
warnx("%s does not support read(2)", d->path);
return 0;
}
+   if (!(cap.capabilities & V4L2_CAP_STREAMING) && vid->mmap_on) {
+   warnx("%s does not support mmap(2)", d->path);
+   return 0;
+   }
d->buf_type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 
return 1;
@@ -972,6 +983,9 @@ dev_dump_info(struct video *vid)
struct dev *d = >dev;
int i, j;
 
+   if (!vid->mmap_on)
+   fprintf(stderr, "Using read instead of mmap to grab frames\n");
+
fprintf(stderr, "video device %s:\n", d->path);
 
fprintf(stderr, "  encodings: ");
@@ -1231,6 +1245,85 @@ choose_enc(struct video *vid)
 }
 
 int
+mmap_init(struct video *vid)
+{
+   struct v4l2_requestbuffers rb;
+   struct v4l2_buffer buf;
+   int i, r, type;
+
+   /* request buffers */
+   rb.count = MMAP_NUM_BUFS;
+   r = ioctl(vid->dev.fd, VIDIOC_REQBUFS, );
+   if (r == -1) {
+   warn("ioctl VIDIOC_REQBUFS");
+   return 0;
+   }
+
+   /* mmap the buffers */
+   for (i = 0; i < MMAP_NUM_BUFS; i++) {
+   buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory = V4L2_MEMORY_MMAP;
+   buf.index = i;
+   r = ioctl(vid->dev.fd, VIDIOC_QUERYBUF, );
+   if (r == -1) {
+   warn("ioctl VIDIOC_QUERYBUF");
+   return 0;
+   }
+   vid->mmap_buffer[i] = mmap(0, buf.length, PROT_READ,
+   MAP_SHARED, vid->dev.fd, buf.m.offset);
+   if (vid->mmap_buffer[i] == NULL) {
+   warn("mmap");
+   return 0;
+   }
+   }
+
+   /* initial buffer queueing */
+   for (i = 0; i < MMAP_NUM_BUFS; i++) {
+   buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory = V4L2_MEMORY_MMAP;
+   buf.index = i;
+   r = ioctl(vid->dev.fd, VIDIOC_QBUF, );
+   if (r == -1) {
+   warn("ioctl VIDIOC_QBUF");
+   return 0;
+   }
+   }
+
+   /* start video stream */
+   r = ioctl(vid->dev.fd, VIDIOC_STREAMON, );
+   if (r == -1) {
+  

Re: nd6 timers vs ticks

[Sebastian Benoit]

David Gwynne(da...@gwynne.id.au) on 2016.05.30 17:16:24 +1000:
> llinfo_nd6 thinks its expiry may extend beyond a timeout interval.
> 
> so it keeps track of the number of ticks it really wants via ln_ntick
> in llinfo_nd6 and schedules multiple timeouts to reach it.
> 
> i think this is a waste of time for two reasons:
> 
> 1. nd6_llinfo_settimer() (which sets this up) doesnt seem to be
> called with a timeout greater than what timeouts can handle. timeouts
> off the wire are ignored if theyre greater than an hour
> (MAX_REACHABLE_TIME), and the largest constant that ends up being
> passed is a day via nd6_gctimer. the fastest ticking arch we have
> is alpha with HZ at 1024, which wraps at about 24 days. we have
> space.
> 
> 2. ln_ntick is a long, which is the same size as int on 32 bit
> archs. the semantics it wants dont exist on a bunch of platforms.
> it is kind of arguing its own uselesness.
> 
> ok?

sounds reasonable. 
ok benno

> 
> Index: nd6.c
> ===
> RCS file: /cvs/src/sys/netinet6/nd6.c,v
> retrieving revision 1.179
> diff -u -p -r1.179 nd6.c
> --- nd6.c 17 May 2016 08:29:14 -  1.179
> +++ nd6.c 30 May 2016 07:08:09 -
> @@ -308,21 +308,16 @@ nd6_llinfo_settimer(struct llinfo_nd6 *l
>  {
>   int s;
>  
> + KASSERT(tick <= INT_MAX);
> +
>   s = splsoftnet();
>  
>   if (tick < 0) {
>   ln->ln_expire = 0;
> - ln->ln_ntick = 0;
>   timeout_del(>ln_timer_ch);
>   } else {
>   ln->ln_expire = time_second + tick / hz;
> - if (tick > INT_MAX) {
> - ln->ln_ntick = tick - INT_MAX;
> - timeout_add(>ln_timer_ch, INT_MAX);
> - } else {
> - ln->ln_ntick = 0;
> - timeout_add(>ln_timer_ch, tick);
> - }
> + timeout_add(>ln_timer_ch, tick);
>   }
>  
>   splx(s);
> @@ -341,18 +336,6 @@ nd6_llinfo_timer(void *arg)
>   s = splsoftnet();
>  
>   ln = (struct llinfo_nd6 *)arg;
> -
> - if (ln->ln_ntick > 0) {
> - if (ln->ln_ntick > INT_MAX) {
> - ln->ln_ntick -= INT_MAX;
> - nd6_llinfo_settimer(ln, INT_MAX);
> - } else {
> - ln->ln_ntick = 0;
> - nd6_llinfo_settimer(ln, ln->ln_ntick);
> - }
> - splx(s);
> - return;
> - }
>  
>   if ((rt = ln->ln_rt) == NULL)
>   panic("ln->ln_rt == NULL");
> Index: nd6.h
> ===
> RCS file: /cvs/src/sys/netinet6/nd6.h,v
> retrieving revision 1.58
> diff -u -p -r1.58 nd6.h
> --- nd6.h 30 Mar 2016 10:13:14 -  1.58
> +++ nd6.h 30 May 2016 07:08:09 -
> @@ -150,7 +150,6 @@ structllinfo_nd6 {
>   short   ln_state;   /* reachability state */
>   short   ln_router;  /* 2^0: ND6 router bit */
>  
> - longln_ntick;
>   struct  timeout ln_timer_ch;
>  };
>  
> 

-- 

Re: -current packages that need rebuilding from recent ABI break

[Dmitrij D. Czarkoff]

Stuart Henderson said:
> Are you sure it's errno related and not something else (e.g. lack of
> following http://www.openbsd.org/faq/current.html#r20160527 ("2016/05/27
> - fstab needs wxallowed flag on /usr/local")?

Mpv doas not need "wxallow".

-- 
Dmitrij D. Czarkoff

Re: video(1) mmap support

[Theo Buehler]

On Mon, May 30, 2016 at 02:29:08PM +0200, Marcus Glocker wrote:
> On Mon, May 30, 2016 at 10:49:10AM +0200, Theo Buehler wrote:
> 
> > On Mon, May 30, 2016 at 10:02:23AM +0200, Marcus Glocker wrote:
> > > I was in the middle of testing a uvideo(4) mmap queue diff when I
> > > noticed that our video(1) tool doesn't support the mmap method to grab
> > > frames.  This diff adds it and also makes mmap the default method.
> > > 
> > > Some test reports with different uvideo(4) devices would be welcome.
> > > It would be good if you could switch between different resolutions and
> > > also regression test the read method.  E.g.:
> > > 
> > >   $ video
> > >   $ video -s 800x600
> > >   $ video -s 1600x1200
> > >   $ video -g
> > >   $ video -g -s 1024x768
> > >   ...
> > > 
> > > Thanks,
> > > Marcus
> > > 
> > 
> > A quick test of the built-in camera of my T420, shows no regression when
> > directly compared to output of video(1) without your patch.  I tested
> > each of the supported frame sizes and rates for about 10 seconds both
> > with and without -g.
> 
> Thanks for testing!  Attached an updated diff after more feedback from
> Patrick Keshishian; Fix frame buffer processing order to dequeue,
> process buffer, requeue to avoid a potential buffer overwriting by
> driver before we can copy away the buffer.  And added munmap(2) once done.
> 

The same tests went fine with these changes.  Diff reads ok to me, it's
really easy to follow what is happening.

Very minor comments inline.

> 
> Index: video.1
> ===
> RCS file: /cvs/xenocara/app/video/video.1,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 video.1
> --- video.1   30 Nov 2014 01:40:26 -  1.11
> +++ video.1   30 May 2016 12:24:06 -
> @@ -25,7 +25,7 @@
>  .Sh SYNOPSIS
>  .Nm
>  .Bk -words
> -.Op Fl \
> +.Op Fl \
>  .Op Fl a Ar adaptor
>  .Op Fl e Ar encoding
>  .Op Fl f Ar file
> @@ -101,6 +101,11 @@ will be used by default.
>  device from which frames will be read.
>  The default is
>  .Pa /dev/video .
> +.It Fl g
> +Use
> +.Xr read 2
> +method to grab frames instead of
> +.Xr mmap 2 .
>  .It Fl i Ar input
>  File from which frames will be read.
>  If
> Index: video.c
> ===
> RCS file: /cvs/xenocara/app/video/video.c,v
> retrieving revision 1.12
> diff -u -p -u -p -r1.12 video.c
> --- video.c   23 Oct 2014 07:36:06 -  1.12
> +++ video.c   30 May 2016 12:24:06 -
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -145,6 +146,9 @@ struct encodings {
>  struct video {
>   struct xdsp  xdsp;
>   struct dev   dev;
> +#define MMAP_NUM_BUFS4
> + uint8_t  mmap_on;
> + void*mmap_buffer[MMAP_NUM_BUFS];
>   uint8_t *frame_buffer;
>   size_t   frame_bufsz;
>   uint8_t *conv_buffer;
> @@ -189,8 +193,11 @@ void dev_reset_ctrls(struct video *);
>  int parse_size(struct video *);
>  int choose_size(struct video *);
>  int choose_enc(struct video *);
> +int mmap_init(struct video *);
> +int mmap_stop(struct video *);
>  int setup(struct video *);
>  void cleanup(struct video *, int);
> +int ioctl_input(struct video *);
>  int poll_input(struct video *);
>  int grab_frame(struct video *);
>  int stream(struct video *);
> @@ -206,7 +213,7 @@ extern char *__progname;
>  void
>  usage(void)
>  {
> - fprintf(stderr, "usage: %s [-Rv] "
> + fprintf(stderr, "usage: %s [-gRv] "
>   "[-a adaptor] [-e encoding] [-f file] [-i input] [-O output]\n"
>   "   %*s [-o output] [-r rate] [-s size]\n", __progname,
>   (int)strlen(__progname), "");
> @@ -668,10 +675,14 @@ dev_check_caps(struct video *vid)
>   warnx("%s is not a capture device", d->path);
>   return 0;
>   }
> - if (!(cap.capabilities & V4L2_CAP_READWRITE)) {
> + if (!(cap.capabilities & V4L2_CAP_READWRITE) && !vid->mmap_on) {
>   warnx("%s does not support read(2)", d->path);
>   return 0;
>   }
> + if (!(cap.capabilities & V4L2_CAP_STREAMING) && vid->mmap_on) {
> + warnx("%s does not support mmap(2)");

This should be:
warnx("%s does not support read(2)", d->path);

> + return 0;
> + }
>   d->buf_type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>  
>   return 1;
> @@ -1231,6 +1242,85 @@ choose_enc(struct video *vid)
>  }
>  
>  int
> +mmap_init(struct video *vid)
> +{
> + struct v4l2_requestbuffers rb;
> + struct v4l2_buffer buf;
> + int i, r, type;
> +
> + /* request buffers */
> + rb.count = MMAP_NUM_BUFS;
> + r = ioctl(vid->dev.fd, VIDIOC_REQBUFS, );
> + if (r == -1) {
> + warn("ioctl VIDIOC_REQBUFS");
> + return 0;
> + }
> +
> + /* mmap the buffers */
> + for (i = 0; i < MMAP_NUM_BUFS; i++) {
> + buf.type 

Re: -current packages that need rebuilding from recent ABI break

[Stuart Henderson]

On 2016/05/30 14:38, Daniel Wilkins wrote:
> The mpv and libreoffice packages need to get rebuilt after the abi change;
> it seems like they were missed when most other things got updated, they're
> still giving the errno crash on startup.
> 

All packages get rebuilt every few days on amd64/i386, there have been
several builds done since then.

Are you sure it's errno related and not something else (e.g. lack of
following http://www.openbsd.org/faq/current.html#r20160527 ("2016/05/27
- fstab needs wxallowed flag on /usr/local")?

If a run of "pkg_add -u" doesn't update these packages for you, please
send more information (as a minimum, a copy of the output from pkg_add -u,
and which mirror you're using - either "installpath" from /etc/pkg.conf
or the contents of the PKG_PATH environment variable).

Re: pppoe(4) vlan priorities

[Mike Belopuhov]

On 30 May 2016 at 20:15, Stuart Henderson  wrote:
> On 2016/05/30 19:26, Daniel Gillen wrote:
>> Just tested your patch on my 5.9-stable amd64 gateway.
>>
>> Setting SPPP_CTL_PRIO to 1 and adding "match out on pppoe0 set prio 1"
>> to /etc/pf.conf solves my issues.
>
> Thanks for testing.
>
>> The only drawback is having to change the source and compiling a new
>> kernel. Would be nice if this could be configured in hostname.pppoe0 :)
>
> Agreed, but that would want to be a separate diff anyway (and I'd
> like to try and figure out how to do it without adding yet more cruft
> to ifconfig if possible..I'm wondering if it might be acceptable to
> appropriate vnetid for this).
>

I think it is appropriate.  dlg@ wanted to use it for the vlan tag in the
vlan driver itself.

Diff looks good to me, ok mikeb@

-current packages that need rebuilding from recent ABI break

[Daniel Wilkins]

The mpv and libreoffice packages need to get rebuilt after the abi change;
it seems like they were missed when most other things got updated, they're
still giving the errno crash on startup.

Re: pppoe(4) vlan priorities

[Stuart Henderson]

On 2016/05/30 19:26, Daniel Gillen wrote:
> Just tested your patch on my 5.9-stable amd64 gateway.
> 
> Setting SPPP_CTL_PRIO to 1 and adding "match out on pppoe0 set prio 1"
> to /etc/pf.conf solves my issues.

Thanks for testing.

> The only drawback is having to change the source and compiling a new
> kernel. Would be nice if this could be configured in hostname.pppoe0 :)

Agreed, but that would want to be a separate diff anyway (and I'd
like to try and figure out how to do it without adding yet more cruft
to ifconfig if possible..I'm wondering if it might be acceptable to
appropriate vnetid for this).

Re: pool related crashes, but "kernel did no panic"

[Ted Unangst]

Alexey Suslikov wrote:
> On Thu, May 12, 2016 at 4:14 PM, Bob Beck  wrote:
> > Thank you!now that's a bug report..
> 
> Hi.
> 
> Moved to 6.0-beta some time ago to make crash dumps more up
> to date. Also, removed some services to minimize their impact.
> 
> Fresh build against today's cvs don't survived even half of the day.
> 
> http://article.gmane.org/gmane.os.openbsd.bugs/23593
> 
> For me, it looks like: 5.7-5.8 - rare crashes, 5.9-6.0 - more frequent
> crashes.
> 
> Backtrace differs from crash to crash, but this remains the same:
> 
> Stopped at  pool_put+0x1dd: xorq0x8(%rax),%rcx
> 
> Do you have any idea where should I look in a source code?

sys/kern/subr_pool.c

Re: exp.3: remove ancient history and some markup tweaks

[Mark Kettenis]

> Date: Mon, 30 May 2016 19:33:04 +0200
> From: Theo Buehler 
> 
> > Sorry.  No.  The use of originally still implies that these functions
> > are no longer relevant for the purpose mentioned in the sentence.  It
> > doesn't make sense without the historic context.  I'd simply leave the
> > NOTES section as-is.
> 
> Fine. Here's the diff only doing the markup stuff.

Not an mdoc expert, but this looks good to me.

> Index: exp.3
> ===
> RCS file: /var/cvs/src/lib/libm/man/exp.3,v
> retrieving revision 1.33
> diff -u -p -r1.33 exp.3
> --- exp.3 26 Apr 2016 19:49:22 -  1.33
> +++ exp.3 30 May 2016 17:30:40 -
> @@ -139,7 +139,7 @@ function is an extended precision versio
>  .Pp
>  The
>  .Fn expm1
> -function computes the value exp(x)\-1 accurately even for tiny argument
> +function computes the value exp(x) \(mi 1 accurately even for tiny argument
>  .Fa x .
>  The
>  .Fn expm1f
> @@ -194,7 +194,7 @@ function is an extended precision versio
>  The
>  .Fn log1p
>  function computes
> -the value of log(1+x) accurately even for tiny argument
> +the value of log(1 + x) accurately even for tiny argument
>  .Fa x .
>  The
>  .Fn log1pf
> @@ -277,12 +277,12 @@ are accurate enough that
>  .Fn pow integer integer
>  is exact until it is bigger than 2**53 for IEEE 754.
>  .Sh NOTES
> -The functions exp(x)\-1 and log(1+x) are called
> +The functions exp(x) \(mi 1 and log(1 + x) are called
>  expm1 and logp1 in BASIC on the Hewlett\-Packard HP-71B
>  and APPLE Macintosh, EXP1 and LN1 in Pascal, exp1 and log1 in C
>  on APPLE Macintoshes, where they have been provided to make
> -sure financial calculations of ((1+x)**n\-1)/x, namely
> -expm1(n*log1p(x))/x, will be accurate when x is tiny.
> +sure financial calculations of ((1 + x)**n \(mi 1) / x, namely
> +expm1(n * log1p(x)) / x, will be accurate when x is tiny.
>  They also provide accurate inverse hyperbolic functions.
>  .Pp
>  The function
> 

Re: ptrace PT_IO write bug

[Mark Kettenis]

> From: Jeremie Courreges-Anglas 
> Date: Mon, 30 May 2016 19:30:27 +0200
> 
> Mark Kettenis  writes:
> 
> > Mathieu - schreef op 2016-05-28 13:05:
> >> Martin Natano wrote:
> >>> The diff reads fine to me, however it is incomplete. There are some
> >>> callers of process_domem() in arch/. They will need to be changed too.
> >>> req seems to be in sync with uio_rw in all the cases, so just removing
> >>> the last argument should do it.
> >>>
> >>
> >> Thanks for the feedback. The missing callers where an overlook on my
> >> part, sorry for that.
> >>
> >> Here is a regenerated diff including all the call site. As a side note,
> >> obviously every one of them was using PT_WRITE_I, that's why it went
> >> unnoticed.
> >
> > The thing you guys are missing is that on some architectures making
> > changes to instructions (PT_WRITE_I) requires some additional operations
> > to guarantee that the CPU actually sees those updated instructions.
> > Typically this is the case on architectures with separate data and
> > instruction caches, where the instruction cache doesn't snoop the data
> > cache.  On such architectures (powerpc and arm are examples) you need to
> > flush the data cache and invalidate the instruction cache.  That may be
> > a somewhat expensive operation.
> > As you probably guessed, pmap_proc_iflush() is the function that takes
> > care of this.  Since you still call pmap_proc_iflush(), the diff isn't
> > wrong from a correctness point of view, but I think we should keep the
> > optimization of not calling pmap_proc_iflush() for PT_WRITE_D.
> 
> Since PT_WRITE_I and PT_WRITE_D are documented as strictly equivalent
> since rev. 1.1, I doubt that such an optimization is a good idea.

A clear case where the documentation is wrong.

Re: ptrace PT_IO write bug

[Jeremie Courreges-Anglas]

Mark Kettenis  writes:

> Mathieu - schreef op 2016-05-28 13:05:
>> Martin Natano wrote:
>>> The diff reads fine to me, however it is incomplete. There are some
>>> callers of process_domem() in arch/. They will need to be changed too.
>>> req seems to be in sync with uio_rw in all the cases, so just removing
>>> the last argument should do it.
>>>
>>
>> Thanks for the feedback. The missing callers where an overlook on my
>> part, sorry for that.
>>
>> Here is a regenerated diff including all the call site. As a side note,
>> obviously every one of them was using PT_WRITE_I, that's why it went
>> unnoticed.
>
> The thing you guys are missing is that on some architectures making
> changes to instructions (PT_WRITE_I) requires some additional operations
> to guarantee that the CPU actually sees those updated instructions.
> Typically this is the case on architectures with separate data and
> instruction caches, where the instruction cache doesn't snoop the data
> cache.  On such architectures (powerpc and arm are examples) you need to
> flush the data cache and invalidate the instruction cache.  That may be
> a somewhat expensive operation.
> As you probably guessed, pmap_proc_iflush() is the function that takes
> care of this.  Since you still call pmap_proc_iflush(), the diff isn't
> wrong from a correctness point of view, but I think we should keep the
> optimization of not calling pmap_proc_iflush() for PT_WRITE_D.

Since PT_WRITE_I and PT_WRITE_D are documented as strictly equivalent
since rev. 1.1, I doubt that such an optimization is a good idea.

> As for the original issue.  Adding UVM_IO_FIXPROT for PT_WRITE_D as
> well, means that it will now be able to make changes to read-only data.
> That is probably corrrect.
>
> So I think the only thing that should be changed is the following bit:
>
>> @@ -734,11 +724,11 @@ process_domem(struct proc *curp, struct proc *p,
>> struct uio *uio, int req)
>>  vm->vm_refcnt++;
>>
>>  error = uvm_io(>vm_map, uio,
>> -(req == PT_WRITE_I) ? UVM_IO_FIXPROT : 0);
>> +(uio->uio_rw == UIO_WRITE) ? UVM_IO_FIXPROT : 0);
>>
>
> Is that indeed enough to fix the original problem?

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: pppoe(4) vlan priorities

[Daniel Gillen]

On 30.05.2016 18:24, Stuart Henderson wrote:
> So people are running into the pppoe vlan priority problem again, some
> ISP equipment doesn't like the default of IFQ_DEFPRIO (prio 3).
> 
> http://permalink.gmane.org/gmane.os.openbsd.misc/231358
> 
> As things stand, priority of normal IP packets can be set using PF
> rules, but there's no way to set the priority of pppoe control frames,
> and whichever way you look at it, the value we're currently using is not
> optimal.
> 
> The diff below adds a #define and applies it in the appropriate places
> to set priority on the control frames. I sent out similar diffs a couple
> of times before but had zero feedback, the only difference with this one
> is that it has been updated to apply following the removal of pppoe(4)
> server.
> 
> I had a thought of using interface priority from the pppoe interface,
> but after implementing that I realised it's bogus because that is for
> setting *route* priorities.
> 
> So as in the previous diffs it's still hard coded to 7 at present -
> highest priority, "Network Control" - which is most appropriate for
> these frames in normal conditions.
> 
> People having the problem where they require 0 in the vlan header will
> need to change the #define to SPPP_CTL_PRIO 1, and use a PF rule like
> "match on pppoe set prio 1". (Yes, 1, not 0; IEEE 802.1Q-2014 table I-2).
> For those people the advantage of this diff over the other one is that
> in other cases vlan priorities will still work as expected.
> 
> Any comments?
> 

Just tested your patch on my 5.9-stable amd64 gateway.

Setting SPPP_CTL_PRIO to 1 and adding "match out on pppoe0 set prio 1"
to /etc/pf.conf solves my issues.

The only drawback is having to change the source and compiling a new
kernel. Would be nice if this could be configured in hostname.pppoe0 :)

Thx for the patch.

Daniel

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!

Re: exp.3: remove ancient history and some markup tweaks

[Mark Kettenis]

> Date: Mon, 30 May 2016 18:55:42 +0200
> From: Theo Buehler 
> 
> On Mon, May 30, 2016 at 06:24:55PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 30 May 2016 15:34:04 +0200
> > > From: Joerg Sonnenberger 
> > > 
> > > On Mon, May 30, 2016 at 02:16:20PM +0200, Theo Buehler wrote:
> > > > It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and
> > > > log1p(x) = log(1 + x) are provided and what their historical purpose is.
> > > > However, as mlarkin@ put it: are any of our users of exp(3) going to
> > > > seriously be asking themselves "hmm, is OpenBSD's exp compatible with
> > > > BASIC on the HP-71B?"
> > > 
> > > The wording change also changes the semantics quite a bit. The old
> > > wording explained where the name came from and what the function does.
> > > The new wording implies somewhat that the functions are obsolete, which
> > > is far from true.
> > 
> > Right.  The function is as releveant as ever. And not only for
> > "financial" calculations.  The new text isn't an improvment.
> 
> Ok, maybe the choice of the word 'historically' was suboptimal.  I
> didn't intend to imply irrelevance or obsolescence.  Note also that this
> is in the NOTES section, not in the DESCRIPTION section.
> 
> How about this?

Sorry.  No.  The use of originally still implies that these functions
are no longer relevant for the purpose mentioned in the sentence.  It
doesn't make sense without the historic context.  I'd simply leave the
NOTES section as-is.

> Index: exp.3
> ===
> RCS file: /var/cvs/src/lib/libm/man/exp.3,v
> retrieving revision 1.33
> diff -u -p -r1.33 exp.3
> --- exp.3 26 Apr 2016 19:49:22 -  1.33
> +++ exp.3 30 May 2016 16:38:34 -
> @@ -139,7 +139,7 @@ function is an extended precision versio
>  .Pp
>  The
>  .Fn expm1
> -function computes the value exp(x)\-1 accurately even for tiny argument
> +function computes the value exp(x) \(mi 1 accurately even for tiny argument
>  .Fa x .
>  The
>  .Fn expm1f
> @@ -194,7 +194,7 @@ function is an extended precision versio
>  The
>  .Fn log1p
>  function computes
> -the value of log(1+x) accurately even for tiny argument
> +the value of log(1 + x) accurately even for tiny argument
>  .Fa x .
>  The
>  .Fn log1pf
> @@ -277,12 +277,9 @@ are accurate enough that
>  .Fn pow integer integer
>  is exact until it is bigger than 2**53 for IEEE 754.
>  .Sh NOTES
> -The functions exp(x)\-1 and log(1+x) are called
> -expm1 and logp1 in BASIC on the Hewlett\-Packard HP-71B
> -and APPLE Macintosh, EXP1 and LN1 in Pascal, exp1 and log1 in C
> -on APPLE Macintoshes, where they have been provided to make
> -sure financial calculations of ((1+x)**n\-1)/x, namely
> -expm1(n*log1p(x))/x, will be accurate when x is tiny.
> +Originally, expm1(x) = exp(x) \(mi 1 and log1p(x) = log(1 + x)
> +were used to ensure financial calculations of ((1 + x)**n \(mi 1) / x,
> +namely expm1(n * log1p(x)) / x, are accurate when x is tiny.
>  They also provide accurate inverse hyperbolic functions.
>  .Pp
>  The function
> 
> 
> 

Re: exp.3: remove ancient history and some markup tweaks

[Theo Buehler]

> Sorry.  No.  The use of originally still implies that these functions
> are no longer relevant for the purpose mentioned in the sentence.  It
> doesn't make sense without the historic context.  I'd simply leave the
> NOTES section as-is.

Fine. Here's the diff only doing the markup stuff.

Index: exp.3
===
RCS file: /var/cvs/src/lib/libm/man/exp.3,v
retrieving revision 1.33
diff -u -p -r1.33 exp.3
--- exp.3   26 Apr 2016 19:49:22 -  1.33
+++ exp.3   30 May 2016 17:30:40 -
@@ -139,7 +139,7 @@ function is an extended precision versio
 .Pp
 The
 .Fn expm1
-function computes the value exp(x)\-1 accurately even for tiny argument
+function computes the value exp(x) \(mi 1 accurately even for tiny argument
 .Fa x .
 The
 .Fn expm1f
@@ -194,7 +194,7 @@ function is an extended precision versio
 The
 .Fn log1p
 function computes
-the value of log(1+x) accurately even for tiny argument
+the value of log(1 + x) accurately even for tiny argument
 .Fa x .
 The
 .Fn log1pf
@@ -277,12 +277,12 @@ are accurate enough that
 .Fn pow integer integer
 is exact until it is bigger than 2**53 for IEEE 754.
 .Sh NOTES
-The functions exp(x)\-1 and log(1+x) are called
+The functions exp(x) \(mi 1 and log(1 + x) are called
 expm1 and logp1 in BASIC on the Hewlett\-Packard HP-71B
 and APPLE Macintosh, EXP1 and LN1 in Pascal, exp1 and log1 in C
 on APPLE Macintoshes, where they have been provided to make
-sure financial calculations of ((1+x)**n\-1)/x, namely
-expm1(n*log1p(x))/x, will be accurate when x is tiny.
+sure financial calculations of ((1 + x)**n \(mi 1) / x, namely
+expm1(n * log1p(x)) / x, will be accurate when x is tiny.
 They also provide accurate inverse hyperbolic functions.
 .Pp
 The function

Re: pool related crashes, but "kernel did no panic"

[Alexey Suslikov]

On Thu, May 12, 2016 at 4:14 PM, Bob Beck  wrote:
> Thank you!now that's a bug report..

Hi.

Moved to 6.0-beta some time ago to make crash dumps more up
to date. Also, removed some services to minimize their impact.

Fresh build against today's cvs don't survived even half of the day.

http://article.gmane.org/gmane.os.openbsd.bugs/23593

For me, it looks like: 5.7-5.8 - rare crashes, 5.9-6.0 - more frequent
crashes.

Backtrace differs from crash to crash, but this remains the same:

Stopped at  pool_put+0x1dd: xorq0x8(%rax),%rcx

Do you have any idea where should I look in a source code?

Thanks.

Re: exp.3: remove ancient history and some markup tweaks

[Theo Buehler]

On Mon, May 30, 2016 at 06:24:55PM +0200, Mark Kettenis wrote:
> > Date: Mon, 30 May 2016 15:34:04 +0200
> > From: Joerg Sonnenberger 
> > 
> > On Mon, May 30, 2016 at 02:16:20PM +0200, Theo Buehler wrote:
> > > It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and
> > > log1p(x) = log(1 + x) are provided and what their historical purpose is.
> > > However, as mlarkin@ put it: are any of our users of exp(3) going to
> > > seriously be asking themselves "hmm, is OpenBSD's exp compatible with
> > > BASIC on the HP-71B?"
> > 
> > The wording change also changes the semantics quite a bit. The old
> > wording explained where the name came from and what the function does.
> > The new wording implies somewhat that the functions are obsolete, which
> > is far from true.
> 
> Right.  The function is as releveant as ever. And not only for
> "financial" calculations.  The new text isn't an improvment.

Ok, maybe the choice of the word 'historically' was suboptimal.  I
didn't intend to imply irrelevance or obsolescence.  Note also that this
is in the NOTES section, not in the DESCRIPTION section.

How about this?

Index: exp.3
===
RCS file: /var/cvs/src/lib/libm/man/exp.3,v
retrieving revision 1.33
diff -u -p -r1.33 exp.3
--- exp.3   26 Apr 2016 19:49:22 -  1.33
+++ exp.3   30 May 2016 16:38:34 -
@@ -139,7 +139,7 @@ function is an extended precision versio
 .Pp
 The
 .Fn expm1
-function computes the value exp(x)\-1 accurately even for tiny argument
+function computes the value exp(x) \(mi 1 accurately even for tiny argument
 .Fa x .
 The
 .Fn expm1f
@@ -194,7 +194,7 @@ function is an extended precision versio
 The
 .Fn log1p
 function computes
-the value of log(1+x) accurately even for tiny argument
+the value of log(1 + x) accurately even for tiny argument
 .Fa x .
 The
 .Fn log1pf
@@ -277,12 +277,9 @@ are accurate enough that
 .Fn pow integer integer
 is exact until it is bigger than 2**53 for IEEE 754.
 .Sh NOTES
-The functions exp(x)\-1 and log(1+x) are called
-expm1 and logp1 in BASIC on the Hewlett\-Packard HP-71B
-and APPLE Macintosh, EXP1 and LN1 in Pascal, exp1 and log1 in C
-on APPLE Macintoshes, where they have been provided to make
-sure financial calculations of ((1+x)**n\-1)/x, namely
-expm1(n*log1p(x))/x, will be accurate when x is tiny.
+Originally, expm1(x) = exp(x) \(mi 1 and log1p(x) = log(1 + x)
+were used to ensure financial calculations of ((1 + x)**n \(mi 1) / x,
+namely expm1(n * log1p(x)) / x, are accurate when x is tiny.
 They also provide accurate inverse hyperbolic functions.
 .Pp
 The function

Re: exp.3: remove ancient history and some markup tweaks

[Mark Kettenis]

> Date: Mon, 30 May 2016 15:34:04 +0200
> From: Joerg Sonnenberger 
> 
> On Mon, May 30, 2016 at 02:16:20PM +0200, Theo Buehler wrote:
> > It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and
> > log1p(x) = log(1 + x) are provided and what their historical purpose is.
> > However, as mlarkin@ put it: are any of our users of exp(3) going to
> > seriously be asking themselves "hmm, is OpenBSD's exp compatible with
> > BASIC on the HP-71B?"
> 
> The wording change also changes the semantics quite a bit. The old
> wording explained where the name came from and what the function does.
> The new wording implies somewhat that the functions are obsolete, which
> is far from true.

Right.  The function is as releveant as ever. And not only for
"financial" calculations.  The new text isn't an improvment.

Re: exp.3: remove ancient history and some markup tweaks

[Joerg Sonnenberger]

On Mon, May 30, 2016 at 04:30:10PM +0200, Marc Espie wrote:
> On Mon, May 30, 2016 at 03:34:04PM +0200, Joerg Sonnenberger wrote:
> > On Mon, May 30, 2016 at 02:16:20PM +0200, Theo Buehler wrote:
> > > It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and
> > > log1p(x) = log(1 + x) are provided and what their historical purpose is.
> > > However, as mlarkin@ put it: are any of our users of exp(3) going to
> > > seriously be asking themselves "hmm, is OpenBSD's exp compatible with
> > > BASIC on the HP-71B?"
> > 
> > The wording change also changes the semantics quite a bit. The old
> > wording explained where the name came from and what the function does.
> > The new wording implies somewhat that the functions are obsolete, which
> > is far from true.
> 
> Huh ?
> "computes the value ... accurately even for tiny arguments".
> 
> That's quite enough as far as a function description goes.

Look at the changed NOTES section. The rest is fine.

Joerg

pppoe(4) vlan priorities

[Stuart Henderson]

So people are running into the pppoe vlan priority problem again, some
ISP equipment doesn't like the default of IFQ_DEFPRIO (prio 3).

http://permalink.gmane.org/gmane.os.openbsd.misc/231358

As things stand, priority of normal IP packets can be set using PF
rules, but there's no way to set the priority of pppoe control frames,
and whichever way you look at it, the value we're currently using is not
optimal.

The diff below adds a #define and applies it in the appropriate places
to set priority on the control frames. I sent out similar diffs a couple
of times before but had zero feedback, the only difference with this one
is that it has been updated to apply following the removal of pppoe(4)
server.

I had a thought of using interface priority from the pppoe interface,
but after implementing that I realised it's bogus because that is for
setting *route* priorities.

So as in the previous diffs it's still hard coded to 7 at present -
highest priority, "Network Control" - which is most appropriate for
these frames in normal conditions.

People having the problem where they require 0 in the vlan header will
need to change the #define to SPPP_CTL_PRIO 1, and use a PF rule like
"match on pppoe set prio 1". (Yes, 1, not 0; IEEE 802.1Q-2014 table I-2).
For those people the advantage of this diff over the other one is that
in other cases vlan priorities will still work as expected.

Any comments?


Index: if_sppp.h
===
RCS file: /cvs/src/sys/net/if_sppp.h,v
retrieving revision 1.23
diff -u -p -r1.23 if_sppp.h
--- if_sppp.h   11 Nov 2015 01:49:17 -  1.23
+++ if_sppp.h   30 May 2016 15:55:35 -
@@ -56,6 +56,7 @@ enum ppp_phase {
 
 #define AUTHMAXLEN 256 /* including terminating '\0' */
 #define AUTHCHALEN 16  /* length of the challenge we send */
+#define SPPP_CTL_PRIO  7   /* priority to use for control packets */
 
 /*
  * Definitions to pass struct sppp data down into the kernel using the
Index: if_pppoe.c
===
RCS file: /cvs/src/sys/net/if_pppoe.c,v
retrieving revision 1.55
diff -u -p -r1.55 if_pppoe.c
--- if_pppoe.c  18 Apr 2016 14:38:08 -  1.55
+++ if_pppoe.c  30 May 2016 15:55:35 -
@@ -1011,6 +1011,7 @@ pppoe_send_padi(struct pppoe_softc *sc)
m0 = pppoe_get_mbuf(len + PPPOE_HEADERLEN); /* header len + payload 
len */
if (m0 == NULL)
return (ENOBUFS);
+   m0->m_pkthdr.pf.prio = SPPP_CTL_PRIO;
 
/* fill in pkt */
p = mtod(m0, u_int8_t *);
@@ -1237,6 +1238,7 @@ pppoe_send_padr(struct pppoe_softc *sc)
m0 = pppoe_get_mbuf(len + PPPOE_HEADERLEN);
if (m0 == NULL)
return (ENOBUFS);
+   m0->m_pkthdr.pf.prio = SPPP_CTL_PRIO;
 
p = mtod(m0, u_int8_t *);
PPPOE_ADD_HEADER(p, PPPOE_CODE_PADR, 0, len);
@@ -1300,6 +1302,7 @@ pppoe_send_padt(unsigned int ifidx, u_in
if_put(eth_if);
return (ENOBUFS);
}
+   m0->m_pkthdr.pf.prio = SPPP_CTL_PRIO;
 
p = mtod(m0, u_int8_t *);
PPPOE_ADD_HEADER(p, PPPOE_CODE_PADT, session, 0);
Index: if_spppsubr.c
===
RCS file: /cvs/src/sys/net/if_spppsubr.c,v
retrieving revision 1.152
diff -u -p -r1.152 if_spppsubr.c
--- if_spppsubr.c   2 May 2016 22:15:49 -   1.152
+++ if_spppsubr.c   30 May 2016 15:55:35 -
@@ -914,6 +914,7 @@ sppp_cp_send(struct sppp *sp, u_short pr
return;
m->m_pkthdr.len = m->m_len = PKTHDRLEN + LCP_HEADER_LEN + len;
m->m_pkthdr.ph_ifidx = 0;
+   m->m_pkthdr.pf.prio = SPPP_CTL_PRIO;
 
*mtod(m, u_int16_t *) = htons(proto);
lh = (struct lcp_header *)(mtod(m, u_int8_t *) + 2);
@@ -3991,6 +3992,7 @@ sppp_auth_send(const struct cp *cp, stru
if (! m)
return;
m->m_pkthdr.ph_ifidx = 0;
+   m->m_pkthdr.pf.prio = SPPP_CTL_PRIO;
 
*mtod(m, u_int16_t *) = htons(cp->proto);
lh = (struct lcp_header *)(mtod(m, u_int8_t *) + 2);

Re: ugen(4) Asynchronous USB Requests

[Phil Vachon]

Hi Martin,

Thank you very much for the information and commentary!

On May 30, 2016 at 9:28:52 AM, Martin Pieuchot wrote:

> Hello Phil,
> 
> On 26/05/16(Thu) 14:55, Phil Vachon wrote:
> > Hi all,
> >
> > -- snip --
> 
> You should get in touch with Grant Czajkowski, he did something similar
> during the GSoC 2015, see:
> 
> https://www.google-melange.com/gsoc/project/details/google/gsoc2015/coolguy1253/5649050225344512
> 

Damn, now I wish I had looked harder before I embarked on all this. I
will reach out to Grant and see how we could maybe work together to
get this over the finish line to go into an upcoming release. It's
very helpful to have! I'm guessing Grant's contact info can be found
in the mailing list archives, so I'll have a look.

> >
> > Currently broken things:
> > - The entire synchronous interface (poll-related changes)
> 
> That's fine as long as libusb is update accordingly. But if it doesn't
> make sense to keep two set of ioctl(2) then, simply get rid of the old
> ones ;)
> 

Loud and clear. I'll see if we can keep the current interface as
intact as possible (based on your comment below), but if there are
'appendices' that remain, they will be removed.

> > - Cancelling pending transfers
> 
> That's the hard part of the problem. Grant's work includes a working
> solution, but modifying the HC driver for that should be avoided.
> 

This is one thing I'm not 100% understanding -- my plan (though Grant
has already gone through this) was to expose the pipe's abort()
method through a similar usbi_* function. I presumed this should be
callable safely at splusb(), since this is how a pipe goes about
cleaning itself up? There was a change to uhci(4) that seems to insert
a USB task for every transfer that is to be cancelled, is this the HC
driver change you're referring to?

I am guessing that my presumption that abort() is safely callable at
splusb() is wrong?

The other thing that I was trying to avoid in cancellation was having
complexities around identifying pending operations. Originally I
hacked something together using the address of the source/target
userspace buffer for identifying the operation. But the same buffer
could be reused for multiple transactions so this does not make
sense. The other idea I had was to provide a transaction 'handle'
returned by the USB_ASYNC_SUBMIT ioctl(2) that would then be used to
later reference the operation. Both approaches have lots of downsides,
but since libusb is already doing bookkeeping on the programmer's
behalf, the latter approach might not be too onerous.

> > - Isochronous transfers
> 
> That's not important in the first place.
> 

I didn't think so, but I was thinking of providing a kernel-managed
queue for isochronous transfers. Then userspace would populate the
queue with transfers to be submitted after the next isochronous
transfer completes. Something similar could be done for interrupt
endpoints too, which would allow for the timing 'requirements' to be
met more readily for such things. 

> > - Kqueue (maybe? I haven't tested it thoroughly yet)
> 
> Not sure if we should keep support it. If libusb's handle_event doesn't
> need kqueue(2) support after your modifications then it can go.
> 

It _could_ be used I suppose, since the libusb user could register to
receive notification of all new fds, and use kqueue(2) rather than
poll(2) to receive notification of completed operations. I was
planning to support it, based on that.

> > - Locking is somewhat heavy-handed in places
> 
> Please removing your locking code. All ioctl(2) are serialized by the
> KERNEL_LOCK(). The only problem is if your code can sleep, in which
> case the mutex you're using does not help.
> 

Perfect, will do. I guess I was worried about concurrent modification
of the queue of pending ops, but if all ioctl(2) are serialized as
such, then there's no sense in keeping any locking around. This was
one thing that I'm admittedly not comfortable with in OpenBSD, and
need to learn more about.

> > - There's a hard cap of 16 asynchronous operations in-flight per
> > endpoint at this time. This could be readily made configurable.
> 
> Nice.
> 
> > My current test cases are a trivial "smoke test" of the API, as well as 
> > using libusb and the libimobiledevice/usbmux and ipheth-pair tools. Of 
> > course, this requires a modified libusb, which can be found at:
> > https://github.com/pvachon/libusb - see the openbsd-6.0 branch
> 
> Nice, I'd really suggest you to look at Grant's work, hopefully with him
> because his work also solve some other issues, like timeout handling
> without deprecating the existing interface.
> 
> > and some light modifications to usbmuxd:
> > https://github.com/pvachon/usbmuxd
> 
> Nice, I'd suggest you to submit a port for usbmuxd :)
> 
> > Otherwise, upstream libimobiledevice, libusbmux, etc. can all be used 
> > as-is.
> >

I'll make ports for all of these, seems there are none that exist as of today.
Makes sense, since they didn't work before.

Re: sed/regcomp bug?

[Ingo Schwarze]

Hi Martijn,

Martijn van Duren wrote on Sat, May 28, 2016 at 10:58:27PM +0200:

> Here's part two of the sed fix.  It applies the just added
> REG_NOTBOL|REG_STARTEND change to sed, so that begin of word
> matches directly after a previous match, ending in not a
> word, can match.
> 
> It passes regress and an earlier version of this patch (based on
> an earlier attempt of the libregex patch) passed a full ports build
> thanks to aja@ for testing.
> 
> before:
> $ echo x,x,x,x,x,x, | sed 's/\ y,x,y,x,y,x,
> after:
> $ echo x,x,x,x,x,x, | sed 's/\ y,y,y,y,y,y,
> 
> OK?

Yes, OK schwarze@, with or without any of the three following tweaks,
however you prefer.

Yours,
  Ingo


> Index: process.c
> ===
> RCS file: /cvs/src/usr.bin/sed/process.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 process.c
> --- process.c 26 Oct 2015 14:08:47 -  1.27
> +++ process.c 28 May 2016 20:56:30 -
> @@ -61,7 +61,8 @@ static SPACE HS, PS, SS;
>  static inline int applies(struct s_command *);
>  static void   flush_appends(void);
>  static void   lputs(char *);
> -static inline int regexec_e(regex_t *, const char *, int, int, size_t);
> +static inline int regexec_e(regex_t *, const char *, int, int, size_t,
> +  size_t);
>  static void   regsub(SPACE *, char *, char *);
>  static intsubstitute(struct s_command *);
>  
> @@ -267,7 +268,7 @@ new:  if (!nflag && !pd)
>   * (lastline, linenumber, ps).
>   */
>  #define  MATCH(a)\
> - (a)->type == AT_RE ? regexec_e((a)->u.r, ps, 0, 1, psl) :   \
> + (a)->type == AT_RE ? regexec_e((a)->u.r, ps, 0, 1, 0, psl) :\
>   (a)->type == AT_LINE ? linenum == (a)->u.l : lastline()
>  
>  /*
> @@ -335,6 +336,7 @@ substitute(struct s_command *cp)
>   regex_t *re;
>   regoff_t slen;
>   int n, lastempty;
> + size_t le = 0;
>   char *s;
>  
>   s = ps;
> @@ -346,7 +348,7 @@ substitute(struct s_command *cp)
>   cp->u.s->maxbref);
>   }
>   }
> - if (!regexec_e(re, s, 0, 0, psl))
> + if (!regexec_e(re, s, 0, 0, 0, psl))
>   return (0);
>  
>   SS.len = 0; /* Clean substitute space. */

Bikeshed:
Consider making that

  + if(!regexec_e(re, ps, 0, 0, 0, psl))

for clarity.  You are no longer using "s" for the regexec_e()
at the end of the loop either.  No functional change.

> @@ -356,28 +358,30 @@ substitute(struct s_command *cp)
>  
>   do {
>   /* Copy the leading retained string. */
> - if (n <= 1 && match[0].rm_so)
> - cspace(, s, match[0].rm_so, APPEND);
> + if (n <= 1 && (match[0].rm_so - le))

Bikeshed:
Consider making that

  + if (n <= 1 && (match[0].rm_so > le))

I'd find that easier to understand in the condition.
No functional change.

> + cspace(, s, match[0].rm_so - le, APPEND);
>  
>   /* Skip zero-length matches right after other matches. */
> - if (lastempty || match[0].rm_so ||
> + if (lastempty || (match[0].rm_so - le) ||
>   match[0].rm_so != match[0].rm_eo) {
>   if (n <= 1) {
>   /* Want this match: append replacement. */
> - regsub(, s, cp->u.s->new);
> + regsub(, ps, cp->u.s->new);
>   if (n == 1)
>   n = -1;
>   } else {
>   /* Want a later match: append original. */
> - if (match[0].rm_eo)
> - cspace(, s, match[0].rm_eo, APPEND);
> + if (match[0].rm_eo - le)
> + cspace(, s, match[0].rm_eo - le,
> + APPEND);
>   n--;
>   }
>   }
>  
>   /* Move past this match. */
> - s += match[0].rm_eo;
> - slen -= match[0].rm_eo;
> + s += (match[0].rm_eo - le);
> + slen -= (match[0].rm_eo - le);

Bikeshed:
Consider making that

  + s = ps + match[0].rm_eo;
  + slen = psl - match[0].rm_eo;

Seems much easier to understand.  No functional change.

> + le = match[0].rm_eo;
>  
>   /*
>* After a zero-length match, advance one byte,
> @@ -388,13 +392,16 @@ substitute(struct s_command *cp)
>   slen = -1;
>   else
>   slen--;
> - if (*s != '\0')
> + if (*s != '\0') {
>   cspace(, s++, 1, 

Re: nd6_output() and NULL

[Alexander Bluhm]

On Mon, May 30, 2016 at 02:46:18PM +0200, Martin Pieuchot wrote:
> Here's a corrected version of the previous diff that got backed out.
> 
> The idea is still to stop calling nd6_output() with a NULL ``rt''
> argument in order to always use the same code path when inserting
> routes.
> 
> ok?

OK bluhm@

> 
> Index: net/pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.973
> diff -u -p -r1.973 pf.c
> --- net/pf.c  28 May 2016 12:04:33 -  1.973
> +++ net/pf.c  30 May 2016 12:42:46 -
> @@ -5665,11 +5665,13 @@ pf_route6(struct mbuf **m, struct pf_rul
>  {
>   struct mbuf *m0;
>   struct sockaddr_in6 *dst, sin6;
> + struct rtentry  *rt = NULL;
>   struct ip6_hdr  *ip6;
>   struct ifnet*ifp = NULL;
>   struct pf_addr   naddr;
>   struct pf_src_node  *sns[PF_SN_MAX];
>   struct m_tag*mtag;
> + unsigned int rtableid;
>  
>   if (m == NULL || *m == NULL || r == NULL ||
>   (dir != PF_IN && dir != PF_OUT) || oifp == NULL)
> @@ -5702,6 +5704,7 @@ pf_route6(struct mbuf **m, struct pf_rul
>   dst->sin6_family = AF_INET6;
>   dst->sin6_len = sizeof(*dst);
>   dst->sin6_addr = ip6->ip6_dst;
> + rtableid = m0->m_pkthdr.ph_rtableid;
>  
>   if (!r->rt) {
>   m0->m_pkthdr.pf.flags |= PF_TAG_GENERATED;
> @@ -5754,7 +5757,13 @@ pf_route6(struct mbuf **m, struct pf_rul
>   if ((mtag = m_tag_find(m0, PACKET_TAG_PF_REASSEMBLED, NULL))) {
>   (void) pf_refragment6(, mtag, dst, ifp);
>   } else if ((u_long)m0->m_pkthdr.len <= ifp->if_mtu) {
> - nd6_output(ifp, m0, dst, NULL);
> + rt = rtalloc(sin6tosa(dst), RT_RESOLVE, rtableid);
> + if (rt == NULL) {
> + ip6stat.ip6s_noroute++;
> + goto bad;
> + }
> + nd6_output(ifp, m0, dst, rt);
> + rtfree(rt);
>   } else {
>   icmp6_error(m0, ICMP6_PACKET_TOO_BIG, 0, ifp->if_mtu);
>   }
> Index: net/pf_norm.c
> ===
> RCS file: /cvs/src/sys/net/pf_norm.c,v
> retrieving revision 1.185
> diff -u -p -r1.185 pf_norm.c
> --- net/pf_norm.c 28 May 2016 12:04:33 -  1.185
> +++ net/pf_norm.c 30 May 2016 04:33:01 -
> @@ -687,6 +687,7 @@ pf_refragment6(struct mbuf **m0, struct 
>  {
>   struct mbuf *m = *m0, *t;
>   struct pf_fragment_tag  *ftag = (struct pf_fragment_tag *)(mtag + 1);
> + struct rtentry  *rt = NULL;
>   u_int32_tmtu;
>   u_int16_thdrlen, extoff, maxlen;
>   u_int8_t proto;
> @@ -742,6 +743,16 @@ pf_refragment6(struct mbuf **m0, struct 
>   DPFPRINTF(LOG_NOTICE, "refragment error %d", error);
>   action = PF_DROP;
>   }
> +
> + if (ifp != NULL) {
> + rt = rtalloc(sin6tosa(dst), RT_RESOLVE,
> + m->m_pkthdr.ph_rtableid);
> + if (rt == NULL) {
> + ip6stat.ip6s_noroute++;
> + error = -1;
> + }
> + }
> +
>   for (t = m; m; m = t) {
>   t = m->m_nextpkt;
>   m->m_nextpkt = NULL;
> @@ -750,7 +761,7 @@ pf_refragment6(struct mbuf **m0, struct 
>   if (ifp == NULL) {
>   ip6_forward(m, 0);
>   } else if ((u_long)m->m_pkthdr.len <= ifp->if_mtu) {
> - nd6_output(ifp, m, dst, NULL);
> + nd6_output(ifp, m, dst, rt);
>   } else {
>   icmp6_error(m, ICMP6_PACKET_TOO_BIG, 0,
>   ifp->if_mtu);
> @@ -759,6 +770,7 @@ pf_refragment6(struct mbuf **m0, struct 
>   m_freem(m);
>   }
>   }
> + rtfree(rt);
>  
>   return (action);
>  }

Re: exp.3: remove ancient history and some markup tweaks

[Marc Espie]

On Mon, May 30, 2016 at 03:34:04PM +0200, Joerg Sonnenberger wrote:
> On Mon, May 30, 2016 at 02:16:20PM +0200, Theo Buehler wrote:
> > It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and
> > log1p(x) = log(1 + x) are provided and what their historical purpose is.
> > However, as mlarkin@ put it: are any of our users of exp(3) going to
> > seriously be asking themselves "hmm, is OpenBSD's exp compatible with
> > BASIC on the HP-71B?"
> 
> The wording change also changes the semantics quite a bit. The old
> wording explained where the name came from and what the function does.
> The new wording implies somewhat that the functions are obsolete, which
> is far from true.

Huh ?
"computes the value ... accurately even for tiny arguments".

That's quite enough as far as a function description goes.


When it does matter, you're pretty much going to lose anyway.
You can possibly want to add references to external texts
(Art of computer programming, Numerical recipes, or any decent IEEE754
text would do... 

https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
is probably the best short reference IMO), but if people do floating point
stuff without understanding the basics, the manpage isn't really going to
help anyway.


Losing the full historical explanation of the name is not that big a problem;
the names are very much self-explanatory.

Re: utvfu driver port

[Martin Pieuchot]

On 26/05/16(Thu) 16:09, patrick keshishian wrote:
> 
> Included is my initial effort to port the dual-licensed driver
> for Fushicai Audio-Video Grabber (vendor 0x1b71 product 0x3002).

Nice.  Did you test both bulk and iso? Some comments inline.

> Index: dev/usb/files.usb
> ===
> RCS file: /cvs/obsd/src/sys/dev/usb/files.usb,v
> retrieving revision 1.126
> diff -u -p -u -p -r1.126 files.usb
> --- dev/usb/files.usb 8 Jan 2016 15:54:13 -   1.126
> +++ dev/usb/files.usb 26 May 2016 22:34:38 -
> @@ -35,6 +35,12 @@ device uvideo: video, firmload
>  attach   uvideo at uhub
>  file dev/usb/uvideo.cuvideo
>  
> +# USBTV007 devices
> +device   utvfu: video, audio
> +attach   utvfu at uhub
> +file dev/usb/utvfu.c utvfu
> +file dev/usb/utvfu_ops.c utvfu

I'd appreciate if we can keep the driver in one file, when the license
issue is solved, this is coherent with the rest of our tree.

> +#ifndef _UTVFU_H_
> +#define _UTVFU_H_

Is there any hardware reference for this device or everything is reverse
engineered?  I mean the values below are specified somewhere?

> +
> +#include 
> +#include 
> +
> +/* Hardware. */
> +#define UTVFU_VIDEO_ENDP 0x81
> +#define UTVFU_AUDIO_ENDP 0x83
> +#define UTVFU_BASE   0xc000
> +#define UTVFU_REQUEST_REG12
> +
> +/* Number of concurrent isochronous urbs submitted.
> + * Higher numbers was seen to overly saturate the USB bus. */

This comment does not respect style(9).

> +#define UTVFU_ISOC_TRANSFERS 16
> +#define UTVFU_ISOC_PACKETS   8
> +
> +#define UTVFU_CHUNK_SIZE 256
> +#define UTVFU_CHUNK  240
> +
> +#define UTVFU_AUDIO_URBSIZE  20480
> +#define UTVFU_AUDIO_HDRSIZE  4
> +#define UTVFU_AUDIO_BUFFER   65536
> +
> +#define  UTVFU_COMPOSITE_INPUT   0
> +#define  UTVFU_SVIDEO_INPUT  1
  ^^
We try to avoid mixing space and tab after "#define"

> +/* Chunk header. */
> +#define UTVFU_MAGIC(hdr) (hdr & 0xff00U)
> +#define UTVFU_MAGIC_OK(hdr)  ((hdr & 0xff00U) == 0x8800U)
> +#define UTVFU_FRAME_ID(hdr)  ((hdr & 0x00ffU) >> 16)
> +#define UTVFU_ODD(hdr)   ((hdr & 0xf000U) >> 15)
> +#define UTVFU_CHUNK_NO(hdr)  (hdr & 0x0fffU)
> +
> +#define UTVFU_TV_STD  (V4L2_STD_525_60 | V4L2_STD_PAL)
> +
> +/* parameters for supported TV norms */
> +struct utvfu_norm_params {
> + v4l2_std_id norm;
> + int cap_width,
> + cap_height,
> + frame_len;

Please one type per line.

> +};

> +extern struct utvfu_norm_params  utvfu_norm_params[];
> +
> +#define  UTVFU_MAX_BUFFERS   32
> +struct utvfu_mmap {
> + SIMPLEQ_ENTRY(utvfu_mmap)   q_frames;
> + uint8_t *buf;
> + struct v4l2_buffer  v4l2_buf;
> +};
> +typedef SIMPLEQ_HEAD(, utvfu_mmap)   q_mmap;
> +
> +struct utvfu_frame_buf {
> + uintoff;
> + uintsize;
> + uint16_tchunks_done;
> + uint8_t fid; 
> + uint8_t last_odd;
> + uint8_t *buf;
> +};
> +
> +#define  UTVFU_NFRAMES_MAX   40
> +struct utvfu_isoc_xfer {
> + struct utvfu_softc  *sc;
> + struct usbd_xfer*xfer;
> + void*buf;
> + uint16_tsize[UTVFU_NFRAMES_MAX];
> +};
> +
> +struct utvfu_bulk_xfer {
> + struct usbd_xfer*xfer;
> + void*buf;

I'd use the simpler approach of using KERNADDR(>dmabuf, 0) instead
of defining another structure to abstract an USB xfer.  You can look at
uhidev_get_report_async_cb() for an example.

> +};
> +
> +struct utvfu_vs_iface {
> + struct usbd_pipe*pipeh;
> + int endpoint;
> + uint32_tpsize;
> + struct utvfu_isoc_xfer  ixfer[UTVFU_ISOC_TRANSFERS];
> +};
> +
> +struct utvfu_as_iface {
> + struct usbd_pipe*pipeh;
> + int endpoint;
> + struct utvfu_bulk_xfer  bxfer;
> +};
> +
> +struct utvfu_audio_chan {
> + uint8_t *start;
> + uint8_t *end;
> + uint8_t *cur;
> + int blksize;
> + void*intr_arg;
> + void(*intr)(void *);
> + struct utvfu_as_iface   iface;
> +};
> +
> +/* Per-device structure. */
> +struct utvfu_softc {
> + struct device   sc_dev;
> + struct usbd_device  *sc_udev;
> + struct usbd_interface   *sc_uifaceh;
> +
> + /* audio & video device */
> + struct device   *sc_audiodev;
> + struct device   *sc_videodev;
> +
> + int sc_normi;
> + int sc_nchunks;
> + int sc_input;
> + int sc_max_frame_sz;
> + int sc_nframes;
> +
> + 

Re: exp.3: remove ancient history and some markup tweaks

[Joerg Sonnenberger]

On Mon, May 30, 2016 at 02:16:20PM +0200, Theo Buehler wrote:
> It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and
> log1p(x) = log(1 + x) are provided and what their historical purpose is.
> However, as mlarkin@ put it: are any of our users of exp(3) going to
> seriously be asking themselves "hmm, is OpenBSD's exp compatible with
> BASIC on the HP-71B?"

The wording change also changes the semantics quite a bit. The old
wording explained where the name came from and what the function does.
The new wording implies somewhat that the functions are obsolete, which
is far from true.

Joerg

Re: ip_output, KERNEL_LOCK and multicast

[Stefan Sperling]

On Mon, May 30, 2016 at 02:49:11PM +0200, Martin Pieuchot wrote:
> Do not grab the KERNEL_LOCK if the source address is already specified.
> 
> Note that the sending path will still be done while holding the
> KERNEL_LOCK but it doesn't hurt to get this right.  Plus this makes it
> similar to another chunk in this file.
> 
> ok?

Yeah, makes sense. OK

> 
> Index: netinet/ip_output.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_output.c,v
> retrieving revision 1.322
> diff -u -p -r1.322 ip_output.c
> --- netinet/ip_output.c   4 May 2016 13:22:51 -   1.322
> +++ netinet/ip_output.c   30 May 2016 04:53:09 -
> @@ -185,14 +185,17 @@ reroute:
>   if ((IN_MULTICAST(ip->ip_dst.s_addr) ||
>   (ip->ip_dst.s_addr == INADDR_BROADCAST)) &&
>   imo != NULL && (ifp = if_get(imo->imo_ifidx)) != NULL) {
> - struct in_ifaddr *ia;
>  
>   mtu = ifp->if_mtu;
> - KERNEL_LOCK();
> - IFP_TO_IA(ifp, ia);
> - if (ip->ip_src.s_addr == INADDR_ANY && ia)
> - ip->ip_src = ia->ia_addr.sin_addr;
> - KERNEL_UNLOCK();
> + if (ip->ip_src.s_addr == INADDR_ANY) {
> + struct in_ifaddr *ia;
> +
> + KERNEL_LOCK();
> + IFP_TO_IA(ifp, ia);
> + if (ia != NULL)
> + ip->ip_src = ia->ia_addr.sin_addr;
> + KERNEL_UNLOCK();
> + }
>   } else {
>   struct in_ifaddr *ia;
>  
> 

Re: plug rt leak

[Alexander Bluhm]

On Mon, May 30, 2016 at 02:24:10PM +0200, Martin Pieuchot wrote:
> Good catch, updated diff below.

OK bluhm@

> 
> Index: net/route.c
> ===
> RCS file: /cvs/src/sys/net/route.c,v
> retrieving revision 1.300
> diff -u -p -r1.300 route.c
> --- net/route.c   2 May 2016 22:15:49 -   1.300
> +++ net/route.c   27 May 2016 11:34:54 -
> @@ -1091,6 +1091,10 @@ rtrequest(int req, struct rt_addrinfo *i
>* it to (re)order routes.
>*/
>   if ((error = rt_setgate(rt, info->rti_info[RTAX_GATEWAY]))) {
> + ifafree(ifa);
> + rtfree(rt->rt_parent);
> + rtfree(rt->rt_gwroute);
> + free(rt->rt_gateway, M_RTABLE, 0);
>   free(ndst, M_RTABLE, dlen);
>   pool_put(_pool, rt);
>   return (error);
> @@ -1118,12 +1122,9 @@ rtrequest(int req, struct rt_addrinfo *i
>   }
>   if (error != 0) {
>   ifafree(ifa);
> - if ((rt->rt_flags & RTF_CLONED) != 0 && rt->rt_parent)
> - rtfree(rt->rt_parent);
> - if (rt->rt_gwroute)
> - rtfree(rt->rt_gwroute);
> - if (rt->rt_gateway)
> - free(rt->rt_gateway, M_RTABLE, 0);
> + rtfree(rt->rt_parent);
> + rtfree(rt->rt_gwroute);
> + free(rt->rt_gateway, M_RTABLE, 0);
>   free(ndst, M_RTABLE, dlen);
>   pool_put(_pool, rt);
>   return (EEXIST);
> @@ -1163,10 +1164,8 @@ rt_setgate(struct rtentry *rt, struct so
>   }
>   memmove(rt->rt_gateway, gate, glen);
>  
> - if (rt->rt_gwroute != NULL) {
> - rtfree(rt->rt_gwroute);
> - rt->rt_gwroute = NULL;
> - }
> + rtfree(rt->rt_gwroute);
> + rt->rt_gwroute = NULL;
>  
>   return (0);
>  }

Re: ugen(4) Asynchronous USB Requests

[Martin Pieuchot]

Hello Phil,

On 26/05/16(Thu) 14:55, Phil Vachon wrote:
> Hi all,
> 
> In order to make iPhone USB tethering work with OpenBSD, I ended up 
> going a bit down the proverbial rabbit's hole.
> 
> After initially playing around with trying to build a userspace 
> 'driver' using a tap interface, I found that ugen(4) was entirely 
> blocking. I had started hacking around this using separate 
> reader/writer threads, but realized that ugen(4) could be fairly 
> readily made capable of submitting and tracking multiple asynchronous 
> operations on a single endpoint without too much effort.
> 
> Thus this patch was born. At this point, I'm really looking for 
> comments as to what the appetite would be for such a drastic change 
> (while attempting to maintain backwards compatibility for code that 
> depends on the existing behavior), as well as feedback on the interface 
> and code itself.

You should get in touch with Grant Czajkowski, he did something similar
during the GSoC 2015, see:

https://www.google-melange.com/gsoc/project/details/google/gsoc2015/coolguy1253/5649050225344512

> The major changes are:
>  - Asynchronous USB operations are supported through 3 new ioctls:
>   USB_ASYNC_SUBMIT - submit a new asynchronous operation
>   USB_ASYNC_CANCEL - cancel a pending operation (TBD)
>   USB_ASYNC_FINISH - retrieve the next completed operation
>    All three operations act on a new 'struct usb_async_op'.
>  - Control, Bulk and Interrupt endpoints all are supported through the
>    same API, with Control operations requiring the setup packet be in
>    the first bytes of the data packet.
> 
> Currently broken things:
>  - The entire synchronous interface (poll-related changes)

That's fine as long as libusb is update accordingly.  But if it doesn't
make sense to keep two set of ioctl(2) then, simply get rid of the old
ones ;)

>  - Cancelling pending transfers

That's the hard part of the problem.  Grant's work includes a working
solution, but modifying the HC driver for that should be avoided.

>  - Isochronous transfers

That's not important in the first place.  

>  - Kqueue (maybe? I haven't tested it thoroughly yet)

Not sure if we should keep support it.  If libusb's handle_event doesn't
need kqueue(2) support after your modifications then it can go.

>  - Locking is somewhat heavy-handed in places

Please removing your locking code.  All ioctl(2) are serialized by the
KERNEL_LOCK().  The only problem is if your code can sleep, in which
case the mutex you're using does not help.

>  - There's a hard cap of 16 asynchronous operations in-flight per
>    endpoint at this time. This could be readily made configurable.

Nice.

> My current test cases are a trivial "smoke test" of the API, as well as 
> using libusb and the libimobiledevice/usbmux and ipheth-pair tools. Of 
> course, this requires a modified libusb, which can be found at:
>     https://github.com/pvachon/libusb - see the openbsd-6.0 branch

Nice, I'd really suggest you to look at Grant's work, hopefully with him
because his work also solve some other issues, like timeout handling
without deprecating the existing interface.

> and some light modifications to usbmuxd:
>     https://github.com/pvachon/usbmuxd

Nice, I'd suggest you to submit a port for usbmuxd :)

> Otherwise, upstream libimobiledevice, libusbmux, etc. can all be used 
> as-is.
> 
> Any thoughts are appreciated.
> 
> Index: sys/dev/usb/ugen.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ugen.c,v
> retrieving revision 1.94
> diff -u -p -r1.94 ugen.c
> --- sys/dev/usb/ugen.c24 May 2016 05:35:01 -  1.94
> +++ sys/dev/usb/ugen.c26 May 2016 17:16:55 -
> @@ -10,6 +10,8 @@
>   * by Lennart Augustsson (lenn...@augustsson.net) at
>   * Carlstedt Research & Technology.
>   *
> + * Copyright (C) 2016 Phil Vachon 
> + *
>   * Redistribution and use in source and binary forms, with or without
>   * modification, are permitted provided that the following conditions
>   * are met:
> @@ -50,61 +52,97 @@
>  #include 
>  #include 
>  
> +#define EPDEV(_ep) (&(_ep)->sc->sc_dev)
> +#define SCDEV(_sc) (&(_sc)->sc_dev)
> +
>  #ifdef UGEN_DEBUG
>  #define DPRINTF(x)   do { if (ugendebug) printf x; } while (0)
>  #define DPRINTFN(n,x)do { if (ugendebug>(n)) printf x; } while (0)
> +#define UPRINTF(_dev, msg, ...) do { (void)printf("%s: " msg "\n", 
> (_dev)->dv_xname, ##__VA_ARGS__); } while (0)
>  int  ugendebug = 0;
>  #else
>  #define DPRINTF(x)
>  #define DPRINTFN(n,x)
> +#define UPRINTF(...)
>  #endif
>  
>  #define  UGEN_CHUNK  128 /* chunk size for read */
>  #define  UGEN_IBSIZE 1020/* buffer size */
>  #define  UGEN_BBSIZE 1024
>  
> -#define  UGEN_NISOFRAMES 500 /* 0.5 seconds worth */
> -#define UGEN_NISOREQS6   /* number of outstanding xfer requests 
> */
> -#define 

Re: W^X compliance

[Marc Espie]

On Sun, May 29, 2016 at 12:00:14PM -0600, Theo de Raadt wrote:
> If anyone decides to engage an upstream developer about their software
> performing W^X violations, please be respectful, detailed, and calm.
> The major W^X violators which remain are not simple pieces of
> software, and their authors will not make improvements in this area in
> a fortnight.  It is going to take a lot of patience.

Taking the opportunity to stress again the plague of the ports tree:
copy-pasting bugs.  We have some variations upon the same library that exist
in at least 3 different variations, with various ways to show basically the
same mode of failure.

(shows up there wrt webkit and libffi at least, and probably some others,
though I haven't looked too closely yet).

Yes, copying/forking the same code saves time instead of talking to upstream
to get what you need, but we do pay it heavily every time.

This is, again, a very long term problem that will take forever to address
(e.g., people discover again and again that antipattern, that packaging and
forking alleviates their immediate problem, but causes a HUGE debt later on
with respect to security issues).

Well, let's be positive, and say that at least, the current W^X changes
show with glaring clarity some examples of that anti-pattern at work...

bookmark for later use with the next problem we face. :p

Re: Bridge STP and multicast address

[Martin Pieuchot]

On 24/05/16(Tue) 13:08, Alexandre MOREL wrote:
> Hi,
> 
> Hope that I'm writing to the adequate mailing list in order to have some
> ideas or point of view about a functionality need after some troubleshoot
> with STP and other networks devices.
> 
> In order to have two "redundancy" firewalls based on ethernet bridges, I
> have two servers with on each a bridge network interface that add two vlans
> interfaces on each. I use RSTP in order to get one in a discarding state
> and the other in forwarding state so this let's the loop open.
> All the vlans are provides by a trunk interface (LACP) off two 10G ethernet
> interfaces. It's work very well and it's very efficient for our needs.
> 
> But, with some switchs vendors (here force10), we have network device
> that's drop all the BPDU of RSTP, so there is no forwarding of RSTP hello
> on the ports.
> Despite the disabling of all STP process on it, it's impossible to get
> BPDUs forwarded on ports.
> I's appear that it's not possible to flood BPDU on the 4810 force10.
> 
> After some quick changes in bridgestp and if_bridge source, now my bridge
> are able to send BPDU to a different multicast address. This permit to have
> an instance
> of RSTP dedicated for this ethernet bridges.
> Of course, it's doesn't respect the standard address of STP but it permit
> to bypass this kind of limitation due to network devices and mays also
> permit
> to have more than one STP domain. It's may be very useful to have the
> possibility to change the destination address for the STP packets from cli
> like
> ifconfig bridgeX spanmac 01:80:c2:00:00:10 (change from the default
> 01:80:c2:00:00:00) ...
> 
> Maybe someone have another idea to solve this kind of problem ? and will it
> be interesting to have a patch about this feature into OpenBSD ?

Please send your diff then we can discuss if we want to integrate or not
:)

> I hope my explanations are clear and there is an interest in this system.

Your explanations are good, it's just hard to answer without seeing the
actual code change.

Cheers,
Martin

Re: siginfo_t.si_addr should be void*

[Martin Pieuchot]

On 27/04/16(Wed) 18:52, i80...@foxquill.com wrote:
> On 2016-04-27 18:20, Joerg Sonnenberger wrote:
> >This
> >[...snip...]
> >and this disagree?
> 
> I... am so sorry. You're right of course; I don't know how that patch
> happened.

ok mpi@

> diff --git a/src/sys/sys/siginfo.h b/src/sys/sys/siginfo.h
> index 814e8f2..1e8365f 100644
> --- a/src/sys/sys/siginfo.h
> +++ b/src/sys/sys/siginfo.h
> @@ -150,7 +150,7 @@ typedef struct {
>   } _pdata;
>   } _proc;
>   struct {/* SIGSEGV, SIGBUS, SIGILL and SIGFPE */
> - caddr_t _addr;  /* faulting address */
> + void*_addr; /* faulting address */
>   int _trapno;/* illegal trap number */
>   } _fault;
>  #if 0
> 

ip_output, KERNEL_LOCK and multicast

[Martin Pieuchot]

Do not grab the KERNEL_LOCK if the source address is already specified.

Note that the sending path will still be done while holding the
KERNEL_LOCK but it doesn't hurt to get this right.  Plus this makes it
similar to another chunk in this file.

ok?

Index: netinet/ip_output.c
===
RCS file: /cvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.322
diff -u -p -r1.322 ip_output.c
--- netinet/ip_output.c 4 May 2016 13:22:51 -   1.322
+++ netinet/ip_output.c 30 May 2016 04:53:09 -
@@ -185,14 +185,17 @@ reroute:
if ((IN_MULTICAST(ip->ip_dst.s_addr) ||
(ip->ip_dst.s_addr == INADDR_BROADCAST)) &&
imo != NULL && (ifp = if_get(imo->imo_ifidx)) != NULL) {
-   struct in_ifaddr *ia;
 
mtu = ifp->if_mtu;
-   KERNEL_LOCK();
-   IFP_TO_IA(ifp, ia);
-   if (ip->ip_src.s_addr == INADDR_ANY && ia)
-   ip->ip_src = ia->ia_addr.sin_addr;
-   KERNEL_UNLOCK();
+   if (ip->ip_src.s_addr == INADDR_ANY) {
+   struct in_ifaddr *ia;
+
+   KERNEL_LOCK();
+   IFP_TO_IA(ifp, ia);
+   if (ia != NULL)
+   ip->ip_src = ia->ia_addr.sin_addr;
+   KERNEL_UNLOCK();
+   }
} else {
struct in_ifaddr *ia;
 

nd6_output() and NULL

[Martin Pieuchot]

Here's a corrected version of the previous diff that got backed out.

The idea is still to stop calling nd6_output() with a NULL ``rt''
argument in order to always use the same code path when inserting
routes.

ok?

Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.973
diff -u -p -r1.973 pf.c
--- net/pf.c28 May 2016 12:04:33 -  1.973
+++ net/pf.c30 May 2016 12:42:46 -
@@ -5665,11 +5665,13 @@ pf_route6(struct mbuf **m, struct pf_rul
 {
struct mbuf *m0;
struct sockaddr_in6 *dst, sin6;
+   struct rtentry  *rt = NULL;
struct ip6_hdr  *ip6;
struct ifnet*ifp = NULL;
struct pf_addr   naddr;
struct pf_src_node  *sns[PF_SN_MAX];
struct m_tag*mtag;
+   unsigned int rtableid;
 
if (m == NULL || *m == NULL || r == NULL ||
(dir != PF_IN && dir != PF_OUT) || oifp == NULL)
@@ -5702,6 +5704,7 @@ pf_route6(struct mbuf **m, struct pf_rul
dst->sin6_family = AF_INET6;
dst->sin6_len = sizeof(*dst);
dst->sin6_addr = ip6->ip6_dst;
+   rtableid = m0->m_pkthdr.ph_rtableid;
 
if (!r->rt) {
m0->m_pkthdr.pf.flags |= PF_TAG_GENERATED;
@@ -5754,7 +5757,13 @@ pf_route6(struct mbuf **m, struct pf_rul
if ((mtag = m_tag_find(m0, PACKET_TAG_PF_REASSEMBLED, NULL))) {
(void) pf_refragment6(, mtag, dst, ifp);
} else if ((u_long)m0->m_pkthdr.len <= ifp->if_mtu) {
-   nd6_output(ifp, m0, dst, NULL);
+   rt = rtalloc(sin6tosa(dst), RT_RESOLVE, rtableid);
+   if (rt == NULL) {
+   ip6stat.ip6s_noroute++;
+   goto bad;
+   }
+   nd6_output(ifp, m0, dst, rt);
+   rtfree(rt);
} else {
icmp6_error(m0, ICMP6_PACKET_TOO_BIG, 0, ifp->if_mtu);
}
Index: net/pf_norm.c
===
RCS file: /cvs/src/sys/net/pf_norm.c,v
retrieving revision 1.185
diff -u -p -r1.185 pf_norm.c
--- net/pf_norm.c   28 May 2016 12:04:33 -  1.185
+++ net/pf_norm.c   30 May 2016 04:33:01 -
@@ -687,6 +687,7 @@ pf_refragment6(struct mbuf **m0, struct 
 {
struct mbuf *m = *m0, *t;
struct pf_fragment_tag  *ftag = (struct pf_fragment_tag *)(mtag + 1);
+   struct rtentry  *rt = NULL;
u_int32_tmtu;
u_int16_thdrlen, extoff, maxlen;
u_int8_t proto;
@@ -742,6 +743,16 @@ pf_refragment6(struct mbuf **m0, struct 
DPFPRINTF(LOG_NOTICE, "refragment error %d", error);
action = PF_DROP;
}
+
+   if (ifp != NULL) {
+   rt = rtalloc(sin6tosa(dst), RT_RESOLVE,
+   m->m_pkthdr.ph_rtableid);
+   if (rt == NULL) {
+   ip6stat.ip6s_noroute++;
+   error = -1;
+   }
+   }
+
for (t = m; m; m = t) {
t = m->m_nextpkt;
m->m_nextpkt = NULL;
@@ -750,7 +761,7 @@ pf_refragment6(struct mbuf **m0, struct 
if (ifp == NULL) {
ip6_forward(m, 0);
} else if ((u_long)m->m_pkthdr.len <= ifp->if_mtu) {
-   nd6_output(ifp, m, dst, NULL);
+   nd6_output(ifp, m, dst, rt);
} else {
icmp6_error(m, ICMP6_PACKET_TOO_BIG, 0,
ifp->if_mtu);
@@ -759,6 +770,7 @@ pf_refragment6(struct mbuf **m0, struct 
m_freem(m);
}
}
+   rtfree(rt);
 
return (action);
 }

exp.3: remove ancient history and some markup tweaks

[Theo Buehler]

It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and
log1p(x) = log(1 + x) are provided and what their historical purpose is.
However, as mlarkin@ put it: are any of our users of exp(3) going to
seriously be asking themselves "hmm, is OpenBSD's exp compatible with
BASIC on the HP-71B?"

I suggest to keep a little bit of the historical background but strip
away the extra verbiage.

While there, use \(mi instead of - for the mathematical minus sign, as
mandoc_char(7) recommends.  I'd also like to add some spaces surrounding
the arithmetic operations.  I think this makes the formulas much easier
to parse:  I had to think for a second to be sure whether (1+x)**n-1
means (1+x)**(n-1) or ((1+x)**n)-1, while (1 + x)**n - 1 is hard to
misinterpret at first glance.

Index: exp.3
===
RCS file: /var/cvs/src/lib/libm/man/exp.3,v
retrieving revision 1.33
diff -u -p -r1.33 exp.3
--- exp.3   26 Apr 2016 19:49:22 -  1.33
+++ exp.3   30 May 2016 12:02:21 -
@@ -139,7 +139,7 @@ function is an extended precision versio
 .Pp
 The
 .Fn expm1
-function computes the value exp(x)\-1 accurately even for tiny argument
+function computes the value exp(x) \(mi 1 accurately even for tiny argument
 .Fa x .
 The
 .Fn expm1f
@@ -194,7 +194,7 @@ function is an extended precision versio
 The
 .Fn log1p
 function computes
-the value of log(1+x) accurately even for tiny argument
+the value of log(1 + x) accurately even for tiny argument
 .Fa x .
 The
 .Fn log1pf
@@ -277,12 +277,9 @@ are accurate enough that
 .Fn pow integer integer
 is exact until it is bigger than 2**53 for IEEE 754.
 .Sh NOTES
-The functions exp(x)\-1 and log(1+x) are called
-expm1 and logp1 in BASIC on the Hewlett\-Packard HP-71B
-and APPLE Macintosh, EXP1 and LN1 in Pascal, exp1 and log1 in C
-on APPLE Macintoshes, where they have been provided to make
-sure financial calculations of ((1+x)**n\-1)/x, namely
-expm1(n*log1p(x))/x, will be accurate when x is tiny.
+The historical use of expm1(x) = exp(x) \(mi 1 and log1p(x) = log(1 + x)
+is to make sure financial calculations of ((1 + x)**n \(mi 1) / x,
+namely expm1(n * log1p(x)) / x, will be accurate when x is tiny.
 They also provide accurate inverse hyperbolic functions.
 .Pp
 The function

Re: video(1) mmap support

[Marcus Glocker]

On Mon, May 30, 2016 at 10:49:10AM +0200, Theo Buehler wrote:

> On Mon, May 30, 2016 at 10:02:23AM +0200, Marcus Glocker wrote:
> > I was in the middle of testing a uvideo(4) mmap queue diff when I
> > noticed that our video(1) tool doesn't support the mmap method to grab
> > frames.  This diff adds it and also makes mmap the default method.
> > 
> > Some test reports with different uvideo(4) devices would be welcome.
> > It would be good if you could switch between different resolutions and
> > also regression test the read method.  E.g.:
> > 
> > $ video
> > $ video -s 800x600
> > $ video -s 1600x1200
> > $ video -g
> > $ video -g -s 1024x768
> > ...
> > 
> > Thanks,
> > Marcus
> > 
> 
> A quick test of the built-in camera of my T420, shows no regression when
> directly compared to output of video(1) without your patch.  I tested
> each of the supported frame sizes and rates for about 10 seconds both
> with and without -g.

Thanks for testing!  Attached an updated diff after more feedback from
Patrick Keshishian; Fix frame buffer processing order to dequeue,
process buffer, requeue to avoid a potential buffer overwriting by
driver before we can copy away the buffer.  And added munmap(2) once done.


Index: video.1
===
RCS file: /cvs/xenocara/app/video/video.1,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 video.1
--- video.1 30 Nov 2014 01:40:26 -  1.11
+++ video.1 30 May 2016 12:24:06 -
@@ -25,7 +25,7 @@
 .Sh SYNOPSIS
 .Nm
 .Bk -words
-.Op Fl \
+.Op Fl \
 .Op Fl a Ar adaptor
 .Op Fl e Ar encoding
 .Op Fl f Ar file
@@ -101,6 +101,11 @@ will be used by default.
 device from which frames will be read.
 The default is
 .Pa /dev/video .
+.It Fl g
+Use
+.Xr read 2
+method to grab frames instead of
+.Xr mmap 2 .
 .It Fl i Ar input
 File from which frames will be read.
 If
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 video.c
--- video.c 23 Oct 2014 07:36:06 -  1.12
+++ video.c 30 May 2016 12:24:06 -
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -145,6 +146,9 @@ struct encodings {
 struct video {
struct xdsp  xdsp;
struct dev   dev;
+#define MMAP_NUM_BUFS  4
+   uint8_t  mmap_on;
+   void*mmap_buffer[MMAP_NUM_BUFS];
uint8_t *frame_buffer;
size_t   frame_bufsz;
uint8_t *conv_buffer;
@@ -189,8 +193,11 @@ void dev_reset_ctrls(struct video *);
 int parse_size(struct video *);
 int choose_size(struct video *);
 int choose_enc(struct video *);
+int mmap_init(struct video *);
+int mmap_stop(struct video *);
 int setup(struct video *);
 void cleanup(struct video *, int);
+int ioctl_input(struct video *);
 int poll_input(struct video *);
 int grab_frame(struct video *);
 int stream(struct video *);
@@ -206,7 +213,7 @@ extern char *__progname;
 void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-Rv] "
+   fprintf(stderr, "usage: %s [-gRv] "
"[-a adaptor] [-e encoding] [-f file] [-i input] [-O output]\n"
"   %*s [-o output] [-r rate] [-s size]\n", __progname,
(int)strlen(__progname), "");
@@ -668,10 +675,14 @@ dev_check_caps(struct video *vid)
warnx("%s is not a capture device", d->path);
return 0;
}
-   if (!(cap.capabilities & V4L2_CAP_READWRITE)) {
+   if (!(cap.capabilities & V4L2_CAP_READWRITE) && !vid->mmap_on) {
warnx("%s does not support read(2)", d->path);
return 0;
}
+   if (!(cap.capabilities & V4L2_CAP_STREAMING) && vid->mmap_on) {
+   warnx("%s does not support mmap(2)");
+   return 0;
+   }
d->buf_type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 
return 1;
@@ -1231,6 +1242,85 @@ choose_enc(struct video *vid)
 }
 
 int
+mmap_init(struct video *vid)
+{
+   struct v4l2_requestbuffers rb;
+   struct v4l2_buffer buf;
+   int i, r, type;
+
+   /* request buffers */
+   rb.count = MMAP_NUM_BUFS;
+   r = ioctl(vid->dev.fd, VIDIOC_REQBUFS, );
+   if (r == -1) {
+   warn("ioctl VIDIOC_REQBUFS");
+   return 0;
+   }
+
+   /* mmap the buffers */
+   for (i = 0; i < MMAP_NUM_BUFS; i++) {
+   buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory = V4L2_MEMORY_MMAP;
+   buf.index = i;
+   r = ioctl(vid->dev.fd, VIDIOC_QUERYBUF, );
+   if (r == -1) {
+   warn("ioctl VIDIOC_QUERYBUF");
+   return 0;
+   }
+   vid->mmap_buffer[i] = mmap(0, buf.length, PROT_READ,
+   MAP_SHARED, vid->dev.fd, buf.m.offset);
+   if (vid->mmap_buffer[i] == NULL) {

Re: plug rt leak

[Martin Pieuchot]

On 25/05/16(Wed) 01:47, Alexander Bluhm wrote:
> On Tue, May 24, 2016 at 05:03:32PM +0200, Martin Pieuchot wrote:
> > Hrvoje Popovski founds that as soon as his ARP cache reached 2097152
> > entries his machine started leaking route entries.
> > 
> > Turns out that with that many entries he exhausted malloc(9) and
> > rt_setgate() started failing, leaking the rt->rt_parent reference.
> > 
> > The diff below fixes the issue, ok?
> [...] 
> > free(ndst, M_RTABLE, dlen);
> > pool_put(_pool, rt);
> > return (error);
> > @@ -1118,12 +1122,9 @@ rtrequest(int req, struct rt_addrinfo *i
> > }
> > if (error != 0) {
> > ifafree(ifa);
> > -   if ((rt->rt_flags & RTF_CLONED) != 0 && rt->rt_parent)
> > -   rtfree(rt->rt_parent);
> > -   if (rt->rt_gwroute)
> > -   rtfree(rt->rt_gwroute);
> > -   if (rt->rt_gateway)
> > -   free(rt->rt_gateway, M_RTABLE, 0);
> > +   rtfree(rt->rt_parent);
> > +   rtfree(rt->rt_gwroute);
> > +   free(rt->rt_gateway, M_RTABLE, 0);
> > free(ndst, M_RTABLE, dlen);
> > pool_put(_pool, rt);
> > return (EEXIST);
> 
> Have you considered to move those two error handlings into a goto
> error to avoid duplication?  Do you know why we return (EEXIST)
> instead of (error) here?

I did, I'm not convinced (yet) but not opposed.

> 
> > @@ -1163,10 +1164,7 @@ rt_setgate(struct rtentry *rt, struct so
> > }
> > memmove(rt->rt_gateway, gate, glen);
> >  
> > -   if (rt->rt_gwroute != NULL) {
> > -   rtfree(rt->rt_gwroute);
> > -   rt->rt_gwroute = NULL;
> > -   }
> > +   rtfree(rt->rt_gwroute);
> 
> Why have you removed the rt->rt_gwroute = NULL here?  It results
> in a freed pointer that may be used later.

Good catch, updated diff below.

Index: net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.300
diff -u -p -r1.300 route.c
--- net/route.c 2 May 2016 22:15:49 -   1.300
+++ net/route.c 27 May 2016 11:34:54 -
@@ -1091,6 +1091,10 @@ rtrequest(int req, struct rt_addrinfo *i
 * it to (re)order routes.
 */
if ((error = rt_setgate(rt, info->rti_info[RTAX_GATEWAY]))) {
+   ifafree(ifa);
+   rtfree(rt->rt_parent);
+   rtfree(rt->rt_gwroute);
+   free(rt->rt_gateway, M_RTABLE, 0);
free(ndst, M_RTABLE, dlen);
pool_put(_pool, rt);
return (error);
@@ -1118,12 +1122,9 @@ rtrequest(int req, struct rt_addrinfo *i
}
if (error != 0) {
ifafree(ifa);
-   if ((rt->rt_flags & RTF_CLONED) != 0 && rt->rt_parent)
-   rtfree(rt->rt_parent);
-   if (rt->rt_gwroute)
-   rtfree(rt->rt_gwroute);
-   if (rt->rt_gateway)
-   free(rt->rt_gateway, M_RTABLE, 0);
+   rtfree(rt->rt_parent);
+   rtfree(rt->rt_gwroute);
+   free(rt->rt_gateway, M_RTABLE, 0);
free(ndst, M_RTABLE, dlen);
pool_put(_pool, rt);
return (EEXIST);
@@ -1163,10 +1164,8 @@ rt_setgate(struct rtentry *rt, struct so
}
memmove(rt->rt_gateway, gate, glen);
 
-   if (rt->rt_gwroute != NULL) {
-   rtfree(rt->rt_gwroute);
-   rt->rt_gwroute = NULL;
-   }
+   rtfree(rt->rt_gwroute);
+   rt->rt_gwroute = NULL;
 
return (0);
 }

Re: nd6 timers vs ticks

[Todd C. Miller]

On Mon, 30 May 2016 17:16:24 +1000, David Gwynne wrote:

> llinfo_nd6 thinks its expiry may extend beyond a timeout interval.
> 
> so it keeps track of the number of ticks it really wants via ln_ntick
> in llinfo_nd6 and schedules multiple timeouts to reach it.
> 
> i think this is a waste of time for two reasons:
> 
> 1. nd6_llinfo_settimer() (which sets this up) doesnt seem to be
> called with a timeout greater than what timeouts can handle. timeouts
> off the wire are ignored if theyre greater than an hour
> (MAX_REACHABLE_TIME), and the largest constant that ends up being
> passed is a day via nd6_gctimer. the fastest ticking arch we have
> is alpha with HZ at 1024, which wraps at about 24 days. we have
> space.
> 
> 2. ln_ntick is a long, which is the same size as int on 32 bit
> archs. the semantics it wants dont exist on a bunch of platforms.
> it is kind of arguing its own uselesness.

OK millert@

 - todd

Re: MBIM Patch - Part 1 of 4

[Stefan Sperling]

On Mon, May 30, 2016 at 09:35:13AM +0200, Gerhard Roth wrote:
> Yes mbim does support IPv6, but the code is still missing.
> I just don't have a SIM card for a provider that gives me an IPv6
> address. So I could only implement it without testing.

Let's just wait until IPv6 arrives in the telco industry.
I'll probably be looking for things to do when I retire in a bit less
than 40 years from now.

On a more serious note, from a process perspective, getting a very minimal
driver into CVS should be the next best step. It doesn't even have to be
hooked to the build yet, but it has to be small and good enough to draw
attention by other devs who would like to use this for mobile data.

Once we've got a minimalist version of this in CVS, this project will
most likely succeed. Before then, you're going to be working on it alone,
and everybody else will just be making smart comments.

So I'd suggest you really focus on stripping it down and getting the stripped
down result into the tree. Adding more features now would just get in the way.

Re: video(1) mmap support

[Theo Buehler]

On Mon, May 30, 2016 at 10:02:23AM +0200, Marcus Glocker wrote:
> I was in the middle of testing a uvideo(4) mmap queue diff when I
> noticed that our video(1) tool doesn't support the mmap method to grab
> frames.  This diff adds it and also makes mmap the default method.
> 
> Some test reports with different uvideo(4) devices would be welcome.
> It would be good if you could switch between different resolutions and
> also regression test the read method.  E.g.:
> 
>   $ video
>   $ video -s 800x600
>   $ video -s 1600x1200
>   $ video -g
>   $ video -g -s 1024x768
>   ...
> 
> Thanks,
> Marcus
> 

A quick test of the built-in camera of my T420, shows no regression when
directly compared to output of video(1) without your patch.  I tested
each of the supported frame sizes and rates for about 10 seconds both
with and without -g.

$ dmesg | grep video
uvideo0 at uhub2 port 6 configuration 1 interface 0 "Chicony Electronics Co., 
Ltd. Integrated Camera" rev 2.00/7.52 addr 3
video0 at uvideo0
$ video -v
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
320x240: 30, 15
352x288: 30, 15
424x240: 30, 15
640x360: 30, 15
640x480: 30, 15
800x448: 15
960x544: 10
1280x720: 10
  controls: brightness, contrast, saturation, hue, gamma, sharpness
Xv adaptor 0, Intel(R) Textured Video:
  encodings: yuy2, uyvy
  max size: 1600x900

video(1) mmap support

[Marcus Glocker]

I was in the middle of testing a uvideo(4) mmap queue diff when I
noticed that our video(1) tool doesn't support the mmap method to grab
frames.  This diff adds it and also makes mmap the default method.

Some test reports with different uvideo(4) devices would be welcome.
It would be good if you could switch between different resolutions and
also regression test the read method.  E.g.:

$ video
$ video -s 800x600
$ video -s 1600x1200
$ video -g
$ video -g -s 1024x768
...

Thanks,
Marcus


Index: video.1
===
RCS file: /cvs/xenocara/app/video/video.1,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 video.1
--- video.1 30 Nov 2014 01:40:26 -  1.11
+++ video.1 30 May 2016 07:48:15 -
@@ -25,7 +25,7 @@
 .Sh SYNOPSIS
 .Nm
 .Bk -words
-.Op Fl \
+.Op Fl \
 .Op Fl a Ar adaptor
 .Op Fl e Ar encoding
 .Op Fl f Ar file
@@ -101,6 +101,11 @@ will be used by default.
 device from which frames will be read.
 The default is
 .Pa /dev/video .
+.It Fl g
+Use
+.Xr read 2
+method to grab frames instead of
+.Xr mmap 2 .
 .It Fl i Ar input
 File from which frames will be read.
 If
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 video.c
--- video.c 23 Oct 2014 07:36:06 -  1.12
+++ video.c 30 May 2016 07:48:15 -
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -145,6 +146,9 @@ struct encodings {
 struct video {
struct xdsp  xdsp;
struct dev   dev;
+#define MMAP_NUM_BUFS  4
+   uint8_t  mmap_on;
+   void*mmap_buffer[MMAP_NUM_BUFS];
uint8_t *frame_buffer;
size_t   frame_bufsz;
uint8_t *conv_buffer;
@@ -189,8 +193,10 @@ void dev_reset_ctrls(struct video *);
 int parse_size(struct video *);
 int choose_size(struct video *);
 int choose_enc(struct video *);
+int mmap_init(struct video *);
 int setup(struct video *);
 void cleanup(struct video *, int);
+int ioctl_input(struct video *);
 int poll_input(struct video *);
 int grab_frame(struct video *);
 int stream(struct video *);
@@ -206,7 +212,7 @@ extern char *__progname;
 void
 usage(void)
 {
-   fprintf(stderr, "usage: %s [-Rv] "
+   fprintf(stderr, "usage: %s [-gRv] "
"[-a adaptor] [-e encoding] [-f file] [-i input] [-O output]\n"
"   %*s [-o output] [-r rate] [-s size]\n", __progname,
(int)strlen(__progname), "");
@@ -668,10 +674,14 @@ dev_check_caps(struct video *vid)
warnx("%s is not a capture device", d->path);
return 0;
}
-   if (!(cap.capabilities & V4L2_CAP_READWRITE)) {
+   if (!(cap.capabilities & V4L2_CAP_READWRITE) && !vid->mmap_on) {
warnx("%s does not support read(2)", d->path);
return 0;
}
+   if (!(cap.capabilities & V4L2_CAP_STREAMING) && vid->mmap_on) {
+   warnx("%s does not support mmap(2)");
+   return 0;
+   }
d->buf_type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 
return 1;
@@ -1231,6 +1241,61 @@ choose_enc(struct video *vid)
 }
 
 int
+mmap_init(struct video *vid)
+{
+   struct v4l2_requestbuffers rb;
+   struct v4l2_buffer buf;
+   int i, r, type;
+
+   /* request buffers */
+   rb.count = MMAP_NUM_BUFS;
+   r = ioctl(vid->dev.fd, VIDIOC_REQBUFS, );
+   if (r == -1) {
+   warn("ioctl VIDIOC_REQBUFS");
+   return 0;
+   }
+
+   /* mmap the buffers */
+   for (i = 0; i < MMAP_NUM_BUFS; i++) {
+   buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory = V4L2_MEMORY_MMAP;
+   buf.index = i;
+   r = ioctl(vid->dev.fd, VIDIOC_QUERYBUF, );
+   if (r == -1) {
+   warn("ioctl VIDIOC_QUERYBUF");
+   return 0;
+   }
+   vid->mmap_buffer[i] = mmap(0, buf.length, PROT_READ,
+   MAP_SHARED, vid->dev.fd, buf.m.offset);
+   if (vid->mmap_buffer[i] == NULL) {
+   warn("mmap");
+   return 0;
+   }
+   }
+
+   /* initial buffer queueing */
+   for (i = 0; i < MMAP_NUM_BUFS; i++) {
+   buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory = V4L2_MEMORY_MMAP;
+   buf.index = i;
+   r = ioctl(vid->dev.fd, VIDIOC_QBUF, );
+   if (r == -1) {
+   warn("ioctl VIDIOC_QBUF");
+   return 0;
+   }
+   }
+
+   /* start video stream */
+   r = ioctl(vid->dev.fd, VIDIOC_STREAMON, );
+   if (r == -1) {
+   warn("ioctl VIDIOC_STREAMON");
+   return 0;
+   }
+
+   return 1;
+}

Re: MBIM Patch - Part 1 of 4

[Gerhard Roth]

On Sat, 28 May 2016 09:18:13 +0200 Stefan Sperling  wrote:
> On Mon, May 23, 2016 at 03:37:32PM +0200, Gerhard Roth wrote:
> > I have this stuff around quite a while now, but since patrick@ asked
> > me repeatedly, I think it is time to share this now.
> > 
> > This is a patch that adds support for the "Mobile Broadband Interface
> > Model" (MBIM) from http://www.usb.org/. It allows to attach UMTS/LTE
> > USB devices as a network interface.
> > 
> > I'm not asking for OKs at this time, but hope that some people will
> > give it test. I tested with two different Sierra Wireless modules
> > (EM8805, MC8305) and each one behaved a little bit different.
> > 
> > In order to configure the network interface, this is what you do:
> > 
> > # ifconfig mbim0 pin 1234 apn internet.t-mobile
> > # ifconfig mbim0 inet 0.0.0.1 0.0.0.2
> > # route delete default
> > # route add -ifp mbim0 default 0.0.0.2
> > # ifconfig mbim0 up
> > 
> > The mbim interface is a point-to-point type interface and will
> > update the default route, once it is registered in the network.
> 
> As others have already said, I think the problem with these diffs
> is that you're trying to solve too many problems at once.
> 
> I believe the problems this driver should solve first and foremost are getting
> a network link and getting an IP assigned to the interface so people can use
> that IP to set up whatever routing they want.
> 
> Could mbim in theory support IPv6? We don't need to do anything about
> this now. But the design shouldn't assume it will only support IPv4.

Yes mbim does support IPv6, but the code is still missing.
I just don't have a SIM card for a provider that gives me an IPv6
address. So I could only implement it without testing.


> 
> Don't worry about breaking existing umsm(4) setups.
> Since this driver provides a much simpler user interface than umsm coupled
> with pppd(8) I'd suggest to eventually prefer attaching mbim instead of umsm
> where possible. I hate having to copy pppd config files around for umsm.
> If I lost those files I'd have to spend a day or so to get the setup working
> again because I don't remember (and don't want to remember) all the AT and
> up/down scripts I used to get umsm to work. That's why I think mbim is 
> promising.
> 
> > To get extended information on the interface use:
> > 
> > # ifconfig mbim0 devinfo
> 
> I don't see the need to add a new subcommand for this.
> If this information is important why is it not shown as part of the
> default 'ifconfig mbim0' output? If it is not important, why show it?
> 
> I agree with Theo that the ifconfig diff is too large. And it seems you're
> exposing too many details at this layer. How much of it can be removed while
> still solving the problem of getting a network link and an IP assigned?
> Can you compress status information on the 'status:' line, instead of printing
> seperate lines for data items such as pin, error state, rssi, ber and so on?
> How much of this information do users really need?

Already removed the 'devinfo' part and compressed the information onto
fewer lines. That will come with the next update of the patch.

nd6 timers vs ticks

[David Gwynne]

llinfo_nd6 thinks its expiry may extend beyond a timeout interval.

so it keeps track of the number of ticks it really wants via ln_ntick
in llinfo_nd6 and schedules multiple timeouts to reach it.

i think this is a waste of time for two reasons:

1. nd6_llinfo_settimer() (which sets this up) doesnt seem to be
called with a timeout greater than what timeouts can handle. timeouts
off the wire are ignored if theyre greater than an hour
(MAX_REACHABLE_TIME), and the largest constant that ends up being
passed is a day via nd6_gctimer. the fastest ticking arch we have
is alpha with HZ at 1024, which wraps at about 24 days. we have
space.

2. ln_ntick is a long, which is the same size as int on 32 bit
archs. the semantics it wants dont exist on a bunch of platforms.
it is kind of arguing its own uselesness.

ok?

Index: nd6.c
===
RCS file: /cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.179
diff -u -p -r1.179 nd6.c
--- nd6.c   17 May 2016 08:29:14 -  1.179
+++ nd6.c   30 May 2016 07:08:09 -
@@ -308,21 +308,16 @@ nd6_llinfo_settimer(struct llinfo_nd6 *l
 {
int s;
 
+   KASSERT(tick <= INT_MAX);
+
s = splsoftnet();
 
if (tick < 0) {
ln->ln_expire = 0;
-   ln->ln_ntick = 0;
timeout_del(>ln_timer_ch);
} else {
ln->ln_expire = time_second + tick / hz;
-   if (tick > INT_MAX) {
-   ln->ln_ntick = tick - INT_MAX;
-   timeout_add(>ln_timer_ch, INT_MAX);
-   } else {
-   ln->ln_ntick = 0;
-   timeout_add(>ln_timer_ch, tick);
-   }
+   timeout_add(>ln_timer_ch, tick);
}
 
splx(s);
@@ -341,18 +336,6 @@ nd6_llinfo_timer(void *arg)
s = splsoftnet();
 
ln = (struct llinfo_nd6 *)arg;
-
-   if (ln->ln_ntick > 0) {
-   if (ln->ln_ntick > INT_MAX) {
-   ln->ln_ntick -= INT_MAX;
-   nd6_llinfo_settimer(ln, INT_MAX);
-   } else {
-   ln->ln_ntick = 0;
-   nd6_llinfo_settimer(ln, ln->ln_ntick);
-   }
-   splx(s);
-   return;
-   }
 
if ((rt = ln->ln_rt) == NULL)
panic("ln->ln_rt == NULL");
Index: nd6.h
===
RCS file: /cvs/src/sys/netinet6/nd6.h,v
retrieving revision 1.58
diff -u -p -r1.58 nd6.h
--- nd6.h   30 Mar 2016 10:13:14 -  1.58
+++ nd6.h   30 May 2016 07:08:09 -
@@ -150,7 +150,6 @@ struct  llinfo_nd6 {
short   ln_state;   /* reachability state */
short   ln_router;  /* 2^0: ND6 router bit */
 
-   longln_ntick;
struct  timeout ln_timer_ch;
 };
 

Clean up regress/usr.bin/sdiff

[Ray Lai]

Okan reminded me that my old regress tests used systrace policy files as 
example text, which weren't the easiest to decypher. I've replaced them with 
simpler files that should make life easier for any future regress test writers.

Comments? Suggestions?

Ray



Index: Iflag12.out
===
RCS file: /home/cvs/src/regress/usr.bin/sdiff/Iflag12.out,v
retrieving revision 1.2
diff -u -p -r1.2 Iflag12.out
--- Iflag12.out 13 Sep 2015 17:08:04 -  1.2
+++ Iflag12.out 30 May 2016 06:06:09 -
@@ -1,100 +1,8 @@
-Policy: /usr/bin/lynx, Emulation: nativePolicy: 
/usr/bin/lynx, Emulation: native
-  > 
native-issetugid: permit
-  > 
native-mprotect: permit
-  > 
native-mmap: permit
-native-sysctl: permit   
native-sysctl: permit
-  > 
native-fsread: filename eq "/var/run/ld.so.hints" then pe
-  > 
native-fstat: permit
-native-close: permit
native-close: permit
-native-connect: sockaddr eq "inet-[127.0.0.1]:53" then pe | 
native-fsread: filename match "/usr/lib/libssl.so.*" then
-native-connect: sockaddr match "inet-\\\[*\\\]:80" then p | 
native-read: permit
-native-exit: permit   | 
native-fsread: filename match "/usr/lib/libcrypto.so.*" t
-native-fcntl: cmd eq "F_SETFD" then permit| 
native-fsread: filename match "/usr/lib/libncurses.so.*" 
-native-fsread: filename eq "/" then permit| 
native-fsread: filename match "/usr/lib/libc.so.*" then p
-native-fsread: filename match "/:  | 
native-munmap: permit
-native-fsread: filename eq "/etc/lynx.cfg" then permit| 
native-sigprocmask: permit
-native-fsread: filename eq "/etc/malloc.conf" then permit   
native-fsread: filename eq "/etc/malloc.conf" then permit
-native-fsread: filename eq "/etc/resolv.conf" then permit | 
native-getpid: permit
-native-fsread: filename eq "/etc/utmp" then permit<
-native-fsread: filename eq "/home" then permit<
-native-fsread: filename eq "$HOME" then permit<
-native-fsread: filename eq "$HOME/.lynx-keymaps" then per <
-native-fsread: filename eq "$HOME/.lynxrc" then permit<
-native-fsread: filename eq "$HOME/.mailcap" then permit   <
-native-fsread: filename eq "$HOME/.mime.types" then permi <
-native-fsread: filename eq "$HOME/.terminfo" then permit  <
-native-fsread: filename eq "$HOME/.terminfo.db" then perm <
-native-fsread: filename eq "/obj" then permit <
-native-fsread: filename eq "/tmp" then permit   
native-fsread: filename eq "/tmp" then permit
-native-fsread: filename match "/tmp/lynx-*/." then permit   
native-fswrite: filename match "/tmp/lynx-*" then permit
-  ) 
native-fsread: filename match "/tmp/lynx-*/." then permit
-  > 
native-fsread: filename eq "$HOME" then permit
-  > 
native-fsread: filename eq "/etc/lynx.cfg" then permit
-  > 
native-fsread: filename eq "/" then permit
-  > 
native-fsread: filename eq "/usr/obj/bin/systrace/." then
-  > 
native-fsread: filename eq "/usr/obj/bin" then permit
-  > 
native-fcntl: permit
-  > 
native-getdirentries: permit
-  > 
native-lseek: permit
-  > 
native-fsread: filename eq "/usr/obj" then permit
-native-fsread: filename eq "/usr" then permit   
native-fsread: filename eq "/usr" then permit
-native-fsread: filename eq "/usr/bin" then permit   
native-fsread: filename eq "/usr/bin" then permit
-native-fsread: filename eq "/usr/games" then permit 
native-fsread: filename eq "/usr/games" then permit
-native-fsread: filename eq "/usr/include" then permit   
native-fsread: filename eq "/usr/include" then permit
-native-fsread: filename eq "/usr/lib" then permit   
native-fsread: filename eq "/usr/lib" then permit
-

Re: libc: __getcwd() is hidden

[Philip Guenther]

On Sun, 29 May 2016, Philip Guenther wrote:
> Total turd polishing: __getcwd() isn't ex, so ported in the shared 
> version of libc, ...

"__getcwd() isn't exported in the shared version of libc"