Re: w: don't print any header with -h

2017-12-14 Thread Martijn van Duren 
Hello Jasper,

On 12/14/17 13:22, Jasper Lievisse Adriaanse wrote:
> Hi,
> 
> currently w(1) on OpenBSD differs from other implementations
> (GNU/Darwin/FreeBSD/SmartOS) in that 'w -h' does print the
> 'USER TTY FROM ...' header whereas the others don't.
> 
> Is there a specific reason for it or could this diff below go in?

I don't know about the history to tell you, and I don't particularly
care about this change either way.

Do note that our uptime(1) says:
This is the “heading” information from w(1).

This has been removed from the FreeBSD uptime manpage.
So if we want to do the same thing, you should also adjust uptime.1.
> 
> Index: w.c
> ===
> RCS file: /cvs/src/usr.bin/w/w.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 w.c
> --- w.c   27 Jul 2017 14:17:34 -  1.63
> +++ w.c   14 Dec 2017 12:19:34 -
> @@ -224,7 +224,8 @@ main(int argc, char *argv[])
>  
>  #define HEADER   "USERTTY FROM  LOGIN@  IDLE WHAT"
>  #define WUSED(sizeof(HEADER) - sizeof("WHAT"))
> - (void)puts(HEADER);
> + if (header)
> + (void)puts(HEADER);
>  
>   kp = kvm_getprocs(kd, KERN_PROC_ALL, 0, sizeof(*kp), );
>   if (kp == NULL)
>

w: don't print any header with -h

2017-12-14 Thread Jasper Lievisse Adriaanse 
Hi,

currently w(1) on OpenBSD differs from other implementations
(GNU/Darwin/FreeBSD/SmartOS) in that 'w -h' does print the
'USER TTY FROM ...' header whereas the others don't.

Is there a specific reason for it or could this diff below go in?

Index: w.c
===
RCS file: /cvs/src/usr.bin/w/w.c,v
retrieving revision 1.63
diff -u -p -r1.63 w.c
--- w.c 27 Jul 2017 14:17:34 -  1.63
+++ w.c 14 Dec 2017 12:19:34 -
@@ -224,7 +224,8 @@ main(int argc, char *argv[])
 
 #define HEADER "USERTTY FROM  LOGIN@  IDLE WHAT"
 #define WUSED  (sizeof(HEADER) - sizeof("WHAT"))
-   (void)puts(HEADER);
+   if (header)
+   (void)puts(HEADER);
 
kp = kvm_getprocs(kd, KERN_PROC_ALL, 0, sizeof(*kp), );
if (kp == NULL)

-- 
jasper

Re: Add reset option to boot command of ddb(4)

2017-12-14 Thread Florian Riehm 

On 12/14/17 12:20, Mark Kettenis wrote:

Date: Thu, 14 Dec 2017 11:49:18 +0100
From: Martin Pieuchot 

On 14/12/17(Thu) 11:30, Mark Kettenis wrote:

X-Originating-IP: 88.153.7.170
Date: Thu, 14 Dec 2017 10:30:21 +0100
From: Martin Pieuchot 

On 13/12/17(Wed) 19:09, Florian Riehm wrote:

Hi,

This patch follows bluhm's attempt for a ddb command 'boot reset'.
My first attempt was not architecture aware.

Tested on i386 by bluhm@ and on amd64 by me.


I don't understand why we need to add "boot reset"?  To not fix ddb(4)
and keep a broken "boot reboot"?  If we cannot fix our own code...


Funny you say that given the discussion about if_downall() on icb ;).


There's nothing funny.  There's people not reporting bugs with traceback
to bugs@ and coming around with workaround like that.


IIRC "boot reset" is all about avoiding the if_downall() call.  And we
really don't want to skip if_downall() in the "boot reboot".  We added
that call since not stopping the DMA engines of the network cards had
some very interesting effects when the machine rebooted...


If if_downall() is a problem, then please show me a traceback where
that's the case.  I'd be delighted to fix it :)


True.  Given the DMA issue, "boot reset" would be a rather dangerous
command.



If the command could lead to DMA issues, I agree that we should not
introduce it.
I also agree that we should try to make boot reboot as reliable as possible
and it works fine in most situations.
Anyway I have seen it hanging in some cases. This is a problem for me,
since I don't have physical access to my machines all the time. In such
cases I preferred the cpu_reset hammer. I have never noticed any side effects
like DMA issues, so I thought it would be a good idea, to provide that way
as a regular ddb feature. But I am also fine without the command.

C mutex impl. for x86

2017-12-14 Thread Martin Pieuchot 
Diff below moves amd64 and i386 mutex to the common C implementation.

The differences are:
  - membar_enter_after_atomic(9) instead of membar_enter(9), and
  - membar_exit_before_atomic(9) instead of membar_exit(9)

I'd appreciate any performance test to know if the performance
degradation is acceptable with these barriers.

Index: amd64/amd64/mutex.c
===
RCS file: amd64/amd64/mutex.c
diff -N amd64/amd64/mutex.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ amd64/amd64/mutex.c 14 Dec 2017 14:49:59 -
@@ -0,0 +1,151 @@
+/* $OpenBSD: mutex.c,v 1.19 2017/09/11 09:52:15 mpi Exp $  */
+
+/*
+ * Copyright (c) 2004 Artur Grabowski 
+ * All rights reserved. 
+ *
+ * Redistribution and use in source and binary forms, with or without 
+ * modification, are permitted provided that the following conditions 
+ * are met: 
+ *
+ * 1. Redistributions of source code must retain the above copyright 
+ *notice, this list of conditions and the following disclaimer. 
+ * 2. The name of the author may not be used to endorse or promote products
+ *derived from this software without specific prior written permission. 
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
+ * THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+void
+__mtx_init(struct mutex *mtx, int wantipl)
+{
+   mtx->mtx_owner = NULL;
+   mtx->mtx_wantipl = wantipl;
+   mtx->mtx_oldipl = IPL_NONE;
+}
+
+#ifdef MULTIPROCESSOR
+#ifdef MP_LOCKDEBUG
+#ifndef DDB
+#error "MP_LOCKDEBUG requires DDB"
+#endif
+
+/* CPU-dependent timing, needs this to be settable from ddb. */
+extern int __mp_lock_spinout;
+#endif
+
+void
+__mtx_enter(struct mutex *mtx)
+{
+#ifdef MP_LOCKDEBUG
+   int nticks = __mp_lock_spinout;
+#endif
+
+   while (__mtx_enter_try(mtx) == 0) {
+   CPU_BUSY_CYCLE();
+
+#ifdef MP_LOCKDEBUG
+   if (--nticks == 0) {
+   db_printf("%s: %p lock spun out", __func__, mtx);
+   db_enter();
+   nticks = __mp_lock_spinout;
+   }
+#endif
+   }
+}
+
+int
+__mtx_enter_try(struct mutex *mtx)
+{
+   struct cpu_info *owner, *ci = curcpu();
+   int s;
+
+   if (mtx->mtx_wantipl != IPL_NONE)
+   s = splraise(mtx->mtx_wantipl);
+
+   owner = atomic_cas_ptr(>mtx_owner, NULL, ci);
+#ifdef DIAGNOSTIC
+   if (__predict_false(owner == ci))
+   panic("mtx %p: locking against myself", mtx);
+#endif
+   if (owner == NULL) {
+   membar_enter_after_atomic();
+   if (mtx->mtx_wantipl != IPL_NONE)
+   mtx->mtx_oldipl = s;
+#ifdef DIAGNOSTIC
+   ci->ci_mutex_level++;
+#endif
+   return (1);
+   }
+
+   if (mtx->mtx_wantipl != IPL_NONE)
+   splx(s);
+
+   return (0);
+}
+#else
+void
+__mtx_enter(struct mutex *mtx)
+{
+   struct cpu_info *ci = curcpu();
+
+#ifdef DIAGNOSTIC
+   if (__predict_false(mtx->mtx_owner == ci))
+   panic("mtx %p: locking against myself", mtx);
+#endif
+
+   if (mtx->mtx_wantipl != IPL_NONE)
+   mtx->mtx_oldipl = splraise(mtx->mtx_wantipl);
+
+   mtx->mtx_owner = ci;
+
+#ifdef DIAGNOSTIC
+   ci->ci_mutex_level++;
+#endif
+}
+
+int
+__mtx_enter_try(struct mutex *mtx)
+{
+   __mtx_enter(mtx);
+   return (1);
+}
+#endif
+
+void
+__mtx_leave(struct mutex *mtx)
+{
+   int s;
+
+   MUTEX_ASSERT_LOCKED(mtx);
+
+#ifdef DIAGNOSTIC
+   curcpu()->ci_mutex_level--;
+#endif
+
+   s = mtx->mtx_oldipl;
+#ifdef MULTIPROCESSOR
+   membar_exit_before_atomic();
+#endif
+   mtx->mtx_owner = NULL;
+   if (mtx->mtx_wantipl != IPL_NONE)
+   splx(s);
+}
Index: amd64/conf/files.amd64
===
RCS file: /cvs/src/sys/arch/amd64/conf/files.amd64,v
retrieving revision 1.91
diff -u -p -r1.91 files.amd64
--- amd64/conf/files.amd64  17 Oct 2017 14:25:35 -  1.91
+++ amd64/conf/files.amd64  14 Dec 2017 14:51:20 -
@@ -28,7 +28,7 @@ file  arch/amd64/amd64/fpu.c
 file   arch/amd64/amd64/softintr.c
 file   arch/amd64/amd64/i8259.c
 file   arch/amd64/amd64/cacheinfo.c
-file

Re: background scan for iwn(4)

2017-12-14 Thread Renato Aguiar 

No regressions noticed using a single AP setup.

iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, 
MIMO 2T2R, MoW

On Wed, Dec 13 2017, Stefan Sperling wrote:

> Since nobody is reporting problems with iwm(4), I took some time to write the
> corresponding diff for iwn(4) as well. I hope this increases test coverage :)
>
> Works for me on:
> iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, 
> MIMO 2T2R, MoW
>
> Index: if_iwn.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
> retrieving revision 1.194
> diff -u -p -r1.194 if_iwn.c
> --- if_iwn.c  26 Oct 2017 15:00:28 -  1.194
> +++ if_iwn.c  13 Dec 2017 16:07:07 -
> @@ -222,7 +222,9 @@ int   iwn_config(struct iwn_softc *);
>  uint16_t iwn_get_active_dwell_time(struct iwn_softc *, uint16_t, 
> uint8_t);
>  uint16_t iwn_limit_dwell(struct iwn_softc *, uint16_t);
>  uint16_t iwn_get_passive_dwell_time(struct iwn_softc *, uint16_t);
> -int  iwn_scan(struct iwn_softc *, uint16_t);
> +int  iwn_scan(struct iwn_softc *, uint16_t, int);
> +void iwn_scan_abort(struct iwn_softc *);
> +int  iwn_bgscan(struct ieee80211com *);
>  int  iwn_auth(struct iwn_softc *, int);
>  int  iwn_run(struct iwn_softc *);
>  int  iwn_set_key(struct ieee80211com *, struct ieee80211_node *,
> @@ -516,6 +518,7 @@ iwn_attach(struct device *parent, struct
>   if_attach(ifp);
>   ieee80211_ifattach(ifp);
>   ic->ic_node_alloc = iwn_node_alloc;
> + ic->ic_bgscan_start = iwn_bgscan;
>   ic->ic_newassoc = iwn_newassoc;
>   ic->ic_updateedca = iwn_updateedca;
>   ic->ic_set_key = iwn_set_key;
> @@ -1761,18 +1764,20 @@ iwn_newstate(struct ieee80211com *ic, en
>   struct iwn_node *wn = (void *)ni;
>   int error;
>
> - timeout_del(>calib_to);
> -
> - if (ic->ic_state == IEEE80211_S_RUN &&
> - (ni->ni_flags & IEEE80211_NODE_HT))
> + if (ic->ic_state == IEEE80211_S_RUN) {
>   ieee80211_mira_cancel_timeouts(>mn);
> + timeout_del(>calib_to);
> + sc->calib.state = IWN_CALIB_STATE_INIT;
> + if (sc->sc_flags & IWN_FLAG_BGSCAN)
> + iwn_scan_abort(sc);
> + }
>
>   switch (nstate) {
>   case IEEE80211_S_SCAN:
>   /* Make the link LED blink while we're scanning. */
>   iwn_set_led(sc, IWN_LED_LINK, 10, 10);
>
> - if ((error = iwn_scan(sc, IEEE80211_CHAN_2GHZ)) != 0) {
> + if ((error = iwn_scan(sc, IEEE80211_CHAN_2GHZ, 0)) != 0) {
>   printf("%s: could not initiate scan\n",
>   sc->sc_dev.dv_xname);
>   return error;
> @@ -1971,11 +1976,13 @@ iwn_rx_done(struct iwn_softc *sc, struct
>   struct ieee80211_frame *wh;
>   struct ieee80211_rxinfo rxi;
>   struct ieee80211_node *ni;
> + struct ieee80211_channel *bss_chan = NULL;
>   struct mbuf *m, *m1;
>   struct iwn_rx_stat *stat;
>   caddr_t head;
>   uint32_t flags;
>   int error, len, rssi;
> + uint8_t chan;
>
>   if (desc->type == IWN_MPDU_RX_DONE) {
>   /* Check for prior RX_PHY notification. */
> @@ -2131,6 +2138,16 @@ iwn_rx_done(struct iwn_softc *sc, struct
>
>   rssi = ops->get_rssi(stat);
>
> + chan = stat->chan;
> + if (chan > IEEE80211_CHAN_MAX)
> + chan = IEEE80211_CHAN_MAX;
> +
> + if (ni == ic->ic_bss) {
> + bss_chan = ni->ni_chan;
> + /* Fix current channel. */
> + ni->ni_chan = >ic_channels[chan];
> + }
> +
>  #if NBPFILTER > 0
>   if (sc->sc_drvbpf != NULL) {
>   struct mbuf mb;
> @@ -2140,9 +2157,8 @@ iwn_rx_done(struct iwn_softc *sc, struct
>   tap->wr_flags = 0;
>   if (stat->flags & htole16(IWN_STAT_FLAG_SHPREAMBLE))
>   tap->wr_flags |= IEEE80211_RADIOTAP_F_SHORTPRE;
> - tap->wr_chan_freq =
> - htole16(ic->ic_channels[stat->chan].ic_freq);
> - chan_flags = ic->ic_channels[stat->chan].ic_flags;
> + tap->wr_chan_freq = htole16(ic->ic_channels[chan].ic_freq);
> + chan_flags = ic->ic_channels[chan].ic_flags;
>   if (ic->ic_curmode != IEEE80211_MODE_11N)
>   chan_flags &= ~IEEE80211_CHAN_HT;
>   tap->wr_chan_flags = htole16(chan_flags);
> @@ -2187,6 +2203,10 @@ iwn_rx_done(struct iwn_softc *sc, struct
>   rxi.rxi_tstamp = 0; /* unused */
>   ieee80211_input(ifp, m, ni, );
>
> + /* Restore BSS channel. */
> + if (ni == ic->ic_bss)
> + ni->ni_chan = bss_chan;
> +
>   /* Node is no longer needed. */
>   ieee80211_release_node(ic, ni);
>  }
> @@ -2586,6 +2606,9 @@ iwn_notif_intr(struct iwn_softc *sc)
>   DPRINTFN(2, ("scanning channel %d status

Re: sign of char on arm64

2017-12-14 Thread Joerg Sonnenberger 
On Thu, Dec 14, 2017 at 12:17:56PM +0100, Mark Kettenis wrote:
> Pretty sure Linux uses the same defaults for the signedness of char as
> everybody else.  But since both signed and unsigned char have to work,
> it might very well be that the rust developers decided to ignore this
> largely historic inconsistency.  I doubt the performance difference is
> significant in any way for modern code.

The issue is not so much a question of performance, but whether zero or
sign extension is used in various places.

Joerg

Re: rpc: use monotime for timeouts

2017-12-14 Thread Jeremie Courreges-Anglas 

Diff committed, thank you Scott.

Here's another diff on top to remove two useless temporary variables,
and unify the names of the remaining ones.

ok?


Index: clnt_tcp.c
===
--- clnt_tcp.c.orig
+++ clnt_tcp.c
@@ -385,7 +385,7 @@ static int
 readtcp(struct ct_data *ct, caddr_t buf, int len)
 {
struct pollfd pfd[1];
-   struct timespec start, after, duration, tmp, delta, wait;
+   struct timespec start, after, duration, delta, wait;
int r, save_errno;
 
if (len == 0)
@@ -402,8 +402,7 @@ readtcp(struct ct_data *ct, caddr_t buf,
 
clock_gettime(CLOCK_MONOTONIC, );
timespecsub(, , );
-   timespecsub(, , );
-   delta = tmp;
+   timespecsub(, , );
if (delta.tv_sec < 0 || !timespecisset())
r = 0;
 
Index: clnt_udp.c
===
--- clnt_udp.c.orig
+++ clnt_udp.c
@@ -216,7 +216,7 @@ clntudp_call(CLIENT *cl,/* client handl
struct sockaddr_in from;
struct rpc_msg reply_msg;
XDR reply_xdrs;
-   struct timespec time_waited, start, after, tmp1, tmp2, wait;
+   struct timespec time_waited, start, after, duration, wait;
bool_t ok;
int nrefreshes = 2; /* number of times to refresh cred */
struct timespec timeout;
@@ -271,8 +271,7 @@ send_again:
for (;;) {
switch (ppoll(pfd, 1, , NULL)) {
case 0:
-   timespecadd(_waited, , );
-   time_waited = tmp1;
+   timespecadd(_waited, , _waited);
if (timespeccmp(_waited, , <))
goto send_again;
return (cu->cu_error.re_status = RPC_TIMEDOUT);
@@ -287,9 +286,8 @@ send_again:
case -1:
if (errno == EINTR) {
clock_gettime(CLOCK_MONOTONIC, );
-   timespecsub(, , );
-   timespecadd(_waited, , );
-   time_waited = tmp2;
+   timespecsub(, , );
+   timespecadd(_waited, , 
_waited);
if (timespeccmp(_waited, , <))
continue;
return (cu->cu_error.re_status = RPC_TIMEDOUT);
Index: svc_tcp.c
===
--- svc_tcp.c.orig
+++ svc_tcp.c
@@ -333,7 +333,7 @@ readtcp(SVCXPRT *xprt, caddr_t buf, int
 {
int sock = xprt->xp_sock;
int nready;
-   struct timespec start, delta, tmp1, tmp2;
+   struct timespec start, after, duration, delta;
struct pollfd pfd[1];
 
/*
@@ -350,12 +350,11 @@ readtcp(SVCXPRT *xprt, caddr_t buf, int
case -1:
if (errno != EINTR)
goto fatal_err;
-   clock_gettime(CLOCK_MONOTONIC, );
-   timespecsub(, , );
-   timespecsub(_per_try, , );
-   if (tmp1.tv_sec < 0 || !timespecisset())
+   clock_gettime(CLOCK_MONOTONIC, );
+   timespecsub(, , );
+   timespecsub(_per_try, , );
+   if (delta.tv_sec < 0 || !timespecisset())
goto fatal_err;
-   delta = tmp1;
continue;
case 0:
goto fatal_err;

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

httpd: send location: header for 307 and 308 status codes

2017-12-14 Thread Sebastian Benoit 

308 and 307 are the new 301 and 302 HTTP Status Codes:

https://tools.ietf.org/html/rfc7538
https://tools.ietf.org/html/rfc7231#section-6.4.7

   ...
   The server SHOULD generate a Location header field ([RFC7231],
   Section 7.1.2) in the response containing a preferred URI reference
   ...


ok?

diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
index e64de0d2f9c..48bc773332a 100644
--- usr.sbin/httpd/server_http.c
+++ usr.sbin/httpd/server_http.c
@@ -875,6 +875,8 @@ server_abort_http(struct client *clt, unsigned int code, 
const char *msg)
case 301:
case 302:
case 303:
+   case 307:
+   case 308:
if (msg == NULL)
break;
memset(buf, 0, sizeof(buf));

Re: Add reset option to boot command of ddb(4)

2017-12-14 Thread Artturi Alm 
On Thu, Dec 14, 2017 at 02:05:36PM +0100, Martin Pieuchot wrote:
> On 14/12/17(Thu) 13:37, Florian Riehm wrote:
> > [...]
> > If the command could lead to DMA issues, I agree that we should not
> > introduce it.
> 
> The problem is not only DMA issues.  The problem is that ddb(4) will
> never get fixed.  If we give people a 'reset' button then how long
> until the core dump code is going to rot?
> 

implying the core dump code is not rotting around already?
it won't take long to count the zer0 replies i got[0],
for suggesting it's broken on armv7 at bugs@ :(

> As the kernel grows in complexity, because of MP or anything else,
> ddb(4) has to grow with it.
> 
> > I also agree that we should try to make boot reboot as reliable as possible
> > and it works fine in most situations.
> > Anyway I have seen it hanging in some cases.
> 
> Please send a bug report next time you see such case :)
> 

-Artturi

[0] https://marc.info/?l=openbsd-bugs=150125176824983=2

Re: Symbols.map for libfuse

2017-12-14 Thread Philip Guenther 
On Thu, 14 Dec 2017, Jeremie Courreges-Anglas wrote:
> > Looks good to me, but I can't judge if you're removing too much, so
> > maybe you should wait for an ok from helg@ as well.
> 
> I have completed a partial ports bulk build with all libfuse consumers,
> no visible fallout, with the updated diff below.  I used DEF and PROTO
> from guenther's libkvm diff for intra-library calls.

Looks good to me.  If helg@ finds a need to expose some APIs being held 
here we can always bump again.  :-)


Philip Guenther

Re: Add reset option to boot command of ddb(4)

2017-12-14 Thread Martin Pieuchot 
On 14/12/17(Thu) 13:37, Florian Riehm wrote:
> [...]
> If the command could lead to DMA issues, I agree that we should not
> introduce it.

The problem is not only DMA issues.  The problem is that ddb(4) will
never get fixed.  If we give people a 'reset' button then how long
until the core dump code is going to rot?

As the kernel grows in complexity, because of MP or anything else,
ddb(4) has to grow with it.

> I also agree that we should try to make boot reboot as reliable as possible
> and it works fine in most situations.
> Anyway I have seen it hanging in some cases.

Please send a bug report next time you see such case :)

Re: Removal of PIM support in kernel

2017-12-14 Thread Joachim Nilsson 
On Sun, 2017-12-10 at 12:48 -0700, Theo de Raadt wrote:
> In our tree, all security or front-facing code must be maintained by
> an interested individual/group.  If it isn't maintained eventually it
> will become a hinderance towards other developments, or error prone
> and therefore a risk factor.  It gets marginalized by other changes.
> Then it gets the axe.

Completely understandable! :)

> Every part of the tree needs believers who commit their time to
> keeping that part good, or even better -- improving it.  Especially
> relevant as minimum standards of quality rises.

+1

> [...]
> Expanding mindshare is a hard social problem, so I'm glad you mailed
> in... hopefully you take the bait mpi has placed in the
> trap^W^W^W^W^W^W^W

He he, well we'll see ;-)

It's not the first time I've considered pitching in with OpenBSD,
and seeing as multicast is a bit of hobby of mine, as well as part
of my daily work, it could very well be what pulls me in.

Thank you for your thorough reply!

Best regards
 /Joachim

Re: rpc: use monotime for timeouts

2017-12-14 Thread Todd C. Miller 
On Thu, 14 Dec 2017 18:00:08 +0100, Jeremie Courreges-Anglas wrote:

> Here's another diff on top to remove two useless temporary variables,
> and unify the names of the remaining ones.

Looks correct, OK millert@

 - todd

Re: Removal of PIM support in kernel

2017-12-14 Thread Joachim Nilsson 
On Sun, 2017-12-10 at 19:14 +0100, Martin Pieuchot wrote:
> On 10/12/17(Sun) 17:59, Joachim Nilsson wrote:
> > [...] 
> > Now, I've got a few worried questions recently about the removal[3]
> > of PIM support in OpenBSD, so I thought I'd ask here.  Why have you
> > removed it?
> [...]
> Last year rzalamena@ rewrote the multicast code to reduce the number
> of global data structures, add rdomain support and sync v6 with v4.
> When he started working on that we considered that adapting
> unmaintained and non-compiled PIM code was too much extra
> work.  That's why this code has been removed.

I see, well that's completely understandable!  I've noticed this
lack of people interested in learning/maintaining multicast in
the Linux world as well, and I agree.  There's no point trying to
keep support if there's nobody there to help out doing the hard
work testing and reviewing patches.

> I'd welcome anyone interested in PIM to work on it.  I'd be great to
> have proper kernel support that meets OpenBSD standard and have it
> enabled by default.  If you're interested in such work, I can help
> you getting started ;)

Heh, well there's that Christmas vacation coming up soon.  I might
very well have a look at it then :-)

In the meantime, thank you so much for taking the time to respond!

Best regards
 /Joachim

Re: Symbols.map for libfuse

2017-12-14 Thread Mark Kettenis 
> From: Jeremie Courreges-Anglas 
> Date: Thu, 14 Dec 2017 10:40:50 +0100
> 
> When reviewing helg@'s last diff I noticed a bunch of stuff that
> shouldn't be exported.  So here's a diff similar to the recent
> diffs for libutil and libkvm.  To get the list of public symbols I used
> symbol visibility.
> 
> The diff below only reduces the symbols list, it does not remove PLT
> entries for internal calls, as I don't feel confident using this
> machinery.  AFAIK this can be done in a subsequent step with no bump.
> 
> check_sym output:
> /usr/lib/libfuse.so.1.1 --> obj/libfuse.so.2.0
> Dynamic export changes:
> removed:
>   __bss_start
>   __data_start
>   _edata
>   _end
>   _fini
>   _init
>   alloc_vn
>   build_realname
>   dict_SPLAY
>   dict_SPLAY_INSERT
>   dict_SPLAY_MINMAX
>   dict_SPLAY_REMOVE
>   dict_check
>   dict_get
>   dict_pop
>   dict_set
>   get_vn_by_name_and_parent
>   ifuse_debug
>   ifuse_debug_init
>   ifuse_exec_opcode
>   ref_vn
>   remove_vnode_from_name_tree
>   set_vn
>   tree_SPLAY
>   tree_SPLAY_INSERT
>   tree_SPLAY_MINMAX
>   tree_SPLAY_REMOVE
>   tree_check
>   tree_get
>   tree_pop
>   tree_set
>   unref_vn
> 
> PLT removed:
>   alloc_vn
>   build_realname
>   dict_SPLAY
>   dict_check
>   dict_get
>   dict_pop
>   dict_set
>   get_vn_by_name_and_parent
>   ifuse_debug_init
>   ifuse_exec_opcode
>   ref_vn
>   set_vn
>   tree_SPLAY
>   tree_get
>   tree_pop
>   tree_set
>   unref_vn
> 
> To be committed in the next lib bump.
> 
> Thoughts?  ok?

Looks good to me, but I can't judge if you're removing too much, so
maybe you should wait for an ok from helg@ as well.

> Index: Makefile
> ===
> --- Makefile.orig
> +++ Makefile
> @@ -17,6 +17,8 @@ CFLAGS+=-I${.CURDIR}
>  SRCS=debug.c dict.c fuse.c fuse_ops.c fuse_opt.c fuse_subr.c tree.c
>  HDRS=fuse.h fuse_opt.h
>  
> +VERSION_SCRIPT=  ${.CURDIR}/Symbols.map
> +
>  PC_FILES=fuse.pc
>  CLEANFILES+=${PC_FILES}
>  
> Index: Symbols.map
> ===
> --- /dev/null
> +++ Symbols.map
> @@ -0,0 +1,31 @@
> +{
> + global:
> + fuse_chan_fd;
> + fuse_daemonize;
> + fuse_destroy;
> + fuse_get_context;
> + fuse_get_session;
> + fuse_invalidate;
> + fuse_is_lib_option;
> + fuse_loop;
> + fuse_loop_mt;
> + fuse_main;
> + fuse_mount;
> + fuse_new;
> + fuse_opt_add_arg;
> + fuse_opt_add_opt;
> + fuse_opt_add_opt_escaped;
> + fuse_opt_free_args;
> + fuse_opt_insert_arg;
> + fuse_opt_match;
> + fuse_opt_parse;
> + fuse_parse_cmdline;
> + fuse_remove_signal_handlers;
> + fuse_set_signal_handlers;
> + fuse_setup;
> + fuse_teardown;
> + fuse_unmount;
> + fuse_version;
> + local:
> + *;
> +};
> Index: shlib_version
> ===
> --- shlib_version.orig
> +++ shlib_version
> @@ -1,2 +1,2 @@
> -major=1
> -minor=1
> +major=2
> +minor=0
> 
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 
>

Re: sign of char on arm64

2017-12-14 Thread Jeremie Courreges-Anglas 
On Wed, Dec 13 2017, Sebastien Marie  wrote:
> First, thanks to all people that answered, off-list or not.
>
> On Tue, Dec 12, 2017 at 10:01:14PM +0100, Jeremie Courreges-Anglas wrote:
>> On Tue, Dec 12 2017, Sebastien Marie  wrote:
>> 
>> [...]
>> 
>> > But I would like confirmation because for all BSD where I have the
>> > information, I always have a signed char (aarch64-freebsd,
>> > powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
>> >
>> > Is it expected ?
>> 
>> I would certainly not expect NetBSD and FreeBSD to have "char" signed by
>> default.  afaik the powerpc, arm and arm64 ABIs define "char" as
>> unsigned.
>> 
>> FreeBSD documents those architectures as using unsigned char:
>> 
>>   
>> https://www.freebsd.org/cgi/man.cgi?query=arch=0=7=FreeBSD+12-current=default=html
>
> So it means the Rust libc definition for them is currently wrong, as
> 'char' is defined as 'i8' (signed byte) instead of 'u8' (unsigned byte).
> I will report it to FreeBSD people.

Maybe talk with the rust folks too, they probably have made that choice
for Linux on powerpc/arm*.

>> afaik with clang and gcc you can just test whether __CHAR_UNSIGNED__ is
>> defined.
>
> Rust is a wonderfull land where all the standard libc definition has to
> be rewritten by hand (and kept in sync), so I haven't access to such
> compilation variable... 

Have fun. :)

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

Re: sign of char on arm64

2017-12-14 Thread Mark Kettenis 
> From: Jeremie Courreges-Anglas 
> Date: Thu, 14 Dec 2017 12:06:05 +0100
> 
> On Wed, Dec 13 2017, Sebastien Marie  wrote:
> > First, thanks to all people that answered, off-list or not.
> >
> > On Tue, Dec 12, 2017 at 10:01:14PM +0100, Jeremie Courreges-Anglas wrote:
> >> On Tue, Dec 12 2017, Sebastien Marie  wrote:
> >> 
> >> [...]
> >> 
> >> > But I would like confirmation because for all BSD where I have the
> >> > information, I always have a signed char (aarch64-freebsd,
> >> > powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
> >> >
> >> > Is it expected ?
> >> 
> >> I would certainly not expect NetBSD and FreeBSD to have "char" signed by
> >> default.  afaik the powerpc, arm and arm64 ABIs define "char" as
> >> unsigned.
> >> 
> >> FreeBSD documents those architectures as using unsigned char:
> >> 
> >>   
> >> https://www.freebsd.org/cgi/man.cgi?query=arch=0=7=FreeBSD+12-current=default=html
> >
> > So it means the Rust libc definition for them is currently wrong, as
> > 'char' is defined as 'i8' (signed byte) instead of 'u8' (unsigned byte).
> > I will report it to FreeBSD people.
> 
> Maybe talk with the rust folks too, they probably have made that choice
> for Linux on powerpc/arm*.

Pretty sure Linux uses the same defaults for the signedness of char as
everybody else.  But since both signed and unsigned char have to work,
it might very well be that the rust developers decided to ignore this
largely historic inconsistency.  I doubt the performance difference is
significant in any way for modern code.

Cheers,

Mark

Re: sign of char on arm64

2017-12-14 Thread Sebastien Marie 
On Thu, Dec 14, 2017 at 12:17:56PM +0100, Mark Kettenis wrote:
> > >> 
> > >> I would certainly not expect NetBSD and FreeBSD to have "char" signed by
> > >> default.  afaik the powerpc, arm and arm64 ABIs define "char" as
> > >> unsigned.
> > >> 
> > >> FreeBSD documents those architectures as using unsigned char:
> > >> 
> > >>   
> > >> https://www.freebsd.org/cgi/man.cgi?query=arch=0=7=FreeBSD+12-current=default=html
> > >
> > > So it means the Rust libc definition for them is currently wrong, as
> > > 'char' is defined as 'i8' (signed byte) instead of 'u8' (unsigned byte).
> > > I will report it to FreeBSD people.
> > 
> > Maybe talk with the rust folks too, they probably have made that choice
> > for Linux on powerpc/arm*.
> 
> Pretty sure Linux uses the same defaults for the signedness of char as
> everybody else.  But since both signed and unsigned char have to work,
> it might very well be that the rust developers decided to ignore this
> largely historic inconsistency.  I doubt the performance difference is
> significant in any way for modern code.

Just to precise some points about Rust libc code.

If it should be manually maintained, it also have testsuite that
perform all sorts of checks (signedness, size, sturct offset...)

And it is because the testsuite reports to me signedness error (I
initially used 'i8' as all other platforms) that I investigated deeply
if it was expected or not.

The testsuite is automatically tested for each commit (using travis).
But for FreeBSD, only amd64 target is checked (it is done via qemu on
travis). And OpenBSD isn't checked at all.

So for other Linux like powerpc and arm, there are tested (and defined
to unsigned 'u8'). The definition should be right.
-- 
Sebastien Marie

Re: clock_gettime: add CLOCK_BOOTTIME clockid

2017-12-14 Thread Mike Larkin 
On Thu, Dec 14, 2017 at 06:47:02PM -0600, Scott Cheloha wrote:
> Hi,
> 
> Attached is a diff adding a new clockid, CLOCK_BOOTTIME, for use with
> clock_gettime(2).  The value of CLOCK_BOOTTIME is the time elapsed
> since the system booted, i.e. the system uptime.  The diff puts it to
> use in top(1), w(1), and snmpd(8).
> 
> CLOCK_BOOTTIME originated in Linux in the 2.6.39 kernel [1, 2].
> 
> The base motivation for adding CLOCK_BOOTTIME to OpenBSD is that there
> is currently no direct interface for userland to query the system
> uptime, i.e., the time elapsed since the machine was last (re)booted.
> 
> We have several callers using the kern.boottime sysctl, but all of
> them immediately subtract the result from the current time of day to
> derive the system uptime.  This is is (a) cumbersome, and (b) involves
> a race with settimeofday(2), etc.
> 
> We could add a new sysctl, but sysctl(3) itself is cumbersome,
> especially when compared to clock_gettime(2).
> 
> Although CLOCK_MONOTONIC is currently implemented with nanouptime(9)
> and is thus an interface to the system uptime, this is only coincidentally
> so.  The standard notes that the value returned by CLOCK_MONOTONIC is
> meaningless in isolation: it is only portably useful for interval
> measurement.  Overloading CLOCK_MONOTONIC as an interface to the system
> uptime would confuse the purpose of the clock, promote the creation of non-
> portable code, and prevent us from changing the clock's implementation
> in the future.
> 
> On top of enriching base with a nice interface to the system uptime,
> this diff also makes CLOCK_BOOTTIME available to ports with the same
> semantics it has in Linux.  CLOCK_BOOTTIME has been available in Linux
> for over five years, so there are almost certainly ports that can make
> use of it.
> 
> The diff in its current form is the result of discussion and revision
> with guenther@, jca@, and tb@.  All gave their ok.
> 
> Thoughts and feedback?
> 


No objections, you can add me to the ok list...

-ml

> --
> Scott Cheloha
> 
> [1] https://marc.info/?l=linux-kernel=129783004314557=2
> [2] 
> https://github.com/torvalds/linux/commit/420c1c572d4ceaa2f37b6311b7017ac6cf049fe2
> 
> Index: lib/libc/sys/clock_gettime.2
> ===
> RCS file: /cvs/src/lib/libc/sys/clock_gettime.2,v
> retrieving revision 1.27
> diff -u -p -r1.27 clock_gettime.2
> --- lib/libc/sys/clock_gettime.2  10 Sep 2015 17:55:21 -  1.27
> +++ lib/libc/sys/clock_gettime.2  15 Dec 2017 00:43:29 -
> @@ -73,6 +73,9 @@ time that increments as a wall clock sho
>  is meaningless and cannot jump,
>  providing accurate realtime interval measurement,
>  even across suspend and resume
> +.It Dv CLOCK_BOOTTIME
> +time whose absolute value is the time that has elapsed since the
> +system was booted
>  .It Dv CLOCK_UPTIME
>  time whose absolute value is the time the system has been running
>  and not suspended,
> @@ -157,8 +160,10 @@ functions conform to
>  .St -p1003.1-2008 .
>  .Pp
>  The
> +.Dv CLOCK_BOOTTIME
> +and
>  .Dv CLOCK_UPTIME
> -clock is an extension to that.
> +clocks are extensions to that.
>  .Sh HISTORY
>  The
>  .Dv CLOCK_PROCESS_CPUTIME_ID
> @@ -174,3 +179,11 @@ and was added to
>  .Ox
>  in
>  .Ox 5.5 .
> +The
> +.Dv CLOCK_BOOTTIME
> +clock first appeared in
> +Linux 2.6.39
> +and was added to
> +.Ox
> +in
> +.Ox 6.3 .
> Index: sys/kern/kern_time.c
> ===
> RCS file: /cvs/src/sys/kern/kern_time.c,v
> retrieving revision 1.99
> diff -u -p -r1.99 kern_time.c
> --- sys/kern/kern_time.c  24 Jan 2017 00:58:55 -  1.99
> +++ sys/kern/kern_time.c  15 Dec 2017 00:43:29 -
> @@ -124,6 +124,7 @@ clock_gettime(struct proc *p, clockid_t 
>   bintime2timespec(, tp);
>   break;
>   case CLOCK_MONOTONIC:
> + case CLOCK_BOOTTIME:
>   nanouptime(tp);
>   break;
>   case CLOCK_PROCESS_CPUTIME_ID:
> @@ -223,6 +224,7 @@ sys_clock_getres(struct proc *p, void *v
>   switch (clock_id) {
>   case CLOCK_REALTIME:
>   case CLOCK_MONOTONIC:
> + case CLOCK_BOOTTIME:
>   case CLOCK_UPTIME:
>   case CLOCK_PROCESS_CPUTIME_ID:
>   case CLOCK_THREAD_CPUTIME_ID:
> Index: sys/sys/_time.h
> ===
> RCS file: /cvs/src/sys/sys/_time.h,v
> retrieving revision 1.8
> diff -u -p -r1.8 _time.h
> --- sys/sys/_time.h   3 Sep 2016 15:06:06 -   1.8
> +++ sys/sys/_time.h   15 Dec 2017 00:43:29 -
> @@ -37,6 +37,7 @@
>  #define CLOCK_MONOTONIC  3
>  #define CLOCK_THREAD_CPUTIME_ID  4
>  #define CLOCK_UPTIME 5
> +#define CLOCK_BOOTTIME   6
>  
>  #if __BSD_VISIBLE
>  /*
> Index: usr.bin/w/w.c
> ===
> RCS file: /cvs/src/usr.bin/w/w.c,v
> retrieving

Re: clock_gettime: add CLOCK_BOOTTIME clockid

2017-12-14 Thread David Gwynne 

> On 15 Dec 2017, at 10:47, Scott Cheloha  wrote:
> 
> Hi,
> 
> Attached is a diff adding a new clockid, CLOCK_BOOTTIME, for use with
> clock_gettime(2).  The value of CLOCK_BOOTTIME is the time elapsed
> since the system booted, i.e. the system uptime.  The diff puts it to
> use in top(1), w(1), and snmpd(8).
> 
> CLOCK_BOOTTIME originated in Linux in the 2.6.39 kernel [1, 2].
> 
> The base motivation for adding CLOCK_BOOTTIME to OpenBSD is that there
> is currently no direct interface for userland to query the system
> uptime, i.e., the time elapsed since the machine was last (re)booted.
> 
> We have several callers using the kern.boottime sysctl, but all of
> them immediately subtract the result from the current time of day to
> derive the system uptime.  This is is (a) cumbersome, and (b) involves
> a race with settimeofday(2), etc.
> 
> We could add a new sysctl, but sysctl(3) itself is cumbersome,
> especially when compared to clock_gettime(2).
> 
> Although CLOCK_MONOTONIC is currently implemented with nanouptime(9)
> and is thus an interface to the system uptime, this is only coincidentally
> so.  The standard notes that the value returned by CLOCK_MONOTONIC is
> meaningless in isolation: it is only portably useful for interval
> measurement.  Overloading CLOCK_MONOTONIC as an interface to the system
> uptime would confuse the purpose of the clock, promote the creation of non-
> portable code, and prevent us from changing the clock's implementation
> in the future.
> 
> On top of enriching base with a nice interface to the system uptime,
> this diff also makes CLOCK_BOOTTIME available to ports with the same
> semantics it has in Linux.  CLOCK_BOOTTIME has been available in Linux
> for over five years, so there are almost certainly ports that can make
> use of it.
> 
> The diff in its current form is the result of discussion and revision
> with guenther@, jca@, and tb@.  All gave their ok.
> 
> Thoughts and feedback?

i think we should do this, and this is the right way to start.

however, it implies that our CLOCK_MONOTONIC behaviour needs to change. right 
now it represents wall time since boot, but it should be time after boot minus 
how long it has been suspended?

also, i've always wanted to add a random offset on boot to CLOCK_MONOTONIC. 
having CLOCK_BOOTTIME helps justify doing things like that to MONOTONIC.

it has my ok, but you need some more people to say so too.

dlg

> 
> --
> Scott Cheloha
> 
> [1] https://marc.info/?l=linux-kernel=129783004314557=2
> [2] 
> https://github.com/torvalds/linux/commit/420c1c572d4ceaa2f37b6311b7017ac6cf049fe2
> 
> Index: lib/libc/sys/clock_gettime.2
> ===
> RCS file: /cvs/src/lib/libc/sys/clock_gettime.2,v
> retrieving revision 1.27
> diff -u -p -r1.27 clock_gettime.2
> --- lib/libc/sys/clock_gettime.2  10 Sep 2015 17:55:21 -  1.27
> +++ lib/libc/sys/clock_gettime.2  15 Dec 2017 00:43:29 -
> @@ -73,6 +73,9 @@ time that increments as a wall clock sho
> is meaningless and cannot jump,
> providing accurate realtime interval measurement,
> even across suspend and resume
> +.It Dv CLOCK_BOOTTIME
> +time whose absolute value is the time that has elapsed since the
> +system was booted
> .It Dv CLOCK_UPTIME
> time whose absolute value is the time the system has been running
> and not suspended,
> @@ -157,8 +160,10 @@ functions conform to
> .St -p1003.1-2008 .
> .Pp
> The
> +.Dv CLOCK_BOOTTIME
> +and
> .Dv CLOCK_UPTIME
> -clock is an extension to that.
> +clocks are extensions to that.
> .Sh HISTORY
> The
> .Dv CLOCK_PROCESS_CPUTIME_ID
> @@ -174,3 +179,11 @@ and was added to
> .Ox
> in
> .Ox 5.5 .
> +The
> +.Dv CLOCK_BOOTTIME
> +clock first appeared in
> +Linux 2.6.39
> +and was added to
> +.Ox
> +in
> +.Ox 6.3 .
> Index: sys/kern/kern_time.c
> ===
> RCS file: /cvs/src/sys/kern/kern_time.c,v
> retrieving revision 1.99
> diff -u -p -r1.99 kern_time.c
> --- sys/kern/kern_time.c  24 Jan 2017 00:58:55 -  1.99
> +++ sys/kern/kern_time.c  15 Dec 2017 00:43:29 -
> @@ -124,6 +124,7 @@ clock_gettime(struct proc *p, clockid_t 
>   bintime2timespec(, tp);
>   break;
>   case CLOCK_MONOTONIC:
> + case CLOCK_BOOTTIME:
>   nanouptime(tp);
>   break;
>   case CLOCK_PROCESS_CPUTIME_ID:
> @@ -223,6 +224,7 @@ sys_clock_getres(struct proc *p, void *v
>   switch (clock_id) {
>   case CLOCK_REALTIME:
>   case CLOCK_MONOTONIC:
> + case CLOCK_BOOTTIME:
>   case CLOCK_UPTIME:
>   case CLOCK_PROCESS_CPUTIME_ID:
>   case CLOCK_THREAD_CPUTIME_ID:
> Index: sys/sys/_time.h
> ===
> RCS file: /cvs/src/sys/sys/_time.h,v
> retrieving revision 1.8
> diff -u -p -r1.8 _time.h
> --- sys/sys/_time.h   3 Sep 2016 15:06:06 -   1.8
> +++ sys/sys/_time.h

Re: clock_gettime: add CLOCK_BOOTTIME clockid

2017-12-14 Thread Philip Guenther 
On Thu, Dec 14, 2017 at 6:33 PM, David Gwynne  wrote:
...

> however, it implies that our CLOCK_MONOTONIC behaviour needs to change.
> right now it represents wall time since boot, but it should be time after
> boot minus how long it has been suspended?
>

Nope.  To quote clock_gettime(3)
 CLOCK_UPTIME time whose absolute value is the time the system has
  been running and not suspended, providing accurate
  uptime measurement, both absolute and interval


Philip Guenther

Re: w: don't print any header with -h

2017-12-14 Thread Jasper Lievisse Adriaanse 
On Thu, Dec 14, 2017 at 01:35:18PM +0100, Martijn van Duren wrote:
> Hello Jasper,
> 
> On 12/14/17 13:22, Jasper Lievisse Adriaanse wrote:
> > Hi,
> > 
> > currently w(1) on OpenBSD differs from other implementations
> > (GNU/Darwin/FreeBSD/SmartOS) in that 'w -h' does print the
> > 'USER TTY FROM ...' header whereas the others don't.
> > 
> > Is there a specific reason for it or could this diff below go in?
> 
> I don't know about the history to tell you, and I don't particularly
> care about this change either way.
> 
> Do note that our uptime(1) says:
> This is the ???heading??? information from w(1).
> 
> This has been removed from the FreeBSD uptime manpage.
> So if we want to do the same thing, you should also adjust uptime.1.
That still _is_ the heading information from w(1) when ran without flags so I
don't think uptime.1 needs any changes.
 
> > Index: w.c
> > ===
> > RCS file: /cvs/src/usr.bin/w/w.c,v
> > retrieving revision 1.63
> > diff -u -p -r1.63 w.c
> > --- w.c 27 Jul 2017 14:17:34 -  1.63
> > +++ w.c 14 Dec 2017 12:19:34 -
> > @@ -224,7 +224,8 @@ main(int argc, char *argv[])
> >  
> >  #define HEADER "USERTTY FROM  LOGIN@  IDLE WHAT"
> >  #define WUSED  (sizeof(HEADER) - sizeof("WHAT"))
> > -   (void)puts(HEADER);
> > +   if (header)
> > +   (void)puts(HEADER);
> >  
> > kp = kvm_getprocs(kd, KERN_PROC_ALL, 0, sizeof(*kp), );
> > if (kp == NULL)
> > 
> 

-- 
jasper

Re: w: don't print any header with -h

2017-12-14 Thread Martijn van Duren 
On 12/14/17 13:56, Jasper Lievisse Adriaanse wrote:
> On Thu, Dec 14, 2017 at 01:35:18PM +0100, Martijn van Duren wrote:
>> Hello Jasper,
>>
>> On 12/14/17 13:22, Jasper Lievisse Adriaanse wrote:
>>> Hi,
>>>
>>> currently w(1) on OpenBSD differs from other implementations
>>> (GNU/Darwin/FreeBSD/SmartOS) in that 'w -h' does print the
>>> 'USER TTY FROM ...' header whereas the others don't.
>>>
>>> Is there a specific reason for it or could this diff below go in?
>>
>> I don't know about the history to tell you, and I don't particularly
>> care about this change either way.
>>
>> Do note that our uptime(1) says:
>> This is the ???heading??? information from w(1).
>>
>> This has been removed from the FreeBSD uptime manpage.
>> So if we want to do the same thing, you should also adjust uptime.1.
> That still _is_ the heading information from w(1) when ran without flags so I
> don't think uptime.1 needs any changes.

w(1) -h says: "suppress the heading" and uptime(1) says that the uptime
is *the* heading. So with your patch we either remove more than the
heading, or uptime becomes only part of the heading.

Either way it creates an inconsistency.
>  
>>> Index: w.c
>>> ===
>>> RCS file: /cvs/src/usr.bin/w/w.c,v
>>> retrieving revision 1.63
>>> diff -u -p -r1.63 w.c
>>> --- w.c 27 Jul 2017 14:17:34 -  1.63
>>> +++ w.c 14 Dec 2017 12:19:34 -
>>> @@ -224,7 +224,8 @@ main(int argc, char *argv[])
>>>  
>>>  #define HEADER "USERTTY FROM  LOGIN@  IDLE WHAT"
>>>  #define WUSED  (sizeof(HEADER) - sizeof("WHAT"))
>>> -   (void)puts(HEADER);
>>> +   if (header)
>>> +   (void)puts(HEADER);
>>>  
>>> kp = kvm_getprocs(kd, KERN_PROC_ALL, 0, sizeof(*kp), );
>>> if (kp == NULL)
>>>
>>
>

clock_gettime: add CLOCK_BOOTTIME clockid

2017-12-14 Thread Scott Cheloha 
Hi,

Attached is a diff adding a new clockid, CLOCK_BOOTTIME, for use with
clock_gettime(2).  The value of CLOCK_BOOTTIME is the time elapsed
since the system booted, i.e. the system uptime.  The diff puts it to
use in top(1), w(1), and snmpd(8).

CLOCK_BOOTTIME originated in Linux in the 2.6.39 kernel [1, 2].

The base motivation for adding CLOCK_BOOTTIME to OpenBSD is that there
is currently no direct interface for userland to query the system
uptime, i.e., the time elapsed since the machine was last (re)booted.

We have several callers using the kern.boottime sysctl, but all of
them immediately subtract the result from the current time of day to
derive the system uptime.  This is is (a) cumbersome, and (b) involves
a race with settimeofday(2), etc.

We could add a new sysctl, but sysctl(3) itself is cumbersome,
especially when compared to clock_gettime(2).

Although CLOCK_MONOTONIC is currently implemented with nanouptime(9)
and is thus an interface to the system uptime, this is only coincidentally
so.  The standard notes that the value returned by CLOCK_MONOTONIC is
meaningless in isolation: it is only portably useful for interval
measurement.  Overloading CLOCK_MONOTONIC as an interface to the system
uptime would confuse the purpose of the clock, promote the creation of non-
portable code, and prevent us from changing the clock's implementation
in the future.

On top of enriching base with a nice interface to the system uptime,
this diff also makes CLOCK_BOOTTIME available to ports with the same
semantics it has in Linux.  CLOCK_BOOTTIME has been available in Linux
for over five years, so there are almost certainly ports that can make
use of it.

The diff in its current form is the result of discussion and revision
with guenther@, jca@, and tb@.  All gave their ok.

Thoughts and feedback?

--
Scott Cheloha

[1] https://marc.info/?l=linux-kernel=129783004314557=2
[2] 
https://github.com/torvalds/linux/commit/420c1c572d4ceaa2f37b6311b7017ac6cf049fe2

Index: lib/libc/sys/clock_gettime.2
===
RCS file: /cvs/src/lib/libc/sys/clock_gettime.2,v
retrieving revision 1.27
diff -u -p -r1.27 clock_gettime.2
--- lib/libc/sys/clock_gettime.210 Sep 2015 17:55:21 -  1.27
+++ lib/libc/sys/clock_gettime.215 Dec 2017 00:43:29 -
@@ -73,6 +73,9 @@ time that increments as a wall clock sho
 is meaningless and cannot jump,
 providing accurate realtime interval measurement,
 even across suspend and resume
+.It Dv CLOCK_BOOTTIME
+time whose absolute value is the time that has elapsed since the
+system was booted
 .It Dv CLOCK_UPTIME
 time whose absolute value is the time the system has been running
 and not suspended,
@@ -157,8 +160,10 @@ functions conform to
 .St -p1003.1-2008 .
 .Pp
 The
+.Dv CLOCK_BOOTTIME
+and
 .Dv CLOCK_UPTIME
-clock is an extension to that.
+clocks are extensions to that.
 .Sh HISTORY
 The
 .Dv CLOCK_PROCESS_CPUTIME_ID
@@ -174,3 +179,11 @@ and was added to
 .Ox
 in
 .Ox 5.5 .
+The
+.Dv CLOCK_BOOTTIME
+clock first appeared in
+Linux 2.6.39
+and was added to
+.Ox
+in
+.Ox 6.3 .
Index: sys/kern/kern_time.c
===
RCS file: /cvs/src/sys/kern/kern_time.c,v
retrieving revision 1.99
diff -u -p -r1.99 kern_time.c
--- sys/kern/kern_time.c24 Jan 2017 00:58:55 -  1.99
+++ sys/kern/kern_time.c15 Dec 2017 00:43:29 -
@@ -124,6 +124,7 @@ clock_gettime(struct proc *p, clockid_t 
bintime2timespec(, tp);
break;
case CLOCK_MONOTONIC:
+   case CLOCK_BOOTTIME:
nanouptime(tp);
break;
case CLOCK_PROCESS_CPUTIME_ID:
@@ -223,6 +224,7 @@ sys_clock_getres(struct proc *p, void *v
switch (clock_id) {
case CLOCK_REALTIME:
case CLOCK_MONOTONIC:
+   case CLOCK_BOOTTIME:
case CLOCK_UPTIME:
case CLOCK_PROCESS_CPUTIME_ID:
case CLOCK_THREAD_CPUTIME_ID:
Index: sys/sys/_time.h
===
RCS file: /cvs/src/sys/sys/_time.h,v
retrieving revision 1.8
diff -u -p -r1.8 _time.h
--- sys/sys/_time.h 3 Sep 2016 15:06:06 -   1.8
+++ sys/sys/_time.h 15 Dec 2017 00:43:29 -
@@ -37,6 +37,7 @@
 #define CLOCK_MONOTONIC3
 #define CLOCK_THREAD_CPUTIME_ID4
 #define CLOCK_UPTIME   5
+#define CLOCK_BOOTTIME 6
 
 #if __BSD_VISIBLE
 /*
Index: usr.bin/w/w.c
===
RCS file: /cvs/src/usr.bin/w/w.c,v
retrieving revision 1.64
diff -u -p -r1.64 w.c
--- usr.bin/w/w.c   14 Dec 2017 18:03:03 -  1.64
+++ usr.bin/w/w.c   15 Dec 2017 00:43:29 -
@@ -66,7 +66,6 @@
 
 #include "extern.h"
 
-struct timeval boottime;
 struct utmputmp;
 struct winsize ws;
 kvm_t *kd;
@@ -426,10 +425,9 @@ static void
 pr_header(time_t *nowp, int

Symbols.map for libfuse

2017-12-14 Thread Jeremie Courreges-Anglas 

When reviewing helg@'s last diff I noticed a bunch of stuff that
shouldn't be exported.  So here's a diff similar to the recent
diffs for libutil and libkvm.  To get the list of public symbols I used
symbol visibility.

The diff below only reduces the symbols list, it does not remove PLT
entries for internal calls, as I don't feel confident using this
machinery.  AFAIK this can be done in a subsequent step with no bump.

check_sym output:
/usr/lib/libfuse.so.1.1 --> obj/libfuse.so.2.0
Dynamic export changes:
removed:
__bss_start
__data_start
_edata
_end
_fini
_init
alloc_vn
build_realname
dict_SPLAY
dict_SPLAY_INSERT
dict_SPLAY_MINMAX
dict_SPLAY_REMOVE
dict_check
dict_get
dict_pop
dict_set
get_vn_by_name_and_parent
ifuse_debug
ifuse_debug_init
ifuse_exec_opcode
ref_vn
remove_vnode_from_name_tree
set_vn
tree_SPLAY
tree_SPLAY_INSERT
tree_SPLAY_MINMAX
tree_SPLAY_REMOVE
tree_check
tree_get
tree_pop
tree_set
unref_vn

PLT removed:
alloc_vn
build_realname
dict_SPLAY
dict_check
dict_get
dict_pop
dict_set
get_vn_by_name_and_parent
ifuse_debug_init
ifuse_exec_opcode
ref_vn
set_vn
tree_SPLAY
tree_get
tree_pop
tree_set
unref_vn

To be committed in the next lib bump.

Thoughts?  ok?


Index: Makefile
===
--- Makefile.orig
+++ Makefile
@@ -17,6 +17,8 @@ CFLAGS+=  -I${.CURDIR}
 SRCS=  debug.c dict.c fuse.c fuse_ops.c fuse_opt.c fuse_subr.c tree.c
 HDRS=  fuse.h fuse_opt.h
 
+VERSION_SCRIPT=${.CURDIR}/Symbols.map
+
 PC_FILES=fuse.pc
 CLEANFILES+=${PC_FILES}
 
Index: Symbols.map
===
--- /dev/null
+++ Symbols.map
@@ -0,0 +1,31 @@
+{
+   global:
+   fuse_chan_fd;
+   fuse_daemonize;
+   fuse_destroy;
+   fuse_get_context;
+   fuse_get_session;
+   fuse_invalidate;
+   fuse_is_lib_option;
+   fuse_loop;
+   fuse_loop_mt;
+   fuse_main;
+   fuse_mount;
+   fuse_new;
+   fuse_opt_add_arg;
+   fuse_opt_add_opt;
+   fuse_opt_add_opt_escaped;
+   fuse_opt_free_args;
+   fuse_opt_insert_arg;
+   fuse_opt_match;
+   fuse_opt_parse;
+   fuse_parse_cmdline;
+   fuse_remove_signal_handlers;
+   fuse_set_signal_handlers;
+   fuse_setup;
+   fuse_teardown;
+   fuse_unmount;
+   fuse_version;
+   local:
+   *;
+};
Index: shlib_version
===
--- shlib_version.orig
+++ shlib_version
@@ -1,2 +1,2 @@
-major=1
-minor=1
+major=2
+minor=0


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

Re: Add "-c command" option to script(1)

2017-12-14 Thread Jason McIntyre 
On Thu, Dec 14, 2017 at 09:23:29AM +0100, Paul de Weerd wrote:
> Another use I personally find very convenient is this:
> 
> [weerd@pom] $ script -c "vmctl start test -c"
> 
> Hope others see value here too :)
> 
> Paul
> 

you could add this as an EXAMPLES section, since it nicely describes
another way to use script(1).

jmc

Re: Symbols.map for libkvm

2017-12-14 Thread Mark Kettenis 
> Date: Wed, 13 Dec 2017 23:05:24 -0800
> From: Philip Guenther 
> 
> Inspired by kettenis@'s diff for libutil, here's a diff to do the 
> (simpler) work for libkvm,
> 
> The symbols this hides are just the linker defined ones; we've already 
> declared the internal C symbols static or at least hidden.  However, while 
> here I've added the dance to have the three internally referenced symbols 
> be called direct, eliminating the PLT entries.  Here's the check_syms 
> output:
> 
> : corwin; ../check_sym
> /usr/lib/libkvm.so.16.2 --> obj/libkvm.so.17.0
> Dynamic export changes:
> removed:
> __bss_start
> __data_start
> _edata
> _end
> _fini
> _init
> 
> PLT removed:
> kvm_close
> kvm_nlist
> kvm_read
> 
> : corwin;
> 
> ok?

ok kettenis@

> Index: lib/libkvm/Makefile
> ===
> RCS file: /cvs/src/lib/libkvm/Makefile,v
> retrieving revision 1.18
> diff -u -p -r1.18 Makefile
> --- lib/libkvm/Makefile   30 Mar 2016 06:38:42 -  1.18
> +++ lib/libkvm/Makefile   14 Dec 2017 07:02:18 -
> @@ -18,6 +18,8 @@ SRCS=   kvm_${MACHINE_CPU}.c
>  .endif
>  .endif
>  
> +VERSION_SCRIPT=  ${.CURDIR}/Symbols.map
> +
>  CFLAGS+= -D_LIBKVM
>  SRCS+=   kvm.c kvm_file2.c kvm_getloadavg.c kvm_proc.c kvm_proc2.c \
>   kvm_cd9660.c kvm_udf.c kvm_ntfs.c
> Index: lib/libkvm/Symbols.map
> ===
> RCS file: lib/libkvm/Symbols.map
> diff -N lib/libkvm/Symbols.map
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ lib/libkvm/Symbols.map14 Dec 2017 07:02:18 -
> @@ -0,0 +1,21 @@
> +{
> + global:
> + kvm_close;
> + kvm_dump_inval;
> + kvm_dump_mkheader;
> + kvm_dump_wrtheader;
> + kvm_getargv;
> + kvm_getenvv;
> + kvm_geterr;
> + kvm_getfiles;
> + kvm_getloadavg;
> + kvm_getprocs;
> + kvm_nlist;
> + kvm_open;
> + kvm_openfiles;
> + kvm_read;
> + kvm_write;
> +
> + local:
> + *;
> +};
> Index: lib/libkvm/kvm.c
> ===
> RCS file: /cvs/src/lib/libkvm/kvm.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 kvm.c
> --- lib/libkvm/kvm.c  10 Jul 2016 23:06:48 -  1.62
> +++ lib/libkvm/kvm.c  14 Dec 2017 07:02:18 -
> @@ -664,6 +664,7 @@ kvm_close(kvm_t *kd)
>  
>   return (error);
>  }
> +DEF(kvm_close);
>  
>  /*
>   * Set up state necessary to do queries on the kernel namelist
> @@ -802,6 +803,7 @@ kvm_nlist(kvm_t *kd, struct nlist *nl)
>*/
>   return ((p - nl) - nvalid);
>  }
> +DEF(kvm_nlist);
>  
>  int
>  kvm_dump_inval(kvm_t *kd)
> @@ -894,6 +896,7 @@ kvm_read(kvm_t *kd, u_long kva, void *bu
>   }
>   /* NOTREACHED */
>  }
> +DEF(kvm_read);
>  
>  ssize_t
>  kvm_write(kvm_t *kd, u_long kva, const void *buf, size_t len)
> Index: lib/libkvm/kvm_private.h
> ===
> RCS file: /cvs/src/lib/libkvm/kvm_private.h,v
> retrieving revision 1.24
> diff -u -p -r1.24 kvm_private.h
> --- lib/libkvm/kvm_private.h  4 Sep 2015 02:55:09 -   1.24
> +++ lib/libkvm/kvm_private.h  14 Dec 2017 07:02:18 -
> @@ -106,3 +106,11 @@ void  _kvm_syserr(kvm_t *kd, const char 
>  ssize_t   _kvm_pread(kvm_t *, int, void *, size_t, off_t);
>  ssize_t   _kvm_pwrite(kvm_t *, int, const void *, size_t, off_t);
>  __END_HIDDEN_DECLS
> +
> +
> +#define  PROTO(x)__dso_hidden typeof(x) x asm("__"#x)
> +#define  DEF(x)  __strong_alias(x, __##x)
> +
> +PROTO(kvm_close);
> +PROTO(kvm_nlist);
> +PROTO(kvm_read);
> Index: lib/libkvm/shlib_version
> ===
> RCS file: /data/src/openbsd/src/lib/libkvm/shlib_version,v
> retrieving revision 1.19
> diff -u -p -r1.19 shlib_version
> --- lib/libkvm/shlib_version  2 Oct 2016 23:11:55 -   1.19
> +++ lib/libkvm/shlib_version  14 Dec 2017 07:00:46 -
> @@ -1,2 +1,2 @@
> -major=16
> -minor=2
> +major=17
> +minor=0
> 
>

Re: Symbols.map for libkvm

2017-12-14 Thread Jeremie Courreges-Anglas 
On Wed, Dec 13 2017, Philip Guenther  wrote:
> Inspired by kettenis@'s diff for libutil, here's a diff to do the 
> (simpler) work for libkvm,
>
> The symbols this hides are just the linker defined ones; we've already 
> declared the internal C symbols static or at least hidden.  However, while 
> here I've added the dance to have the three internally referenced symbols 
> be called direct, eliminating the PLT entries.  Here's the check_syms 
> output:
>
> : corwin; ../check_sym
> /usr/lib/libkvm.so.16.2 --> obj/libkvm.so.17.0
> Dynamic export changes:
> removed:
> __bss_start
> __data_start
> _edata
> _end
> _fini
> _init
>
> PLT removed:
> kvm_close
> kvm_nlist
> kvm_read
>
> : corwin;
>
> ok?

ok jca@

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

Re: Add reset option to boot command of ddb(4)

2017-12-14 Thread Martin Pieuchot 
On 13/12/17(Wed) 19:09, Florian Riehm wrote:
> Hi,
> 
> This patch follows bluhm's attempt for a ddb command 'boot reset'.
> My first attempt was not architecture aware.
> 
> Tested on i386 by bluhm@ and on amd64 by me.

I don't understand why we need to add "boot reset"?  To not fix ddb(4)
and keep a broken "boot reboot"?  If we cannot fix our own code...

> Index: share/man/man4/ddb.4
> ===
> RCS file: /openbsd/src/share/man/man4/ddb.4,v
> retrieving revision 1.92
> diff -u -p -r1.92 ddb.4
> --- share/man/man4/ddb.4  29 Nov 2017 07:28:21 -  1.92
> +++ share/man/man4/ddb.4  12 Dec 2017 06:35:44 -
> @@ -381,6 +381,15 @@ Just halt.
>  Just reboot.
>  .It Ic boot poweroff
>  Power down the machine whenever possible; if it fails, just halt.
> +.It Ic boot reset
> +Restart the machine by resetting the CPU on i386 and amd64
> +architectures.
> +Useful in situations were
> +.Ic boot reboot
> +does not work anymore, i.e. due to locking issues.
> +On other platforms it is equivalent to the
> +.Ic boot reboot
> +command.
>  .El
>  .\" 
>  .It Xo
> Index: sys/arch/amd64/amd64/machdep.c
> ===
> RCS file: /openbsd/src/sys/arch/amd64/amd64/machdep.c,v
> retrieving revision 1.236
> diff -u -p -r1.236 machdep.c
> --- sys/arch/amd64/amd64/machdep.c11 Dec 2017 05:27:40 -  1.236
> +++ sys/arch/amd64/amd64/machdep.c12 Dec 2017 06:35:44 -
> @@ -713,6 +713,9 @@ struct pcb dumppcb;
>  __dead void
>  boot(int howto)
>  {
> + if ((howto & RB_RESET) != 0)
> + goto reset;
> +
>   if ((howto & RB_POWERDOWN) != 0)
>   lid_action = 0;
>  
> @@ -770,6 +773,7 @@ haltsys:
>   printf("rebooting...\n");
>   if (cpureset_delay > 0)
>   delay(cpureset_delay * 1000);
> +reset:
>   cpu_reset();
>   for (;;)
>   continue;
> Index: sys/arch/i386/i386/machdep.c
> ===
> RCS file: /openbsd/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.607
> diff -u -p -r1.607 machdep.c
> --- sys/arch/i386/i386/machdep.c  11 Dec 2017 05:27:40 -  1.607
> +++ sys/arch/i386/i386/machdep.c  12 Dec 2017 06:35:44 -
> @@ -2629,6 +2629,9 @@ struct pcb dumppcb;
>  __dead void
>  boot(int howto)
>  {
> + if ((howto & RB_RESET) != 0)
> + goto reset;
> +
>   if ((howto & RB_POWERDOWN) != 0)
>   lid_action = 0;
>  
> @@ -2709,6 +2712,7 @@ haltsys:
>   }
>  
>   printf("rebooting...\n");
> +reset:
>   cpu_reset();
>   for (;;)
>   continue;
> Index: sys/ddb/db_command.c
> ===
> RCS file: /openbsd/src/sys/ddb/db_command.c,v
> retrieving revision 1.81
> diff -u -p -r1.81 db_command.c
> --- sys/ddb/db_command.c  11 Dec 2017 05:27:40 -  1.81
> +++ sys/ddb/db_command.c  12 Dec 2017 06:35:44 -
> @@ -105,6 +105,7 @@ void  db_boot_dump_cmd(db_expr_t, int, db
>  void db_boot_halt_cmd(db_expr_t, int, db_expr_t, char *);
>  void db_boot_reboot_cmd(db_expr_t, int, db_expr_t, char *);
>  void db_boot_poweroff_cmd(db_expr_t, int, db_expr_t, char *);
> +void db_boot_reset_cmd(db_expr_t, int, db_expr_t, char *);
>  void db_stack_trace_cmd(db_expr_t, int, db_expr_t, char *);
>  void db_dmesg_cmd(db_expr_t, int, db_expr_t, char *);
>  void db_show_panic_cmd(db_expr_t, int, db_expr_t, char *);
> @@ -597,6 +598,7 @@ struct db_command db_boot_cmds[] = {
>   { "halt",   db_boot_halt_cmd,   0,  0 },
>   { "reboot", db_boot_reboot_cmd, 0,  0 },
>   { "poweroff",   db_boot_poweroff_cmd,   0,  0 },
> + { "reset",  db_boot_reset_cmd,  0,  0 },
>   { NULL, }
>  };
>  
> @@ -812,6 +814,12 @@ void
>  db_boot_poweroff_cmd(db_expr_t addr, int haddr, db_expr_t count, char *modif)
>  {
>   db_reboot(RB_NOSYNC | RB_HALT | RB_POWERDOWN | RB_TIMEBAD | RB_USERREQ);
> +}
> +
> +void
> +db_boot_reset_cmd(db_expr_t addr, int haddr, db_expr_t count, char *modif)
> +{
> + db_reboot(RB_RESET | RB_AUTOBOOT | RB_NOSYNC | RB_TIMEBAD | RB_USERREQ);
>  }
>  
>  void
> Index: sys/sys/reboot.h
> ===
> RCS file: /openbsd/src/sys/sys/reboot.h,v
> retrieving revision 1.17
> diff -u -p -r1.17 reboot.h
> --- sys/sys/reboot.h  11 Jul 2014 14:36:44 -  1.17
> +++ sys/sys/reboot.h  12 Dec 2017 06:35:45 -
> @@ -56,6 +56,7 @@
>  #define  RB_POWERDOWN0x1000  /* attempt to power down machine */
>  #define  RB_SERCONS  0x2000  /* use serial console if available */
>  #define  RB_USERREQ  0x4000  /* boot() called at user request (e.g. 
> ddb) */
> +#define  RB_RESET0x8000  /* do not try to cleanup, only for ddb 
> */
>  
>  /*
>   * Constants for converting boot-style

Re: Add "-c command" option to script(1)

2017-12-14 Thread Paul de Weerd 
Another use I personally find very convenient is this:

[weerd@pom] $ script -c "vmctl start test -c"

Hope others see value here too :)

Paul

On Thu, Dec 14, 2017 at 08:45:19AM +0100, Paul de Weerd wrote:
| Hi Jason,
| 
| Thank you for your quick feedback!  I've incorporated yours and
| off-list feedback from ian@ into a new diff included below.  The diff
| now also includes the removal of /* ARGSUSED */ lint comments.
| 
| On Wed, Dec 13, 2017 at 09:34:03PM +, Jason McIntyre wrote:
| | > +To run a
| | 
| | i'd remove "a", but it's preference only - your choice.
| | 
| | > +.Ar command
| | > +with its own arguments, enclose it in quotes.
| | 
| | and s/its own//
| 
| Rewrote this sentence a bit, it now reads:
| 
| -c command
| Run command instead of an interactive shell.  To run a command
| with arguments, enclose both in quotes.
| 
| Still not 100% happy with it, but the best I could come up with.
| Better suggestions wanted :)
| 
| Paul
| 
| Index: script.1
| ===
| RCS file: /cvs/src/usr.bin/script/script.1,v
| retrieving revision 1.14
| diff -u -p -r1.14 script.1
| --- script.1  15 Jan 2012 20:06:40 -  1.14
| +++ script.1  14 Dec 2017 07:36:11 -
| @@ -39,6 +39,7 @@
|  .Sh SYNOPSIS
|  .Nm script
|  .Op Fl a
| +.Op Fl c Ar command
|  .Op Ar file
|  .Sh DESCRIPTION
|  .Nm
| @@ -65,9 +66,14 @@ Append the output to
|  or
|  .Pa typescript ,
|  retaining the prior contents.
| +.It Fl c Ar command
| +Run
| +.Ar command
| +instead of an interactive shell.
| +To run a command with arguments, enclose both in quotes.
|  .El
|  .Pp
| -The script ends when the forked shell exits (a control-D
| +The script ends when the forked program exits (a control-D
|  .Pq Ql ^D
|  to exit
|  the Bourne shell
| Index: script.c
| ===
| RCS file: /cvs/src/usr.bin/script/script.c,v
| retrieving revision 1.33
| diff -u -p -r1.33 script.c
| --- script.c  12 Apr 2017 14:49:05 -  1.33
| +++ script.c  14 Dec 2017 07:34:10 -
| @@ -89,7 +89,7 @@ int istty;
|  
|  __dead void done(int);
|  void dooutput(void);
| -void doshell(void);
| +void doshell(char *);
|  void fail(void);
|  void finish(int);
|  void scriptflush(int);
| @@ -102,17 +102,23 @@ main(int argc, char *argv[])
|   struct sigaction sa;
|   struct winsize win;
|   char ibuf[BUFSIZ];
| + char *cmd;
|   ssize_t cc, off;
|   int aflg, ch;
|  
| + cmd = NULL;
|   aflg = 0;
| - while ((ch = getopt(argc, argv, "a")) != -1)
| + while ((ch = getopt(argc, argv, "ac:")) != -1)
|   switch(ch) {
|   case 'a':
|   aflg = 1;
|   break;
| + case 'c':
| + cmd = optarg;
| + break;
|   default:
| - fprintf(stderr, "usage: %s [-a] [file]\n", __progname);
| + fprintf(stderr, "usage: %s [-a] [-c command] [file]\n",
| + __progname);
|   exit(1);
|   }
|   argc -= optind;
| @@ -163,7 +169,7 @@ main(int argc, char *argv[])
|   if (child)
|   dooutput();
|   else
| - doshell();
| + doshell(cmd);
|   }
|  
|   bzero(, sizeof sa);
| @@ -196,7 +202,6 @@ main(int argc, char *argv[])
|   done(sigdeadstatus);
|  }
|  
| -/* ARGSUSED */
|  void
|  finish(int signo)
|  {
| @@ -215,7 +220,6 @@ finish(int signo)
|   errno = save_errno;
|  }
|  
| -/* ARGSUSED */
|  void
|  handlesigwinch(int signo)
|  {
| @@ -294,7 +298,6 @@ dooutput(void)
|   done(0);
|  }
|  
| -/* ARGSUSED */
|  void
|  scriptflush(int signo)
|  {
| @@ -302,9 +305,10 @@ scriptflush(int signo)
|  }
|  
|  void
| -doshell(void)
| +doshell(char *cmd)
|  {
|   char *shell;
| + char *argp[] = {"sh", "-c", NULL, NULL};
|  
|   shell = getenv("SHELL");
|   if (shell == NULL)
| @@ -313,8 +317,15 @@ doshell(void)
|   (void)close(master);
|   (void)fclose(fscript);
|   login_tty(slave);
| - execl(shell, shell, "-i", (char *)NULL);
| - warn("%s", shell);
| +
| + if (cmd != NULL) {
| + argp[2] = cmd;
| + execv(_PATH_BSHELL, argp);
| + warn("unable to execute %s", _PATH_BSHELL);
| + } else {
| + execl(shell, shell, "-i", (char *)NULL);
| + warn("%s", shell);
| + }
|   fail();
|  }
| 
|  
| -- 
| >[<++>-]<+++.>+++[<-->-]<.>+++[<+
| +++>-]<.>++[<>-]<+.--.[-]
|  http://www.weirdnet.nl/ 
| 

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/

Re: Add reset option to boot command of ddb(4)

2017-12-14 Thread Mark Kettenis 
> X-Originating-IP: 88.153.7.170
> Date: Thu, 14 Dec 2017 10:30:21 +0100
> From: Martin Pieuchot 
> 
> On 13/12/17(Wed) 19:09, Florian Riehm wrote:
> > Hi,
> > 
> > This patch follows bluhm's attempt for a ddb command 'boot reset'.
> > My first attempt was not architecture aware.
> > 
> > Tested on i386 by bluhm@ and on amd64 by me.
> 
> I don't understand why we need to add "boot reset"?  To not fix ddb(4)
> and keep a broken "boot reboot"?  If we cannot fix our own code...

Funny you say that given the discussion about if_downall() on icb ;).

IIRC "boot reset" is all about avoiding the if_downall() call.  And we
really don't want to skip if_downall() in the "boot reboot".  We added
that call since not stopping the DMA engines of the network cards had
some very interesting effects when the machine rebooted...

> > Index: share/man/man4/ddb.4
> > ===
> > RCS file: /openbsd/src/share/man/man4/ddb.4,v
> > retrieving revision 1.92
> > diff -u -p -r1.92 ddb.4
> > --- share/man/man4/ddb.429 Nov 2017 07:28:21 -  1.92
> > +++ share/man/man4/ddb.412 Dec 2017 06:35:44 -
> > @@ -381,6 +381,15 @@ Just halt.
> >  Just reboot.
> >  .It Ic boot poweroff
> >  Power down the machine whenever possible; if it fails, just halt.
> > +.It Ic boot reset
> > +Restart the machine by resetting the CPU on i386 and amd64
> > +architectures.
> > +Useful in situations were
> > +.Ic boot reboot
> > +does not work anymore, i.e. due to locking issues.
> > +On other platforms it is equivalent to the
> > +.Ic boot reboot
> > +command.
> >  .El
> >  .\" 
> >  .It Xo
> > Index: sys/arch/amd64/amd64/machdep.c
> > ===
> > RCS file: /openbsd/src/sys/arch/amd64/amd64/machdep.c,v
> > retrieving revision 1.236
> > diff -u -p -r1.236 machdep.c
> > --- sys/arch/amd64/amd64/machdep.c  11 Dec 2017 05:27:40 -  1.236
> > +++ sys/arch/amd64/amd64/machdep.c  12 Dec 2017 06:35:44 -
> > @@ -713,6 +713,9 @@ struct pcb dumppcb;
> >  __dead void
> >  boot(int howto)
> >  {
> > +   if ((howto & RB_RESET) != 0)
> > +   goto reset;
> > +
> > if ((howto & RB_POWERDOWN) != 0)
> > lid_action = 0;
> >  
> > @@ -770,6 +773,7 @@ haltsys:
> > printf("rebooting...\n");
> > if (cpureset_delay > 0)
> > delay(cpureset_delay * 1000);
> > +reset:
> > cpu_reset();
> > for (;;)
> > continue;
> > Index: sys/arch/i386/i386/machdep.c
> > ===
> > RCS file: /openbsd/src/sys/arch/i386/i386/machdep.c,v
> > retrieving revision 1.607
> > diff -u -p -r1.607 machdep.c
> > --- sys/arch/i386/i386/machdep.c11 Dec 2017 05:27:40 -  1.607
> > +++ sys/arch/i386/i386/machdep.c12 Dec 2017 06:35:44 -
> > @@ -2629,6 +2629,9 @@ struct pcb dumppcb;
> >  __dead void
> >  boot(int howto)
> >  {
> > +   if ((howto & RB_RESET) != 0)
> > +   goto reset;
> > +
> > if ((howto & RB_POWERDOWN) != 0)
> > lid_action = 0;
> >  
> > @@ -2709,6 +2712,7 @@ haltsys:
> > }
> >  
> > printf("rebooting...\n");
> > +reset:
> > cpu_reset();
> > for (;;)
> > continue;
> > Index: sys/ddb/db_command.c
> > ===
> > RCS file: /openbsd/src/sys/ddb/db_command.c,v
> > retrieving revision 1.81
> > diff -u -p -r1.81 db_command.c
> > --- sys/ddb/db_command.c11 Dec 2017 05:27:40 -  1.81
> > +++ sys/ddb/db_command.c12 Dec 2017 06:35:44 -
> > @@ -105,6 +105,7 @@ voiddb_boot_dump_cmd(db_expr_t, int, db
> >  void   db_boot_halt_cmd(db_expr_t, int, db_expr_t, char *);
> >  void   db_boot_reboot_cmd(db_expr_t, int, db_expr_t, char *);
> >  void   db_boot_poweroff_cmd(db_expr_t, int, db_expr_t, char *);
> > +void   db_boot_reset_cmd(db_expr_t, int, db_expr_t, char *);
> >  void   db_stack_trace_cmd(db_expr_t, int, db_expr_t, char *);
> >  void   db_dmesg_cmd(db_expr_t, int, db_expr_t, char *);
> >  void   db_show_panic_cmd(db_expr_t, int, db_expr_t, char *);
> > @@ -597,6 +598,7 @@ struct db_command db_boot_cmds[] = {
> > { "halt",   db_boot_halt_cmd,   0,  0 },
> > { "reboot", db_boot_reboot_cmd, 0,  0 },
> > { "poweroff",   db_boot_poweroff_cmd,   0,  0 },
> > +   { "reset",  db_boot_reset_cmd,  0,  0 },
> > { NULL, }
> >  };
> >  
> > @@ -812,6 +814,12 @@ void
> >  db_boot_poweroff_cmd(db_expr_t addr, int haddr, db_expr_t count, char 
> > *modif)
> >  {
> > db_reboot(RB_NOSYNC | RB_HALT | RB_POWERDOWN | RB_TIMEBAD | RB_USERREQ);
> > +}
> > +
> > +void
> > +db_boot_reset_cmd(db_expr_t addr, int haddr, db_expr_t count, char *modif)
> > +{
> > +   db_reboot(RB_RESET | RB_AUTOBOOT | RB_NOSYNC | RB_TIMEBAD | RB_USERREQ);
> >  }
> >  
> >  void
> > Index: sys/sys/reboot.h
> >

Re: Add reset option to boot command of ddb(4)

2017-12-14 Thread Martin Pieuchot 
On 14/12/17(Thu) 11:30, Mark Kettenis wrote:
> > X-Originating-IP: 88.153.7.170
> > Date: Thu, 14 Dec 2017 10:30:21 +0100
> > From: Martin Pieuchot 
> > 
> > On 13/12/17(Wed) 19:09, Florian Riehm wrote:
> > > Hi,
> > > 
> > > This patch follows bluhm's attempt for a ddb command 'boot reset'.
> > > My first attempt was not architecture aware.
> > > 
> > > Tested on i386 by bluhm@ and on amd64 by me.
> > 
> > I don't understand why we need to add "boot reset"?  To not fix ddb(4)
> > and keep a broken "boot reboot"?  If we cannot fix our own code...
> 
> Funny you say that given the discussion about if_downall() on icb ;).

There's nothing funny.  There's people not reporting bugs with traceback
to bugs@ and coming around with workaround like that.

> IIRC "boot reset" is all about avoiding the if_downall() call.  And we
> really don't want to skip if_downall() in the "boot reboot".  We added
> that call since not stopping the DMA engines of the network cards had
> some very interesting effects when the machine rebooted...

If if_downall() is a problem, then please show me a traceback where
that's the case.  I'd be delighted to fix it :)

Re: Add reset option to boot command of ddb(4)

2017-12-14 Thread Mark Kettenis 
> Date: Thu, 14 Dec 2017 11:49:18 +0100
> From: Martin Pieuchot 
> 
> On 14/12/17(Thu) 11:30, Mark Kettenis wrote:
> > > X-Originating-IP: 88.153.7.170
> > > Date: Thu, 14 Dec 2017 10:30:21 +0100
> > > From: Martin Pieuchot 
> > > 
> > > On 13/12/17(Wed) 19:09, Florian Riehm wrote:
> > > > Hi,
> > > > 
> > > > This patch follows bluhm's attempt for a ddb command 'boot reset'.
> > > > My first attempt was not architecture aware.
> > > > 
> > > > Tested on i386 by bluhm@ and on amd64 by me.
> > > 
> > > I don't understand why we need to add "boot reset"?  To not fix ddb(4)
> > > and keep a broken "boot reboot"?  If we cannot fix our own code...
> > 
> > Funny you say that given the discussion about if_downall() on icb ;).
> 
> There's nothing funny.  There's people not reporting bugs with traceback
> to bugs@ and coming around with workaround like that.
> 
> > IIRC "boot reset" is all about avoiding the if_downall() call.  And we
> > really don't want to skip if_downall() in the "boot reboot".  We added
> > that call since not stopping the DMA engines of the network cards had
> > some very interesting effects when the machine rebooted...
> 
> If if_downall() is a problem, then please show me a traceback where
> that's the case.  I'd be delighted to fix it :)

True.  Given the DMA issue, "boot reset" would be a rather dangerous
command.

Re: Add reset option to boot command of ddb(4)

2017-12-14 Thread Peter Hessler 
On 2017 Dec 14 (Thu) at 11:49:18 +0100 (+0100), Martin Pieuchot wrote:
:On 14/12/17(Thu) 11:30, Mark Kettenis wrote:
:> > X-Originating-IP: 88.153.7.170
:> > Date: Thu, 14 Dec 2017 10:30:21 +0100
:> > From: Martin Pieuchot 
:> > 
:> > On 13/12/17(Wed) 19:09, Florian Riehm wrote:
:> > > Hi,
:> > > 
:> > > This patch follows bluhm's attempt for a ddb command 'boot reset'.
:> > > My first attempt was not architecture aware.
:> > > 
:> > > Tested on i386 by bluhm@ and on amd64 by me.
:> > 
:> > I don't understand why we need to add "boot reset"?  To not fix ddb(4)
:> > and keep a broken "boot reboot"?  If we cannot fix our own code...
:> 
:> Funny you say that given the discussion about if_downall() on icb ;).
:
:There's nothing funny.  There's people not reporting bugs with traceback
:to bugs@ and coming around with workaround like that.
:
:> IIRC "boot reset" is all about avoiding the if_downall() call.  And we
:> really don't want to skip if_downall() in the "boot reboot".  We added
:> that call since not stopping the DMA engines of the network cards had
:> some very interesting effects when the machine rebooted...
:
:If if_downall() is a problem, then please show me a traceback where
:that's the case.  I'd be delighted to fix it :)
:

Trace is on bugs, Subject: arm64 panic uvm_fault failed: ff80002619b4 with 
bonus panic: netlock: lock not held

-- 
A truly wise man never plays leapfrog with a unicorn.

Re: Symbols.map for libfuse

2017-12-14 Thread Jeremie Courreges-Anglas 

+cc Helg

On Thu, Dec 14 2017, Mark Kettenis  wrote:
>> From: Jeremie Courreges-Anglas 
>> Date: Thu, 14 Dec 2017 10:40:50 +0100
>> 
>> When reviewing helg@'s last diff I noticed a bunch of stuff that
>> shouldn't be exported.  So here's a diff similar to the recent
>> diffs for libutil and libkvm.  To get the list of public symbols I used
>> symbol visibility.
>> 
>> The diff below only reduces the symbols list, it does not remove PLT
>> entries for internal calls, as I don't feel confident using this
>> machinery.  AFAIK this can be done in a subsequent step with no bump.

[...]

> Looks good to me, but I can't judge if you're removing too much, so
> maybe you should wait for an ok from helg@ as well.

I have completed a partial ports bulk build with all libfuse consumers,
no visible fallout, with the updated diff below.  I used DEF and PROTO
from guenther's libkvm diff for intra-library calls.

New check_sym output:
/usr/lib/libfuse.so.1.1 --> obj/libfuse.so.2.0
Dynamic export changes:
removed:
__bss_start
__data_start
_edata
_end
_fini
_init
alloc_vn
build_realname
dict_SPLAY
dict_SPLAY_INSERT
dict_SPLAY_MINMAX
dict_SPLAY_REMOVE
dict_check
dict_get
dict_pop
dict_set
get_vn_by_name_and_parent
ifuse_debug
ifuse_debug_init
ifuse_exec_opcode
ref_vn
remove_vnode_from_name_tree
set_vn
tree_SPLAY
tree_SPLAY_INSERT
tree_SPLAY_MINMAX
tree_SPLAY_REMOVE
tree_check
tree_get
tree_pop
tree_set
unref_vn

PLT removed:
alloc_vn
build_realname
dict_SPLAY
dict_check
dict_get
dict_pop
dict_set
fuse_get_context
fuse_loop
fuse_mount
fuse_opt_insert_arg
fuse_opt_match
fuse_opt_parse
fuse_remove_signal_handlers
fuse_setup
fuse_unmount
get_vn_by_name_and_parent
ifuse_debug_init
ifuse_exec_opcode
ref_vn
set_vn
tree_SPLAY
tree_get
tree_pop
tree_set
unref_vn

ok?


Index: Makefile
===
--- Makefile.orig
+++ Makefile
@@ -17,6 +17,8 @@ CFLAGS+=  -I${.CURDIR}
 SRCS=  debug.c dict.c fuse.c fuse_ops.c fuse_opt.c fuse_subr.c tree.c
 HDRS=  fuse.h fuse_opt.h
 
+VERSION_SCRIPT=${.CURDIR}/Symbols.map
+
 PC_FILES=fuse.pc
 CLEANFILES+=${PC_FILES}
 
Index: Symbols.map
===
--- /dev/null
+++ Symbols.map
@@ -0,0 +1,31 @@
+{
+   global:
+   fuse_chan_fd;
+   fuse_daemonize;
+   fuse_destroy;
+   fuse_get_context;
+   fuse_get_session;
+   fuse_invalidate;
+   fuse_is_lib_option;
+   fuse_loop;
+   fuse_loop_mt;
+   fuse_main;
+   fuse_mount;
+   fuse_new;
+   fuse_opt_add_arg;
+   fuse_opt_add_opt;
+   fuse_opt_add_opt_escaped;
+   fuse_opt_free_args;
+   fuse_opt_insert_arg;
+   fuse_opt_match;
+   fuse_opt_parse;
+   fuse_parse_cmdline;
+   fuse_remove_signal_handlers;
+   fuse_set_signal_handlers;
+   fuse_setup;
+   fuse_teardown;
+   fuse_unmount;
+   fuse_version;
+   local:
+   *;
+};
Index: fuse.c
===
--- fuse.c.orig
+++ fuse.c
@@ -218,6 +218,7 @@ fuse_loop(struct fuse *fuse)
 
return (0);
 }
+DEF(fuse_loop);
 
 struct fuse_chan *
 fuse_mount(const char *dir, unused struct fuse_args *args)
@@ -268,6 +269,7 @@ bad:
free(fc);
return (NULL);
 }
+DEF(fuse_mount);
 
 void
 fuse_unmount(const char *dir, struct fuse_chan *ch)
@@ -278,6 +280,7 @@ fuse_unmount(const char *dir, struct fus
if (unmount(dir, MNT_UPDATE) == -1)
DPERROR(__func__);
 }
+DEF(fuse_unmount);
 
 int
 fuse_is_lib_option(const char *opt)
@@ -299,6 +302,7 @@ fuse_get_session(struct fuse *f)
 {
return (>se);
 }
+DEF(fuse_get_session);
 
 int
 fuse_loop_mt(unused struct fuse *fuse)
@@ -342,6 +346,7 @@ fuse_new(struct fuse_chan *fc, unused st
 
return (fuse);
 }
+DEF(fuse_new);
 
 int
 fuse_daemonize(int foreground)
@@ -351,6 +356,7 @@ fuse_daemonize(int foreground)
 
return (daemon(0,0));
 }
+DEF(fuse_daemonize);
 
 void
 fuse_destroy(struct fuse *f)
@@ -363,6 +369,7 @@ fuse_destroy(struct fuse *f)
free(f->fc);
free(f);
 }
+DEF(fuse_destroy);
 
 void
 fuse_remove_signal_handlers(unused struct fuse_session *se)
@@ -372,6 +379,7 @@ fuse_remove_signal_handlers(unused struc