Re: posix_spawn(3): explain that handling NULL envp is an extension

[Paul de Weerd]

Having never heard of posix_spawn(3), I read the full manpage and
(besides wondering "what's the point"), found that it's misspelled Ed
Schouten's name:

Index: posix_spawn.3
===
RCS file: /cvs/src/lib/libc/gen/posix_spawn.3,v
retrieving revision 1.10
diff -u -p -r1.10 posix_spawn.3
--- posix_spawn.3   26 Jun 2023 06:58:18 -  1.10
+++ posix_spawn.3   26 Jun 2023 15:17:07 -
@@ -132,4 +132,4 @@ These functions were ported from
 to
 .Ox 5.2 .
 .Sh AUTHORS
-.An \ Shouten Aq Mt e...@freebsd.org
+.An \ Schouten Aq Mt e...@freebsd.org

I checked the rest of the tree, no other occurences of 'Ed Shouten'
can be found.

Paul

On Sun, Jun 25, 2023 at 07:07:33PM -0300, Lucas de Sena wrote:
| The manual already describes how posix_spawn(3) behaves when passing it
| a NULL envp, but does not make it clear that it is an OpenBSD extension:
| 
| > If envp is NULL, the environment is passed unchanged from the parent
| > process.
| 
| That differs from GNU/Linux, for example, where a NULL envp gives the
| child an empty environment rather than a copy.
| 
| 
| Index: posix_spawn.3
| ===
| RCS file: /cvs/src/lib/libc/gen/posix_spawn.3,v
| retrieving revision 1.9
| diff -u -p -r1.9 posix_spawn.3
| --- posix_spawn.3 17 Oct 2017 22:47:58 -  1.9
| +++ posix_spawn.3 25 Jun 2023 21:38:47 -
| @@ -122,6 +122,10 @@ with exit status 127.
|  .Sh STANDARDS
|  Both functions conform to
|  .St -p1003.1-2001 .
| +.Pp
| +The handling of NULL
| +.Fa envp
| +is an extension to that standard.
|  .Sh HISTORY
|  These functions were ported from
|  .Fx
| 

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

Re: remove net.inet6.ip6.soiikey from userland

[Paul de Weerd]

On Sat, May 20, 2023 at 05:33:11PM +0200, Florian Obser wrote:
| In case this turns out to be useful for unlocking work in the kernel.
| 
| It's a minimum diff, if we want to go this way we probably want to move
| init_soiikey() to the engine process and stop bouncing through the main
| process when an interface changes.
| 
| This changes behaviour: in -current we can change the sysctl and down/up
| an interface to read the new value, with this diff that no longer
| works. slaacd will (and can) only read the file on startup.
| 
| This has consequences for the installer: slaacd starts before
| /mnt/etc/soii.key is available in the upgrade case. Which in turn means
| that we get a different IPv6 address in the installer than in the
| running system. I don't know how big of an issue that is.

Can't speak for others, but my use case for soii-addresses is for
incoming connections - outgoing ones should use the temporary privacy
addressed.  So for the installer it doesn't matter.

My guess is that this goes for many (most? all?) users of
soii-addresses, so it should be safe to not have those in the
installer during upgrades.

Paul

| diff --git distrib/miniroot/install.sub distrib/miniroot/install.sub
| index d3d944bf2ca..aa84e4808f2 100644
| --- distrib/miniroot/install.sub
| +++ distrib/miniroot/install.sub
| @@ -2620,9 +2620,6 @@ enable_network() {
|   echo "127.0.0.1\tlocalhost" >/tmp/i/hosts
|   echo "::1\t\tlocalhost" >>/tmp/i/hosts
|  
| - _f=/mnt/etc/soii.key
| - [[ -f $_f ]] && sysctl "net.inet6.ip6.soiikey=$(<$_f)"
| -
|   enable_ifs
|  }
|  
| diff --git distrib/special/sysctl/sysctl.c distrib/special/sysctl/sysctl.c
| index 9156d5f455c..7aedb6dd55b 100644
| --- distrib/special/sysctl/sysctl.c
| +++ distrib/special/sysctl/sysctl.c
| @@ -99,39 +99,6 @@ pstring(struct var *v)
|   return (1);
|  }
|  
| -int
| -parse_hex_char(char ch)
| -{
| - if (ch >= '0' && ch <= '9')
| - return (ch - '0');
| -
| - ch = tolower((unsigned char)ch);
| - if (ch >= 'a' && ch <= 'f')
| - return (ch - 'a' + 10);
| -
| - return (-1);
| -}
| -
| -int
| -set_soii_key(char *src)
| -{
| - uint8_t key[SOIIKEY_LEN];
| - int mib[4] = {CTL_NET, PF_INET6, IPPROTO_IPV6, IPV6CTL_SOIIKEY};
| - int i, c;
| -
| - for(i = 0; i < SOIIKEY_LEN; i++) {
| - if ((c = parse_hex_char(src[2 * i])) == -1)
| - return (-1);
| - key[i] = c << 4;
| - if ((c = parse_hex_char(src[2 * i + 1])) == -1)
| - return (-1);
| - key[i] |= c;
| - }
| -
| - return sysctl(mib, sizeof(mib) / sizeof(mib[0]), NULL, NULL, key,
| - SOIIKEY_LEN);
| -}
| -
|  int
|  main(int argc, char *argv[])
|  {
| @@ -159,17 +126,6 @@ main(int argc, char *argv[])
|  
|   while (argc--) {
|   name = *argv++;
| - /*
| -  * strlen("net.inet6.ip6.soiikey="
| -  * "") == 54
| -  * strlen("net.inet6.ip6.soiikey=") == 22
| -  */
| - if (strlen(name) == 54 && strncmp(name,
| - "net.inet6.ip6.soiikey=", 22) == 0) {
| - set_soii_key(name + 22);
| - continue;
| - }
| -
|   for (i = 0; i < sizeof(vars)/sizeof(vars[0]); i++) {
|   if (strcmp(name, vars[i].name) == 0) {
|   (vars[i].print)([i]);
| diff --git etc/netstart etc/netstart
| index af4866f909e..105d5a977cf 100644
| --- etc/netstart
| +++ etc/netstart
| @@ -360,13 +360,6 @@ if ifconfig lo0 inet6 >/dev/null 2>&1; then
|   IP6KERNEL=true
|  fi
|  
| -# Load key material for the generation of IPv6 Semantically Opaque Interface
| -# Identifiers (SOII) used for SLAAC addresses.
| -if $IP6KERNEL && ! $PRINT_ONLY; then
| - [[ -f /etc/soii.key ]] &&
| - sysctl -q "net.inet6.ip6.soiikey=$( /etc/soii.key &&
| - chmod 600 /etc/soii.key && sysctl -q \
| - "net.inet6.ip6.soiikey=$(
|  #include 
|  #include 
| +#include 
|  #include 
| -#include 
|  #include 
|  #include 
|  
| @@ -34,6 +34,7 @@
|  #include 
|  #include 
|  
| +#include 
|  #include 
|  #include 
|  #include 
| @@ -76,7 +77,8 @@ voidconfigure_gateway(struct imsg_configure_dfr *, 
uint8_t);
|  void add_gateway(struct imsg_configure_dfr *);
|  void delete_gateway(struct imsg_configure_dfr *);
|  void send_rdns_proposal(struct imsg_propose_rdns *);
| -int  get_soiikey(uint8_t *);
| +int  parse_hex_char(char);
| +void init_soiikey(void);
|  
|  static int   main_imsg_send_ipc_sockets(struct imsgbuf *, struct imsgbuf *);
|  int  main_imsg_compose_frontend(int, int, void *, uint16_t);
| @@ -89,6 +91,7 @@ pid_tfrontend_pid;
|  pid_t engine_pid;
|  
|  int   routesock, ioctl_sock, rtm_seq = 0;
| +uint8_t   

Re: ure(4): add support for RTL8153D

[Paul de Weerd]

Hi Kevin,

This seems to work fine on my machine.  The ure0 is built into my
monitor:

ure0 at uhub9 port 3 configuration 1 interface 0 "Realtek USB 10/100/1000 LAN" 
rev 3.20/33.00 addr 4
ure0: RTL8153D (0x7420), address c8:4b:d6:af:a7:8d

I can get both v4 and v6 addresses over this interface and so far
everything seems to work just fine.

Thanks!

Paul

On Thu, May 04, 2023 at 02:28:54PM +0800, Kevin Lo wrote:
| Hi,
| 
| This diff adds initial support for RTL8153D to ure(4).
| 
| The RTL8153D chipset shares many similarities with the already supported 
| RTL8156B chip but additionally requires a few semi-unique configurations.
| 
| Tested:
| ure0 at uhub0 port 3 configuration 1 interface 0 "Realtek USB 10/100/1000 
LAN" rev 2.10/f3.f0 addr 2
| ure0: RTL8153D (0x7420), address 00:e0:4c:xx:xx:xx
| 
| ok?
| 
| Index: sys/dev/usb/if_ure.c
| ===
| RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
| retrieving revision 1.31
| diff -u -p -u -p -r1.31 if_ure.c
| --- sys/dev/usb/if_ure.c  27 Oct 2022 13:21:14 -  1.31
| +++ sys/dev/usb/if_ure.c  4 May 2023 06:05:03 -
| @@ -270,7 +270,7 @@ ure_read_1(struct ure_softc *sc, uint16_
|  
|   shift = (reg & 3) << 3;
|   reg &= ~3;
| - 
| +
|   ure_read_mem(sc, reg, index, , 4);
|   val = UGETDW(temp);
|   val >>= shift;
| @@ -466,8 +466,8 @@ ure_ifmedia_init(struct ifnet *ifp)
|  
|   reg = sc->ure_rxbufsz - URE_FRAMELEN(ifp->if_mtu) -
|   sizeof(struct ure_rxpkt) - URE_RX_BUF_ALIGN;
| - if (sc->ure_flags & (URE_FLAG_8153B | URE_FLAG_8156 |
| - URE_FLAG_8156B)) {
| + if (sc->ure_flags &
| + (URE_FLAG_8153B | URE_FLAG_8156 | URE_FLAG_8156B)) {
|   ure_write_2(sc, URE_USB_RX_EARLY_SIZE, URE_MCU_TYPE_USB,
|   reg / 8);
|  
| @@ -493,6 +493,11 @@ ure_ifmedia_init(struct ifnet *ifp)
|   reg);
|   }
|  
| + if (sc->ure_chip & URE_CHIP_VER_7420) {
| + URE_SETBIT_2(sc, URE_PLA_MAC_PWR_CTRL4,
| + URE_MCU_TYPE_PLA, URE_IDLE_SPDWN_EN);
| + }
| +
|   if ((sc->ure_chip & URE_CHIP_VER_6010) ||
|   (sc->ure_flags & URE_FLAG_8156B)) {
|   URE_CLRBIT_2(sc, URE_USB_FW_TASK, URE_MCU_TYPE_USB,
| @@ -502,7 +507,7 @@ ure_ifmedia_init(struct ifnet *ifp)
|   URE_FC_PATCH_TASK);
|   }
|   }
| - 
| +
|   /* Reset the packet filter. */
|   URE_CLRBIT_2(sc, URE_PLA_FMC, URE_MCU_TYPE_PLA, URE_FMC_FCR_MCU_EN);
|   URE_SETBIT_2(sc, URE_PLA_FMC, URE_MCU_TYPE_PLA, URE_FMC_FCR_MCU_EN);
| @@ -530,15 +535,18 @@ ure_ifmedia_upd(struct ifnet *ifp)
|   if (IFM_TYPE(ifm->ifm_media) != IFM_ETHER)
|   return (EINVAL);
|  
| - reg = ure_ocp_reg_read(sc, 0xa5d4);
| - reg &= ~URE_ADV_2500TFDX;
| + if (!(sc->ure_chip & URE_CHIP_VER_7420)) {
| + reg = ure_ocp_reg_read(sc, URE_OCP_10GBT_CTRL);
| + reg &= ~URE_ADV_2500TFDX;
| + }
|  
|   anar = gig = 0;
|   switch (IFM_SUBTYPE(ifm->ifm_media)) {
|   case IFM_AUTO:
|   anar |= ANAR_TX_FD | ANAR_TX | ANAR_10_FD | ANAR_10;
|   gig |= GTCR_ADV_1000TFDX | GTCR_ADV_1000THDX;
| - reg |= URE_ADV_2500TFDX;
| + if (!(sc->ure_chip & URE_CHIP_VER_7420))
| + reg |= URE_ADV_2500TFDX;
|   break;
|   case IFM_2500_T:
|   anar |= ANAR_TX_FD | ANAR_TX | ANAR_10_FD | ANAR_10;
| @@ -566,9 +574,10 @@ ure_ifmedia_upd(struct ifnet *ifp)
|   }
|  
|   ure_ocp_reg_write(sc, URE_OCP_BASE_MII + MII_ANAR * 2,
| - anar | ANAR_PAUSE_ASYM | ANAR_FC); 
| - ure_ocp_reg_write(sc, URE_OCP_BASE_MII + MII_100T2CR * 2, gig); 
| - ure_ocp_reg_write(sc, 0xa5d4, reg);
| + anar | ANAR_PAUSE_ASYM | ANAR_FC);
| + ure_ocp_reg_write(sc, URE_OCP_BASE_MII + MII_100T2CR * 2, gig);
| + if (!(sc->ure_chip & URE_CHIP_VER_7420))
| + ure_ocp_reg_write(sc, URE_OCP_10GBT_CTRL, reg);
|   ure_ocp_reg_write(sc, URE_OCP_BASE_MII + MII_BMCR,
|   BMCR_AUTOEN | BMCR_STARTNEG);
|  
| @@ -602,7 +611,7 @@ ure_ifmedia_sts(struct ifnet *ifp, struc
|   status = ure_read_2(sc, URE_PLA_PHYSTATUS,
|   URE_MCU_TYPE_PLA);
|   if ((status & URE_PHYSTATUS_FDX) ||
| - (status & URE_PHYSTATUS_2500MBPS)) 
| + (status & URE_PHYSTATUS_2500MBPS))
|   ifmr->ifm_active |= IFM_FDX;
|   else
|   

Re: Recognize Kingston KC3000 NVME SSD

[Paul de Weerd]

ping

Is this worth it?  Rebased diff at the bottom for convenience

On Sun, Mar 19, 2023 at 05:12:18PM +0100, Paul de Weerd wrote:
| I put a Kingston KC3000 NVME SSD[1] in my new machine.  This diff
| recognizes that device:
| 
| Index: pcidevs
| ===
| RCS file: /cvs/src/sys/dev/pci/pcidevs,v
| retrieving revision 1.2026
| diff -u -p -r1.2026 pcidevs
| --- pcidevs   19 Mar 2023 09:38:06 -  1.2026
| +++ pcidevs   19 Mar 2023 16:08:11 -
| @@ -7010,6 +7010,7 @@ product JMICRON XD_20x2394  xD
|  
|  /* Kingston */
|  product KINGSTON A2000   0x2263  A2000
| +product KINGSTON KC3000  0x5013  KC3000
|  product KINGSTON NV2 0x5019  NV2
|  
|  /* Kioxia */
| 
| dmesg goes from:
| 
| nvme0 at pci15 dev 0 function 0 vendor "Kingston", unknown product 0x5013 rev 
0x01: msix, NVMe 1.4
| nvme0: KINGSTON SKC3000D2048G, firmware EIFK31.6, serial 50026B76863F2586
| scsibus1 at nvme0: 2 targets, initiator 0
| sd0 at scsibus1 targ 1 lun 0: 
| sd0: 1953514MB, 512 bytes/sector, 4000797360 sectors
| 
| to:
| 
| nvme0 at pci15 dev 0 function 0 "Kingston KC3000" rev 0x01: msix, NVMe 1.4
| nvme0: KINGSTON SKC3000D2048G, firmware EIFK31.6, serial 50026B76863F2586
| scsibus1 at nvme0: 2 targets, initiator 0
| sd0 at scsibus1 targ 1 lun 0: 
| sd0: 1953514MB, 512 bytes/sector, 4000797360 sectors
| 
| It already works fine, so I'm not sure it's worth the extra bytes
| added to the kernel.
| 
| Paul
| 
| [1]: https://www.kingston.com/en/ssd/kc3000-nvme-m2-solid-state-drive
| 
| -- 
| >[<++>-]<+++.>+++[<-->-]<.>+++[<+
| +++>-]<.>++[<>-]<+.--.[-]
|  http://www.weirdnet.nl/ 
| 

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2030
diff -u -p -u -r1.2030 pcidevs
--- pcidevs 12 Apr 2023 15:56:08 -  1.2030
+++ pcidevs 22 Apr 2023 15:06:58 -
@@ -7023,6 +7023,7 @@ product JMICRON XD_2  0x2394  xD
 
 /* Kingston */
 product KINGSTON A2000 0x2263  A2000
+product KINGSTON KC30000x5013  KC3000
 product KINGSTON NV2   0x5019  NV2
 
 /* Kioxia */

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

ntpd: log hostname of constraint with IP address

[Paul de Weerd]

While debugging some NTP weirdness, I noticed an outlier amongst the
constraints (all except one had an offset less than 1s, the one
outlier was over 7 hours off).  Unfortunately, I couldn't tell which
constraint had the outlier, because the IP's rDNS didn't correspond
to one of the constraints (it was cloudfront's), and none of the
constraints resolve to the IP address logged.

Therefore, I suggest the following patch which logs the name of the
constraint together with its IP address:

Index: constraint.c
===
RCS file: /cvs/src/usr.sbin/ntpd/constraint.c,v
retrieving revision 1.54
diff -u -p -r1.54 constraint.c
--- constraint.c27 Nov 2022 13:19:00 -  1.54
+++ constraint.c20 Apr 2023 09:03:00 -
@@ -679,8 +679,9 @@ constraint_msg_result(u_int32_t id, u_in
offset = gettime_from_timeval([0]) -
gettime_from_timeval([1]);
 
-   log_info("constraint reply from %s: offset %f",
+   log_info("constraint reply from %s (%s): offset %f",
log_sockaddr((struct sockaddr *)>addr->ss),
+   cstr->addr_head.name,
offset);
 
cstr->state = STATE_REPLY_RECEIVED;

Cheers,

Paul

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

Recognize Kingston KC3000 NVME SSD

[Paul de Weerd]

I put a Kingston KC3000 NVME SSD[1] in my new machine.  This diff
recognizes that device:

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2026
diff -u -p -r1.2026 pcidevs
--- pcidevs 19 Mar 2023 09:38:06 -  1.2026
+++ pcidevs 19 Mar 2023 16:08:11 -
@@ -7010,6 +7010,7 @@ product JMICRON XD_2  0x2394  xD
 
 /* Kingston */
 product KINGSTON A2000 0x2263  A2000
+product KINGSTON KC30000x5013  KC3000
 product KINGSTON NV2   0x5019  NV2
 
 /* Kioxia */

dmesg goes from:

nvme0 at pci15 dev 0 function 0 vendor "Kingston", unknown product 0x5013 rev 
0x01: msix, NVMe 1.4
nvme0: KINGSTON SKC3000D2048G, firmware EIFK31.6, serial 50026B76863F2586
scsibus1 at nvme0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: 
sd0: 1953514MB, 512 bytes/sector, 4000797360 sectors

to:

nvme0 at pci15 dev 0 function 0 "Kingston KC3000" rev 0x01: msix, NVMe 1.4
nvme0: KINGSTON SKC3000D2048G, firmware EIFK31.6, serial 50026B76863F2586
scsibus1 at nvme0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: 
sd0: 1953514MB, 512 bytes/sector, 4000797360 sectors

It already works fine, so I'm not sure it's worth the extra bytes
added to the kernel.

Paul

[1]: https://www.kingston.com/en/ssd/kc3000-nvme-m2-solid-state-drive

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

add Aquantia AQC113CS to pcidevs

[Paul de Weerd]

My new motherboard has a 10GB/s interface that doesn't work with
-current.  It's this thing:

--- pcidump -v 7:0:0 -
 7:0:0: Aquantia unknown
0x: Vendor ID: 1d6a, Product ID: 94c0
0x0004: Command: 0006, Status: 0010
0x0008: Class: 02 Network, Subclass: 00 Ethernet,
Interface: 00, Revision: 03
0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
Cache Line Size: 10
0x0010: BAR mem 64bit addr: 0xeb80/0x0008
0x0018: BAR mem 64bit addr: 0xeb8a/0x1000
0x0020: BAR mem 64bit addr: 0xeb40/0x0040
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1043 Product ID: 87f5
0x0030: Expansion ROM Base Address: eb88
0x0038: 
0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
0x0040: Capability 0x01: Power Management
State: D0
0x0050: Capability 0x05: Message Signalled Interrupts (MSI)
Enabled: no
0x0070: Capability 0x10: PCI Express
Max Payload Size: 128 / 512 bytes
Max Read Request Size: 512 bytes
Link Speed: 8.0 / 8.0 GT/s
Link Width: x1 / x2
0x0100: Enhanced Capability 0x01: Advanced Error Reporting
0x0148: Enhanced Capability 0x02: Virtual Channel Capability
0x0168: Enhanced Capability 0x03: Device Serial Number
Serial Number: 
0x0178: Enhanced Capability 0x19: Secondary PCIe Capability
0x0198: Enhanced Capability 0x26: Physical Layer 16.0 GT/s
0x01bc: Enhanced Capability 0x27: Lane Margining at the Receiver
0x01d4: Enhanced Capability 0x18: Latency Tolerance Reporting
0x01dc: Enhanced Capability 0x1e: L1 PM
0x01ec: Enhanced Capability 0x0b: Vendor-Specific
0x02ec: Enhanced Capability 0x25: Data Link Feature 
0x02f8: Enhanced Capability 0x1f: Precision Time Measurement
0x0304: Enhanced Capability 0x0b: Vendor-Specific
0x00b0: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
Enabled: yes; table size 32 (BAR 2:0)
--

Some googling led me to this page which suggests it's AQC113CS:

https://devicehunt.com/view/type/pci/vendor/1D6A/device/94C0

So, this adds Aquantia AQC113CS to pcidevs:

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2026
diff -u -p -r1.2026 pcidevs
--- pcidevs 19 Mar 2023 09:38:06 -  1.2026
+++ pcidevs 19 Mar 2023 14:31:30 -
@@ -1134,6 +1134,7 @@ product AQUANTIA AQC108S  0x88b1  AQC108S
 product AQUANTIA AQC109S   0x89b1  AQC109S
 product AQUANTIA AQC111S   0x91b1  AQC111S
 product AQUANTIA AQC112S   0x92b1  AQC112S
+product AQUANTIA AQC113CS  0x94c0  AQC113CS
 product AQUANTIA D100  0xd100  D100
 product AQUANTIA D107  0xd107  D107
 product AQUANTIA D108  0xd108  D108

It doesn't work yet though:

Index: if_aq_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_aq_pci.c,v
retrieving revision 1.17
diff -u -p -r1.17 if_aq_pci.c
--- if_aq_pci.c 25 May 2022 09:49:17 -  1.17
+++ if_aq_pci.c 19 Mar 2023 14:32:51 -
@@ -798,6 +798,7 @@ const struct pci_matchid aq_devices[] = 
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC109S },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC111S },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC112S },
+   { PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC113CS },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_D100 },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_D107 },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_D108 },

results in:

aq0 at pci7 dev 0 function 0 "Aquantia AQC113CS" rev 0x03: msix, 8 queuesaq0: 
FLB> MAC kickstart failed: timed out
aq0: MAC reset failed: 60

And subsequently no interface is available to the OS after system
start up, so obviously more is needed.

Paul

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

Re: ACPI diff for testing

[Paul de Weerd]

Hi Mark,

On Thu, Mar 09, 2023 at 05:23:55PM +0100, Mark Kettenis wrote:
| > Date: Thu, 09 Mar 2023 14:48:25 +0100
| > From: Mark Kettenis 
| > 
| > The diff below fixes an issue with the way we attach "APCI devices".
| > As with all ACPI diffs, this may potentially introduce regressions, so
| > some wider testing would be welcome.
| > 
| > The fix itself involves resolving a "nameref" in the package that
| > describes dependencies between APCI devices.  These namerefs need to
| > be evaluated lazily (for reasons) but this wasn't done in this case.
| 
| To be a bit more specific, I'm really interested to see if there are
| machines where this changes the order in which devices attach on a
| system.  If that happens on your system, please send me both the old
| and the new dmesg.

No difference seen other than:

-OpenBSD 7.2-current (GENERIC.MP) #3: Mon Feb 27 17:02:30 CET 2023
+OpenBSD 7.3-beta (GENERIC.MP) #4: Thu Mar  9 18:03:54 CET 2023

we...@salmon.alm.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 34179575808 (32596MB)
-avail mem = 33124311040 (31589MB)
+avail mem = 33124294656 (31589MB)
 random: good seed from bootblocks
 mpath0 at root
 scsibus0 at mpath0: 256 targets

(this is one of those machines with the 0x6f GPE firing issue)

I'll try a few more systems.

Paul

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

Re: refactor mbuf parsing on driver level

[Paul de Weerd]

On Tue, Feb 07, 2023 at 01:09:25AM +0100, Christian Weisgerber wrote:
| Jan Klemkow:
| 
| > > igc(4) has very similar code, but I don't have access to a machine
| > > with that hardware.
| > 
| > Send me an ssh-key and I give you access to this machine:
| 
| Alternatively, here's the diff, so other people can test it.

Works well for me with:

igc0 at pci2 dev 0 function 0 "Intel I225-V" rev 0x03, msix, 4 queues, address 
60:be:b4:02:9e:70

Haven't been able to test at 2.5GB/s, so 1GB/s max for now.

Paul 'WEiRD' de Weerd

| diff a0c537a1c9d84e98322b55d8f71438a147aaa7c4 
7d976644b87094d08f478fb087be35b91d2e38a7
| commit - a0c537a1c9d84e98322b55d8f71438a147aaa7c4
| commit + 7d976644b87094d08f478fb087be35b91d2e38a7
| blob - a904d43c66b767b162b7602f2ef35fa5dc6dae4f
| blob + c172c137bf82cea95f6f7c0524cd7e72ced18018
| --- sys/dev/pci/if_igc.c
| +++ sys/dev/pci/if_igc.c
| @@ -2002,17 +2002,14 @@ igc_tx_ctx_setup(struct tx_ring *txr, struct mbuf *mp,
|  igc_tx_ctx_setup(struct tx_ring *txr, struct mbuf *mp, int prod,
|  uint32_t *olinfo_status)
|  {
| + struct ether_extracted ext;
|   struct igc_adv_tx_context_desc *txdesc;
| - struct ether_header *eh = mtod(mp, struct ether_header *);
| - struct mbuf *m;
|   uint32_t type_tucmd_mlhl = 0;
|   uint32_t vlan_macip_lens = 0;
|   uint32_t iphlen;
| - int hoff;
|   int off = 0;
| - uint8_t ipproto;
|  
| - vlan_macip_lens |= (sizeof(*eh) << IGC_ADVTXD_MACLEN_SHIFT);
| + vlan_macip_lens |= (sizeof(*ext.eh) << IGC_ADVTXD_MACLEN_SHIFT);
|  
|   /*
|* In advanced descriptors the vlan tag must
| @@ -2029,62 +2026,41 @@ igc_tx_ctx_setup(struct tx_ring *txr, struct mbuf *mp,
|  #endif
|  #endif
|  
| - switch (ntohs(eh->ether_type)) {
| - case ETHERTYPE_IP: {
| - struct ip *ip;
| + ether_extract_headers(mp, );
|  
| - m = m_getptr(mp, sizeof(*eh), );
| - KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip));
| - ip = (struct ip *)(mtod(m, caddr_t) + hoff);
| + if (ext.ip4) {
| + iphlen = ext.ip4->ip_hl << 2;
|  
| - iphlen = ip->ip_hl << 2;
| - ipproto = ip->ip_p;
| -
|   type_tucmd_mlhl |= IGC_ADVTXD_TUCMD_IPV4;
|   if (ISSET(mp->m_pkthdr.csum_flags, M_IPV4_CSUM_OUT)) {
|   *olinfo_status |= IGC_TXD_POPTS_IXSM << 8;
|   off = 1;
|   }
| -
| - break;
| - }
|  #ifdef INET6
| - case ETHERTYPE_IPV6: {
| - struct ip6_hdr *ip6;
| + } else if (ext.ip6) {
| + iphlen = sizeof(*ext.ip6);
|  
| - m = m_getptr(mp, sizeof(*eh), );
| - KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip6));
| - ip6 = (struct ip6_hdr *)(mtod(m, caddr_t) + hoff);
| -
| - iphlen = sizeof(*ip6);
| - ipproto = ip6->ip6_nxt;
| -
|   type_tucmd_mlhl |= IGC_ADVTXD_TUCMD_IPV6;
| - break;
| - }
|  #endif
| - default:
| + } else {
|   return 0;
|   }
|  
|   vlan_macip_lens |= iphlen;
|   type_tucmd_mlhl |= IGC_ADVTXD_DCMD_DEXT | IGC_ADVTXD_DTYP_CTXT;
|  
| - switch (ipproto) {
| - case IPPROTO_TCP:
| + if (ext.tcp) {
|   type_tucmd_mlhl |= IGC_ADVTXD_TUCMD_L4T_TCP;
|   if (ISSET(mp->m_pkthdr.csum_flags, M_TCP_CSUM_OUT)) {
|   *olinfo_status |= IGC_TXD_POPTS_TXSM << 8;
|   off = 1;
|   }
| - break;
| - case IPPROTO_UDP:
| + } else if (ext.udp) {
|   type_tucmd_mlhl |= IGC_ADVTXD_TUCMD_L4T_UDP;
|   if (ISSET(mp->m_pkthdr.csum_flags, M_UDP_CSUM_OUT)) {
|   *olinfo_status |= IGC_TXD_POPTS_TXSM << 8;
|   off = 1;
|   }
| - break;
|   }
|  
|   if (off == 0)
| 
| -- 
| Christian "naddy" Weisgerber  na...@mips.inka.de
| 

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

Re: Making wscons a bit more like xterm

[Paul de Weerd]

On Wed, Jan 04, 2023 at 05:42:31PM -0300, Crystal Kolipe wrote:
| Hopefully it'll fix the problem.

Tested with tmux, the spurious ^@'s are now indeed gone.  I see
there's a new diff available, so I'll try that out in a bit.

Paul

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

Re: Making wscons a bit more like xterm

[Paul de Weerd]

On Wed, Jan 04, 2023 at 02:33:57PM -0300, Crystal Kolipe wrote:
| On Wed, Jan 04, 2023 at 04:42:55PM +0100, Paul de Weerd wrote:
| > Hi Crystal,
| > 
| > I tried your patch on my laptop.  With it applied, and my TERM set to
| > 'xterm', I do get colors in mutt and tmux.
| 
| Great!  Thanks for testing :).
| 
| > The latter, however, shows
| > '^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
| > behavior I don't see with a 'real' xterm.
| 
| This looks like an off-by-one in the wscons code, (not introduced by me!)
| 
| Does the following patch, (on top of the last one), fix it?

Fixes only half of it: we're down to one ^@ now (which is not fixed
with a s/1/2/ in your below diff).

Cheers,

Paul

| --- dev/wscons/wsemul_vt100_subr.c.dist   Mon May 25 06:55:49 2020
| +++ dev/wscons/wsemul_vt100_subr.cWed Jan  4 14:22:05 2023
| @@ -231,7 +231,7 @@
|   switch (A3(edp->modif1, edp->modif2, c)) {
|   case A3('>', '\0', 'c'): /* DA secondary */
|   wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID2,
| - sizeof(WSEMUL_VT_ID2));
| + sizeof(WSEMUL_VT_ID2)-1);
|   break;
|  
|   case A3('\0', '\0', 'J'): /* ED selective erase in display */

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

Re: Making wscons a bit more like xterm

[Paul de Weerd]

Hi Crystal,

I tried your patch on my laptop.  With it applied, and my TERM set to
'xterm', I do get colors in mutt and tmux.  The latter, however, shows
'^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
behavior I don't see with a 'real' xterm.

I like the idea, thanks for your work on this diff.

Paul

On Wed, Jan 04, 2023 at 10:42:56AM -0300, Crystal Kolipe wrote:
| Continuing the move towards xterm becoming the default termtype for the
| console...
| 
| This third version of the patchset adds the following features.  New features
| since the last version are highlighted first:
| 
| NEW - Control sequences for dim text, invisible text, strike through, italic,
|   and double underline attributes are now recognised and set flags in
|   wscons.
| 
| NEW - Rendering of dim, invisible, struck, and double underlined text is now
|   supported in rasops32.c, so users of 32bpp displays will see these text
|   effects on the console.
| 
| NEW - The default number of scrollback screens has been increased from five to
|   twenty.
| 
| * F1 - F4 now send different sequences.
| * F13 - F24 now send different sequences, but see notes below about F13 - F16.
| * With numlock OFF, keypad 5 is now 'begin' rather than unused.
| * Home, End, keypad home, and keypad end now send different sequences.
| * A new keysym has been added - KS_Backtab.
| * Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
| * Shift-F1 - Shift-F12 now send F13 - F24.
| * Five new escape sequences added for cursor movement.
| 
| Running with this patch, all of the curses-based programs that I use on a
| regular basis are working and usable with TERM=xterm.
| 
| The overall experience is much improved over TERM=vt220, as we get colour.
| 
| Even compared to pccon, we gain the ability to use colour together with
| underline, show and hide the cursor, and use backtab.  We also gain the
| practicality of relying on a very widely and well supported terminal
| definition, (xterm), which could much more reasonably become the default than
| could pccon.
| 
| Additionally, a small side benefit of changing the function key sequences from
| those expected by pccon to those expected by xterm is that any programs or
| scripts which ignore terminfo and are hard coded to work with xterm will now
| work on the console as well.
| 
| --- dev/wscons/wsemul_vt100_keys.c.dist   Sat Mar 14 00:38:50 2015
| +++ dev/wscons/wsemul_vt100_keys.cMon Jan  2 16:01:42 2023
| @@ -37,11 +37,9 @@
|  #include 
|  #include 
|  
| +#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
| +
|  static const u_char *vt100_fkeys[] = {
| - "\033[11~", /* F1 */
| - "\033[12~",
| - "\033[13~", /* F1-F5 normally don't send codes */
| - "\033[14~",
|   "\033[15~", /* F5 */
|   "\033[17~", /* F6 */
|   "\033[18~",
| @@ -50,18 +48,18 @@
|   "\033[21~",
|   "\033[23~", /* VT100: ESC */
|   "\033[24~", /* VT100: BS */
| - "\033[25~", /* VT100: LF */
| - "\033[26~",
| - "\033[28~", /* help */
| - "\033[29~", /* do */
| - "\033[31~",
| - "\033[32~",
| - "\033[33~",
| - "\033[34~", /* F20 */
| - "\033[35~",
| - "\033[36~",
| - "\033[37~",
| - "\033[38~"
| + "\033[1;2P",/* VT100: LF */
| + "\033[1;2Q",
| + "\033[1;2R",/* help */
| + "\033[1;2S",/* do */
| + "\033[15;2~",
| + "\033[17;2~",
| + "\033[18;2~",
| + "\033[19;2~",   /* F20 */
| + "\033[20;2~",
| + "\033[21;2~",
| + "\033[23;2~",
| + "\033[24;2~"
|  };
|  
|  static const u_char *vt100_pfkeys[] = {
| @@ -96,14 +94,22 @@
|   edp->translatebuf, edp->flags & VTFL_UTF8));
|   }
|  
| - if (in >= KS_f1 && in <= KS_f24) {
| - *out = vt100_fkeys[in - KS_f1];
| - return (5);
| + if (in >= KS_f1 && in <= KS_f4) {
| + *out = vt100_pfkeys[in - KS_f1];
| + return (3);
|   }
| - if (in >= KS_F1 && in <= KS_F24) {
| - *out = vt100_fkeys[in - KS_F1];
| - return (5);
| + if (in >= KS_F1 && in <= KS_F4) {
| + *out = vt100_pfkeys[in - KS_F1];
| + return (3);
|   }
| + if (in >= KS_f5 && in <= KS_f24) {
| + *out = vt100_fkeys[in - KS_f5];
| + return vt100_fkeys_len(in - KS_f5);
| + }
| + if (in >= KS_F5 && in <= KS_F24) {
| + *out = vt100_fkeys[in - KS_F5];
| + return vt100_fkeys_len(in - KS_F5);
| + }
|   if (in >= KS_KP_F1 && in <= KS_KP_F4) {
|   *out = vt100_pfkeys[in - KS_KP_F1];
|   return (3);
| @@ -148,12 +154,12 @@
|   }
|   switch (in) {
|   case KS_Help:
| - *out = vt100_fkeys[15 - 1];
| + *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
|   return (5);
|   case KS_Execute: /* "Do" */
| - *out = 

Re: dhcpleased(8): close unneeded bpf FDs

[Paul de Weerd]

On Thu, Jul 14, 2022 at 08:20:41AM +0200, Florian Obser wrote:
| On 2022-07-12 14:35 +02, Florian Obser  wrote:
| > When the autoconf flag flaps around we might end up with multiple bpf
| > FDs in flight. Things then get confusing. The kernel tells us we can
| > read from the bpf FD but the data is actually "on the other FD", so
| > read(2) returns 0.
| >
| > Found the hard way by, and patiently debugged with weerd@
| >
| > One way to trigger this is booting a vmm VM where dhcpleased(8)'s
| > init_ifaces() loses a race against netstart(8). init_ifaces() would
| > already see the autoconf flag and request a bpf FD.
| > But then it would receive a RTM_IFINFO message without the autoconf flag
| > set from when the interface came up. Then it will see another RTM_IFINFO
| > message with the autoconf flag set and request yet another bpf FD. If
| > the first bpf FD had not arrived yet we ended up with two in the frontend
| > process.
| >
| > While here make sure a bpf FD has been configured before calling
| > close(2) on it.
| >
| > OK?
| >
| 
| Anyone? This is a slightly annoying bug... Difficult to hit though.

I found it on a bunch of (vmm) VMs I have around for testing /
experimenting purposes.  The change to /etc/rc to start dhcpleased
much earlier was a key factor in triggering it for me.  I tried
bisecting kernels, but all the older ones had the same problem (while
I didn't see this issue when running older snapshots).  That's when I
realized the /etc/rc change could be relevant somehow.

daily(8) started reporting 

> Services that should be running but aren't:
> dhcpleased

Thanks to Florian for the fix, it works well for me.

Paul

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

Re: New hw.perfpolicy behavior

[Paul de Weerd]

On Tue, Nov 02, 2021 at 12:30:56PM -0600, Theo de Raadt wrote:
| Paul de Weerd  wrote:
| 
| > A recent commit by Theo changed the hw.perfpolicy behavior to always
| > run at full speed when AC power is on.  This means that my workstation
| > (and servers, once I upgrade them) now consumes significantly more
| > power, even though they usually idle.
| 
| Did you measure how much more power?

Admittedly, I didn't.  I have a colocated server that has had its 
power usage measured for years (I'm charged per kWh, so each monthly
invoice has the usage for the month prior), and I recalled a
significant drop in usage from years ago.  I thought this was back
when hw.perfpolicy=auto was introduced in 2014, but I was mistaken: it
was the introduction of support for C-states one year later that gave
that result: my machine went from ~30 kWh per month to ~20 kWh per
month.  (note that that was an older generation CPU: cpu0: Intel(R)
Xeon(R) CPU E31260L @ 2.40GHz, 2394.97 MHz, 06-2a-07).

Those were the significant savings I recalled.  Apologies for the
false claim there, I had these two mixed up in my head.

| You must measure, to make such a claim.
| 
| Your OptiPlex 9020 is probably a modern i5/i7, which probably contains
| C states similar to this:
| 
| acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS

You're right, of course:

cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.93 MHz, 06-3c-03
...
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS

| Which means when the idle loop calls the "mwait" instruction, the cpu
| will 'instantly' slow down to a lower clock and make other power use
| reductions, until an interrupt happens and requires labour again.
| 
| Most modern cpus dynamically downscale in such way, which mostly
| obliterates the requirement to manually control things, or even handle
| it in a slow-paced data-weak way in the scheduler.

Thank you for that explanation, that makes a lot of sense.

| So you must back your claim up with power measurements.
| 
| > [weerd@pom] $ sysctl hw.{vendor,product,perfpolicy,setperf,cpuspeed}
| > hw.vendor=Dell Inc.
| > hw.product=OptiPlex 9020
| > hw.perfpolicy=auto
| > hw.setperf=100
| > hw.cpuspeed=3401
| >
| > If I'd want to use the old behavior on "non laptop" systems, what
| > would be the best approach to try to achieve that?  I mean, I can
| > revert the commit, but then I'm stuck with a frankenstein system.
| >
| > Would another "economy" perfpolicy be better, or would it make more
| > sense to try to divine the type of system and adjust accordingly?
| 
| From false premises straight to conclusions that we (OpenBSD) must do
| something.  Come on.

I wanted to look into this myself.  At least with the current code,
the 'auto' perfpolicy doesn't do much on "non laptop" systems: they're
always on AC, so the processor never scales back and the effect is
then the same as the 'high' setting.  I suppose I'll change those
systems back to run with 'high' and let the processor handle things
itself, from what I've learned now it seems that this knob is a bit
superfluous on my systems and I should stop tweaking it.

| I purchased every one of my machines to get the maximum performance out
| of them when they are doing work, and I expect everyone else is in the
| same group.  Otherwise they would have saved money by buying slower
| machines.  Lucky for us that modern cpus do this automatically.

Right, I thought that was what 'auto' did: scale up the frequency when
the machine was doing work so it would have it done faster and then
scale down again, saving power / reducing heat in the process.  I
understand now that this happens anyway.

Thanks again for the cluestick.

Paul

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

New hw.perfpolicy behavior

[Paul de Weerd]

A recent commit by Theo changed the hw.perfpolicy behavior to always
run at full speed when AC power is on.  This means that my workstation
(and servers, once I upgrade them) now consumes significantly more
power, even though they usually idle.

[weerd@pom] $ sysctl hw.{vendor,product,perfpolicy,setperf,cpuspeed}
hw.vendor=Dell Inc.
hw.product=OptiPlex 9020
hw.perfpolicy=auto
hw.setperf=100
hw.cpuspeed=3401

If I'd want to use the old behavior on "non laptop" systems, what
would be the best approach to try to achieve that?  I mean, I can
revert the commit, but then I'm stuck with a frankenstein system.

Would another "economy" perfpolicy be better, or would it make more
sense to try to divine the type of system and adjust accordingly?

Paul

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

Re: Unwind + NSD usage question

[Paul de Weerd]

On Tue, Sep 28, 2021 at 12:25:30PM +0200, Paul de Weerd wrote:
| Otto's answer is a good solution, but I wanted to share mine:

Read Otto's answer too fast - he's basically talking about the same
solution I think.

Unbound has another alternative where you configure it to serve
specific records authoritatively from its own configuration (which is
what I thought Otto was talking about).  Search for 'local-data:' and
'local-data-ptr:' in unbound.conf(5):

http://man.openbsd.org/unbound.conf#local~2
http://man.openbsd.org/unbound.conf#local~3

Cheers,

Paul

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

Re: Unwind + NSD usage question

[Paul de Weerd]

Hi,

Why do you set your NSD as a forwarder?  How is unbound supposed to
know what queires should go to your NSD versus the rest of the
internet?

Otto's answer is a good solution, but I wanted to share mine:

If you have your NSD setup running to only serve those
'router.home.arpa' records and rDNS for your addresses, you could
configure unbound to request those from the local NSD, while taking
the rest from the internet:

local-zone: "10.in-addr.arpa." nodefault

stub-zone:
name: router.home.arpa
stub-addr: 127.0.0.1@10053

stub-zone:
name: 10.in-addr.arpa
stub-addr: 127.0.0.1@10053

That's exactly what I do (well, my zones differ, and my NSD listens on
::1@54, but you get my point) and it works very well.

Paul 'WEiRD' de Weerd

On Mon, Sep 27, 2021 at 08:50:06PM -0400, abyx...@mnetic.ch wrote:
| Hello, trying to set up unwind with nsd on the same machine serving
| a internal domain (home.arpa) with all my machines being part of
| that domain, eg router.home.arpa. If I point dig at my nsd instance
| (dig @127.0.0.1 -p 10053 router.home.arpa. A) I see my subdomains in
| the zone all being returned (router.home.arpa. -> 10.0.0.1). If I
| set nsd as a forwarder in unwind.conf (forwarder 127.0.0.1 port
| 10053) though, things get weird. My ISP doesn't return any results
| for home.arpa but some other servers (quad9 and cloudfare?) return a
| blackhole address pointing to prisoner.iana.org. If I limit unwind
| to preference {forwarder recursor} I now get my local nsd results
| for my domains as expected. If I comment out the preference line,
| unwind eventually learns a server that will answer to home.arpa with
| the blackhole prisoner.iana.org address (at least a minute in,
| sometimes longer, makes testing difficult). The use of force
| forwarder {home.arpa} and force accept bogus forwarder {home.arpa}
| don't appear to have any effect at all. (Full configs and dmesg
| below). 
| 
| I dug through the code a bit, if I'm following it correctly in
| sbin/unwind/resolver.c:check_resolver_done, nsd seems to be
| returning a SERVFAIL and being marked dead (as confirmed with
| unwindctl status. I am not sure I followed the code correctly at
| this point, but being set to DEAD and/or returning a SERVFAIL seems
| to preempt the use of force accept bogus. I am not sure what test
| unwind/libunbound are doing to check the health status of the
| different resolvers but I have yet to see my nsd forwarder not
| marked as "dead" in unwindctl status. Any ideas on how to debug
| this? This happens on both 6.9 and -current. The -current dmesg is
| posted below. 
| 
| 
| 
| ---
| router# cat /etc/unwind.conf  
 
| forwarder {
| 127.0.0.1 port 10053
| }
| 
| force accept bogus forwarder { home.arpa }
| #force autoconf { home.arpa }
| preference { forwarder recursor }
| #preference { recursor DoT forwarder }
| ---
| 
| 
| ---
| router# cat /var/nsd/etc/nsd.conf 
 
| # $OpenBSD: nsd.conf,v 1.13 2018/08/16 17:59:12 florian Exp $
| 
| server:
| hide-version: yes
| verbosity: 1
| database: "" # disable database
| 
| ## bind to a specific address/port
| ip-address: 127.0.0.1@10053
| 
| ## make packets as small as possible, on by default
| #   minimal-responses: yes
| 
| ## respond with truncation for ANY queries over UDP and allow ANY over TCP,
| ## on by default
| #   refuse-any: yes
| 
| remote-control:
| control-enable: yes
| control-interface: /var/run/nsd.sock
| 
| zone:
| name: "home.arpa."
| zonefile: "master/home.arpa"
| ---
| 
| 
| ---
| router# unwindctl status  
 
| 1. recursorvalidating,  30ms   2. forwarder dead,  15ms
| 
|   histograms: lifetime[ms], decaying[ms]
|  <10   <20   <40   <60   <80  <100  <200  <400  <600  <800 <1000 >
|   rec   1634  1008  1014   619   292   339   973   667   15626 7 1
|   1614 8 6 1 3 6 5 0 0 0 0
|  forw   223886 0 0 0 0 0 0 0 0 0 0
|   19 0 0 0 0 0 0 0 0 0 0 0
| ---
| 
| 
| ---
| router# dig @127.0.0.1 home.arpa. A
| 
| ; <<>> dig 9.10.8-P1 <<>> @127.0.0.1 home.arpa. A
| ; (1 server found)
| ;; global options: +cmd
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41102
| ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
| 
| ;; QUESTION SECTION:
| ;home.arpa. IN  A
| 
| ;; ANSWER SECTION:
| home.arpa.  413 IN  A   10.0.0.1
| 
| ;; Query time: 62 msec
| ;; SERVER: 127.0.0.1#53(127.0.0.1)
| ;; WHEN: Mon Sep 27 20:46:38 EDT 2021
| ;; MSG SIZE  rcvd: 43
| ---
| 
| 
| ---
| router# dig 

Re: allow KARL with config(8)'d kernels

[Paul de Weerd]

On Tue, Sep 07, 2021 at 07:57:55PM +0200, Robert Nagy wrote:
| On 07/09/21 19:31 +0200, Paul de Weerd wrote:
| > Hi all,
| > 
| > On Tue, Sep 07, 2021 at 02:30:43PM +0200, Robert Nagy wrote:
| > | /etc/reorder_kernel.conf
| > 
| > Thank you for your suggest Robert!  In the mean time, I've had a few
| > more off-list comments about this proposal - generally favorable, but
| > no better suggestions have come along.  After some more off-list
| > discussion, I'm now proposing the below diff.  It uses Theo's original
| > suggestion of /etc/bsd.re-config.
| 
| Hi
| 
| I would prefer to have -f in both tests, because install.sub is using -e
| now.

Ugh - my bad, sorry.

Fixed:


Index: libexec/reorder_kernel/reorder_kernel.sh
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
retrieving revision 1.9
diff -u -p -r1.9 reorder_kernel.sh
--- libexec/reorder_kernel/reorder_kernel.sh28 Sep 2019 17:30:07 -  
1.9
+++ libexec/reorder_kernel/reorder_kernel.sh7 Sep 2021 16:12:07 -
@@ -63,6 +63,7 @@ fi
 
 cd $KERNEL_DIR/$KERNEL
 make newbsd
+[ -f /etc/bsd.re-config ] && config -e -c /etc/bsd.re-config -f bsd
 make newinstall
 sync
 
Index: libexec/reorder_kernel/bsd.re-config.5
===
RCS file: libexec/reorder_kernel/bsd.re-config.5
diff -N libexec/reorder_kernel/bsd.re-config.5
--- /dev/null   1 Jan 1970 00:00:00 -
+++ libexec/reorder_kernel/bsd.re-config.5  7 Sep 2021 16:16:28 -
@@ -0,0 +1,46 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2021 Paul de Weerd 
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: August 24 2021 $
+.Dt KERNEL.CONF 5
+.Os
+.Sh NAME
+.Nm bsd.re-config
+.Nd kernel configuration file
+.Sh DESCRIPTION
+The
+.Nm
+file contains configuration information for the kernel.
+If present, it is used during system startup to configure the kernel
+that will be running at the next boot.
+It can be used to enable or disable specific devices in the kernel.
+.Sh EXAMPLES
+To enable the
+.Xr ipmi 4
+driver, add the following line to
+.Nm :
+.Pp
+.Dl enable ipmi
+.Pp
+See 
+.Xr config 8
+for more details on how to configure the kernel.
+.Sh FILES
+.Bl -tag -width /etc/bsd.re-config -compact
+.It Pa /etc/bsd.re-config
+Kernel configuration file.
+.Sh SEE ALSO
+.Xr config 8
Index: libexec/reorder_kernel/Makefile
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- libexec/reorder_kernel/Makefile 21 Aug 2017 21:24:11 -  1.1
+++ libexec/reorder_kernel/Makefile 7 Sep 2021 16:11:13 -
@@ -1,6 +1,7 @@
 #  $OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
 
 SCRIPT=reorder_kernel.sh
+MAN=   bsd.re-config.5
 
 realinstall:
${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
Index: distrib/miniroot/install.sub
===
RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1175
diff -u -p -r1.1175 install.sub
--- distrib/miniroot/install.sub29 Aug 2021 13:31:52 -  1.1175
+++ distrib/miniroot/install.sub7 Sep 2021 18:00:52 -
@@ -2857,7 +2857,10 @@ finish_up() {
tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
rm -f $_kernel_dir.tgz
chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
-   make newbsd; make newinstall"
+   make newbsd; \
+   [ -f /etc/bsd.re-config ] && \
+   config -e -c /etc/bsd.re-config -f bsd; \
+   make newinstall"
) >/dev/null 2>&1 && echo " done." || echo " failed."
fi
 
Index: etc/changelist
===
RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
retrieving revision 1.128
di

Re: allow KARL with config(8)'d kernels

[Paul de Weerd]

Hi all,

On Tue, Sep 07, 2021 at 02:30:43PM +0200, Robert Nagy wrote:
| /etc/reorder_kernel.conf

Thank you for your suggest Robert!  In the mean time, I've had a few
more off-list comments about this proposal - generally favorable, but
no better suggestions have come along.  After some more off-list
discussion, I'm now proposing the below diff.  It uses Theo's original
suggestion of /etc/bsd.re-config.

The diff includes:

- the change to reorder_kernel, including a manpage for the file
- the change to install.sub, so it works across installs and upgrades
- references to the new manpage from config(8) and boot_config(8)
- the changelist addition

Any further feedback?

Thanks,

Paul

Index: libexec/reorder_kernel/reorder_kernel.sh
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
retrieving revision 1.9
diff -u -p -r1.9 reorder_kernel.sh
--- libexec/reorder_kernel/reorder_kernel.sh28 Sep 2019 17:30:07 -  
1.9
+++ libexec/reorder_kernel/reorder_kernel.sh7 Sep 2021 16:12:07 -
@@ -63,6 +63,7 @@ fi
 
 cd $KERNEL_DIR/$KERNEL
 make newbsd
+[ -f /etc/bsd.re-config ] && config -e -c /etc/bsd.re-config -f bsd
 make newinstall
 sync
 
Index: libexec/reorder_kernel/bsd.re-config.5
===
RCS file: libexec/reorder_kernel/bsd.re-config.5
diff -N libexec/reorder_kernel/bsd.re-config.5
--- /dev/null   1 Jan 1970 00:00:00 -
+++ libexec/reorder_kernel/bsd.re-config.5  7 Sep 2021 16:16:28 -
@@ -0,0 +1,46 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2021 Paul de Weerd 
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: August 24 2021 $
+.Dt KERNEL.CONF 5
+.Os
+.Sh NAME
+.Nm bsd.re-config
+.Nd kernel configuration file
+.Sh DESCRIPTION
+The
+.Nm
+file contains configuration information for the kernel.
+If present, it is used during system startup to configure the kernel
+that will be running at the next boot.
+It can be used to enable or disable specific devices in the kernel.
+.Sh EXAMPLES
+To enable the
+.Xr ipmi 4
+driver, add the following line to
+.Nm :
+.Pp
+.Dl enable ipmi
+.Pp
+See 
+.Xr config 8
+for more details on how to configure the kernel.
+.Sh FILES
+.Bl -tag -width /etc/bsd.re-config -compact
+.It Pa /etc/bsd.re-config
+Kernel configuration file.
+.Sh SEE ALSO
+.Xr config 8
Index: libexec/reorder_kernel/Makefile
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- libexec/reorder_kernel/Makefile 21 Aug 2017 21:24:11 -  1.1
+++ libexec/reorder_kernel/Makefile 7 Sep 2021 16:11:13 -
@@ -1,6 +1,7 @@
 #  $OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
 
 SCRIPT=reorder_kernel.sh
+MAN=   bsd.re-config.5
 
 realinstall:
${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
Index: distrib/miniroot/install.sub
===
RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1175
diff -u -p -r1.1175 install.sub
--- distrib/miniroot/install.sub29 Aug 2021 13:31:52 -  1.1175
+++ distrib/miniroot/install.sub7 Sep 2021 16:10:30 -
@@ -2857,7 +2857,10 @@ finish_up() {
tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
rm -f $_kernel_dir.tgz
chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
-   make newbsd; make newinstall"
+   make newbsd; \
+   [ -e /etc/bsd.re-config ] && \
+   config -e -c /etc/bsd.re-config -f bsd; \
+   make newinstall"
) >/dev/null 2>&1 && echo " done." || echo " failed."
fi
 
Index: etc/changelist
===
RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
retrieving revision 1.128
diff -u -p -r1.128 cha

Re: allow KARL with config(8)'d kernels

[Paul de Weerd]

Thank you for the suggestion Theo, I tried to update those two pages,
but a better name did not occur to me.  If anything it points at an
issue in the boot_config page which currently states: 

"Changes made can be saved for the next reboot, by using config(8)."

Although true, this breaks KARL with the user non the wiser (they may
not even be aware of the feature in the first place).  The diff below
talks a little bit about kernel relinking; I'm not sure it should (I
don't think there's mention of this elsewhere .. should it be left
out?).

Anyway, I'm a bit stuck with this project now.  Perhaps Theo's
suggestion /etc/bsd.re-config [1] is the best way to go?  The age-old
axiom of "only two hard problems in computer science" persists:
off-by-one's, cache invalidation .. and naming things :-/

Paul

[1]: https://marc.info/?l=openbsd-tech=163024631923964=2

Index: ./usr.sbin/config/config.8
===
RCS file: /home/OpenBSD/cvs/src/usr.sbin/config/config.8,v
retrieving revision 1.71
diff -u -p -r1.71 config.8
--- ./usr.sbin/config/config.8  8 Mar 2021 02:47:29 -   1.71
+++ ./usr.sbin/config/config.8  31 Aug 2021 19:17:43 -
@@ -65,6 +65,11 @@ Similarly, the same editing can be done 
 using the in-kernel editor,
 as described in
 .Xr boot_config 8 .
+Note that any such edits will be lost during upgrades and prevent a newly
+linked kernel from being installed at boot time.
+For such cases, this process can also be automated during boot using the
+.Xr kernel.conf 5
+configuration file.
 .Pp
 For kernel building, the options are as follows:
 .Bl -tag -width Ds
@@ -436,6 +441,7 @@ was given, else ignore changes).
 .Sh SEE ALSO
 .Xr options 4 ,
 .Xr files.conf 5 ,
+.Xr kernel.conf 5,
 .Xr boot.conf 8 ,
 .Xr boot_config 8
 .Pp
Index: ./share/man/man8/boot_config.8
===
RCS file: /home/OpenBSD/cvs/src/share/man/man8/boot_config.8,v
retrieving revision 1.31
diff -u -p -r1.31 boot_config.8
--- ./share/man/man8/boot_config.8  6 Sep 2019 21:30:32 -   1.31
+++ ./share/man/man8/boot_config.8  31 Aug 2021 19:17:20 -
@@ -60,6 +60,12 @@ UKC>
 .Pp
 Changes made can be saved for the next reboot, by using
 .Xr config 8 .
+However, those would not be persisted across system upgrades and would
+prevent kernel relinking.
+To ensure these changes are carried over to upgraded kernels, they can
+be save to the
+.Xr kernel.conf 5
+configuration file.
 .Sh COMMANDS
 .Bl -tag -width "disable devno | dev"
 .It Ic add Ar dev
@@ -189,6 +195,7 @@ Continuing...
 mainbus0 (root)
 .Ed
 .Sh SEE ALSO
+.Xr kernel.conf 5
 .Xr config 8
 .Sh AUTHORS
 .An Mats O Jansson Aq Mt m...@stacken.kth.se

On Sun, Aug 29, 2021 at 07:30:02AM -0600, Theo de Raadt wrote:
| man -k kernel, and man -k ukc, both suggest these are poor names
| for different reasons.
| 
| maybe if you write some diffs to hint at the existance of this mechanism
| in the config(8) and boot_config(8) manual pages, a better name will
| sneak up on us.
| 
| Paul de Weerd  wrote:
| 
| > Hi Theo,
| > 
| > That's a good point, but I have no better alternative.  kernel.conf
| > was the best I could come up with, as it is a configuration file for
| > the (installed) kernel.  I briefly considered:
| > 
| > - config.conf (after config(8), but seems hilariously worse to me)
| > - ukc.conf (has similar (perhaps even stronger) issues as kernel.conf)
| > 
| > Do others have a good suggestion for the color of this particular bike
| > shed?  Open to suggestions!
| > 
| > Paul
| > 
| > On Sun, Aug 29, 2021 at 07:15:34AM -0600, Theo de Raadt wrote:
| > | I am not thrilled with the name "kernel.conf".
| > | 
| > | It does not seem intuitively discoverable.
| > | 
| > | Paul de Weerd  wrote:
| > | 
| > | > Got some more positive feedback off-list, which reminded me that
| > | > there's a small piece missing:
| > | > 
| > | > Index: changelist
| > | > ===
| > | > RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
| > | > retrieving revision 1.128
| > | > diff -u -p -r1.128 changelist
| > | > --- changelist  30 Jul 2021 07:00:02 -  1.128
| > | > +++ changelist  29 Aug 2021 12:12:04 -
| > | > @@ -56,6 +56,7 @@
| > | >  +/etc/isakmpd/isakmpd.policy
| > | >  /etc/isakmpd/local.pub
| > | >  +/etc/isakmpd/private/local.key
| > | > +/etc/kernel.conf
| > | >  /etc/ksh.kshrc
| > | >  /etc/ldapd.conf
| > | >  /etc/ldpd.conf
| > | > 
| > | > Full diff (including the original diff, the diff to install.sub and
| > | > the above changelist diff) below.  Anything else I overlooked?
| > | > 
| > | > Paul
| > | > 
| > | > Index: distrib/miniro

reduce debug logging from slowcgi

[Paul de Weerd]

Hi all,

On a busy-ish site, I found that slowcgi is doing quite excessive
logging: every single environment variable is logged on a separate
logline.  There's at least 17 variables per hit, but I've seen it go
up to 35.  If you're writing debug logs from syslog, that adds up
rather quickly.  Of course you can argue "don't do that", but why have
the system do all this work of sending stuff through syslog when
you're not going to anything with it anyway?

Anyway, after a hint from Florian, I added a -v flag to slowcgi to
only log syslog events at the DEBUG level when it's given and not
always / by default.  It's good to be able to log these when you're
debugging issues, but then you'll have to add '-v' to the
slowcgi_flags in /etc/rc.conf.local using rcctl(8).

I've tested this on that busy-ish setup - works for me (tm).

Cheers,

Paul 'WEiRD' de Weerd

Index: slowcgi.8
===
RCS file: /home/OpenBSD/cvs/src/usr.sbin/slowcgi/slowcgi.8,v
retrieving revision 1.14
diff -u -p -r1.14 slowcgi.8
--- slowcgi.8   13 Aug 2018 16:54:50 -  1.14
+++ slowcgi.8   31 Aug 2021 13:10:42 -
@@ -27,6 +27,7 @@
 .Op Fl s Ar socket
 .Op Fl U Ar user
 .Op Fl u Ar user
+.Op Fl v
 .Sh DESCRIPTION
 .Nm
 is a server which implements the FastCGI Protocol to execute CGI scripts.
@@ -90,6 +91,8 @@ instead of default user www and
 to
 the home directory of
 .Ar user .
+.It Fl v
+Enable more verbose (debug) logging.
 .El
 .Sh SEE ALSO
 .Xr httpd 8
Index: slowcgi.c
===
RCS file: /home/OpenBSD/cvs/src/usr.sbin/slowcgi/slowcgi.c,v
retrieving revision 1.60
diff -u -p -r1.60 slowcgi.c
--- slowcgi.c   20 Apr 2021 07:35:42 -  1.60
+++ slowcgi.c   31 Aug 2021 13:08:37 -
@@ -260,6 +260,7 @@ usage(void)
 struct timeval timeout = { TIMEOUT_DEFAULT, 0 };
 struct slowcgi_procslowcgi_proc;
 intdebug = 0;
+intverbose = 0;
 inton = 1;
 char   *fcgi_socket = "/var/www/run/slowcgi.sock";
 
@@ -292,7 +293,7 @@ main(int argc, char *argv[])
}
}
 
-   while ((c = getopt(argc, argv, "dp:s:U:u:")) != -1) {
+   while ((c = getopt(argc, argv, "dp:s:U:u:v")) != -1) {
switch (c) {
case 'd':
debug++;
@@ -309,6 +310,9 @@ main(int argc, char *argv[])
case 'u':
slowcgi_user = optarg;
break;
+   case 'v':
+   verbose++;
+   break;
default:
usage();
/* NOTREACHED */
@@ -1261,9 +1265,10 @@ syslog_info(const char *fmt, ...)
 void
 syslog_debug(const char *fmt, ...)
 {
-   va_list ap;
-
-   va_start(ap, fmt);
-   vsyslog(LOG_DEBUG, fmt, ap);
-   va_end(ap);
+   if (verbose > 0) {
+   va_list ap;
+   va_start(ap, fmt);
+   vsyslog(LOG_DEBUG, fmt, ap);
+   va_end(ap);
+   }
 }


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

Re: allow KARL with config(8)'d kernels

[Paul de Weerd]

Hi Theo,

That's a good point, but I have no better alternative.  kernel.conf
was the best I could come up with, as it is a configuration file for
the (installed) kernel.  I briefly considered:

- config.conf (after config(8), but seems hilariously worse to me)
- ukc.conf (has similar (perhaps even stronger) issues as kernel.conf)

Do others have a good suggestion for the color of this particular bike
shed?  Open to suggestions!

Paul

On Sun, Aug 29, 2021 at 07:15:34AM -0600, Theo de Raadt wrote:
| I am not thrilled with the name "kernel.conf".
| 
| It does not seem intuitively discoverable.
| 
| Paul de Weerd  wrote:
| 
| > Got some more positive feedback off-list, which reminded me that
| > there's a small piece missing:
| > 
| > Index: changelist
| > ===
| > RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
| > retrieving revision 1.128
| > diff -u -p -r1.128 changelist
| > --- changelist  30 Jul 2021 07:00:02 -  1.128
| > +++ changelist  29 Aug 2021 12:12:04 -
| > @@ -56,6 +56,7 @@
| >  +/etc/isakmpd/isakmpd.policy
| >  /etc/isakmpd/local.pub
| >  +/etc/isakmpd/private/local.key
| > +/etc/kernel.conf
| >  /etc/ksh.kshrc
| >  /etc/ldapd.conf
| >  /etc/ldpd.conf
| > 
| > Full diff (including the original diff, the diff to install.sub and
| > the above changelist diff) below.  Anything else I overlooked?
| > 
| > Paul
| > 
| > Index: distrib/miniroot/install.sub
| > ===
| > RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
| > retrieving revision 1.1172
| > diff -u -p -r1.1172 install.sub
| > --- distrib/miniroot/install.sub9 Aug 2021 13:56:17 -   1.1172
| > +++ distrib/miniroot/install.sub25 Aug 2021 19:42:49 -
| > @@ -2857,7 +2857,10 @@ finish_up() {
| > tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
| > rm -f $_kernel_dir.tgz
| > chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
| > -   make newbsd; make newinstall"
| > +   make newbsd; \
| > +   [ -e /etc/kernel.conf ] && \
| > +   config -e -c /etc/kernel.conf -f bsd; \
| > +   make newinstall"
| > ) >/dev/null 2>&1 && echo " done." || echo " failed."
| > fi
| >  
| > Index: etc/changelist
| > ===
| > RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
| > retrieving revision 1.128
| > diff -u -p -r1.128 changelist
| > --- etc/changelist  30 Jul 2021 07:00:02 -  1.128
| > +++ etc/changelist  29 Aug 2021 12:12:04 -
| > @@ -56,6 +56,7 @@
| >  +/etc/isakmpd/isakmpd.policy
| >  /etc/isakmpd/local.pub
| >  +/etc/isakmpd/private/local.key
| > +/etc/kernel.conf
| >  /etc/ksh.kshrc
| >  /etc/ldapd.conf
| >  /etc/ldpd.conf
| > Index: libexec/reorder_kernel/Makefile
| > ===
| > RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
| > retrieving revision 1.1
| > diff -u -p -r1.1 Makefile
| > --- libexec/reorder_kernel/Makefile 21 Aug 2017 21:24:11 -  1.1
| > +++ libexec/reorder_kernel/Makefile 24 Aug 2021 07:23:38 -
| > @@ -1,6 +1,7 @@
| >  #  $OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
| >  
| >  SCRIPT=reorder_kernel.sh
| > +MAN=   kernel.conf.5
| >  
| >  realinstall:
| > ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
| > Index: libexec/reorder_kernel/kernel.conf.5
| > ===
| > RCS file: libexec/reorder_kernel/kernel.conf.5
| > diff -N libexec/reorder_kernel/kernel.conf.5
| > --- /dev/null   1 Jan 1970 00:00:00 -
| > +++ libexec/reorder_kernel/kernel.conf.524 Aug 2021 07:23:07 -
| > @@ -0,0 +1,46 @@
| > +.\"$OpenBSD$
| > +.\"
| > +.\" Copyright (c) 2021 Paul de Weerd 
| > +.\"
| > +.\" Permission to use, copy, modify, and distribute this software for any
| > +.\" purpose with or without fee is hereby granted, provided that the above
| > +.\" copyright notice and this permission notice appear in all copies.
| > +.\"
| > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL 
WARRANTIES
| > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
| > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
| > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|

Re: allow KARL with config(8)'d kernels

[Paul de Weerd]

Got some more positive feedback off-list, which reminded me that
there's a small piece missing:

Index: changelist
===
RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
retrieving revision 1.128
diff -u -p -r1.128 changelist
--- changelist  30 Jul 2021 07:00:02 -  1.128
+++ changelist  29 Aug 2021 12:12:04 -
@@ -56,6 +56,7 @@
 +/etc/isakmpd/isakmpd.policy
 /etc/isakmpd/local.pub
 +/etc/isakmpd/private/local.key
+/etc/kernel.conf
 /etc/ksh.kshrc
 /etc/ldapd.conf
 /etc/ldpd.conf

Full diff (including the original diff, the diff to install.sub and
the above changelist diff) below.  Anything else I overlooked?

Paul

Index: distrib/miniroot/install.sub
===
RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1172
diff -u -p -r1.1172 install.sub
--- distrib/miniroot/install.sub9 Aug 2021 13:56:17 -   1.1172
+++ distrib/miniroot/install.sub25 Aug 2021 19:42:49 -
@@ -2857,7 +2857,10 @@ finish_up() {
tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
rm -f $_kernel_dir.tgz
chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
-   make newbsd; make newinstall"
+   make newbsd; \
+   [ -e /etc/kernel.conf ] && \
+   config -e -c /etc/kernel.conf -f bsd; \
+   make newinstall"
) >/dev/null 2>&1 && echo " done." || echo " failed."
fi
 
Index: etc/changelist
===
RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
retrieving revision 1.128
diff -u -p -r1.128 changelist
--- etc/changelist  30 Jul 2021 07:00:02 -  1.128
+++ etc/changelist  29 Aug 2021 12:12:04 -
@@ -56,6 +56,7 @@
 +/etc/isakmpd/isakmpd.policy
 /etc/isakmpd/local.pub
 +/etc/isakmpd/private/local.key
+/etc/kernel.conf
 /etc/ksh.kshrc
 /etc/ldapd.conf
 /etc/ldpd.conf
Index: libexec/reorder_kernel/Makefile
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- libexec/reorder_kernel/Makefile 21 Aug 2017 21:24:11 -  1.1
+++ libexec/reorder_kernel/Makefile 24 Aug 2021 07:23:38 -
@@ -1,6 +1,7 @@
 #  $OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
 
 SCRIPT=reorder_kernel.sh
+MAN=   kernel.conf.5
 
 realinstall:
${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
Index: libexec/reorder_kernel/kernel.conf.5
===
RCS file: libexec/reorder_kernel/kernel.conf.5
diff -N libexec/reorder_kernel/kernel.conf.5
--- /dev/null   1 Jan 1970 00:00:00 -
+++ libexec/reorder_kernel/kernel.conf.524 Aug 2021 07:23:07 -
@@ -0,0 +1,46 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2021 Paul de Weerd 
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: August 24 2021 $
+.Dt KERNEL.CONF 5
+.Os
+.Sh NAME
+.Nm kernel.conf
+.Nd kernel configuration file
+.Sh DESCRIPTION
+The
+.Nm
+file contains configuration information for the kernel.
+If present, it is used during system startup to configure the kernel
+that will be running at the next boot.
+It can be used to enable or disable specific devices in the kernel.
+.Sh EXAMPLES
+To enable the
+.Xr ipmi 4
+driver, add the following line to
+.Nm :
+.Pp
+.Dl enable ipmi
+.Pp
+See 
+.Xr config 8
+for more details on how to configure the kernel.
+.Sh FILES
+.Bl -tag -width /etc/kernel.conf -compact
+.It Pa /etc/kernel.conf
+Kernel configuration file.
+.Sh SEE ALSO
+.Xr config 8
Index: libexec/reorder_kernel/reorder_kernel.sh
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
retrieving revision 1.9
diff -u -p -r1.9 reorder_kernel.sh
--- libexec/reorder_kernel/reorder_

Re: allow KARL with config(8)'d kernels

[Paul de Weerd]

Robert, Sebastien and Stuart,

Thanks for your constructive and postive feedback.  Combined with some
off-list (positive) feedback, it suggests this is at least worth
further consideration.

On Tue, Aug 24, 2021 at 08:05:37PM +0200, Robert Nagy wrote:
| I am happy to see this. All for it. Did you check all the error cases
| to make sure that reorder_kernel will report what needs to be reported?

Well, the thing I checked was that reorder_kernel sets errexit.  So if
an error does occur during the config(8) run that gets added with the
diff, it will get reported as usual.

- no /etc/kernel.conf -> works as expected
- proper /etc/kernel.conf -> works as expected
- full partition -> config still is able to change the kernel

- faulty /etc/kernel.conf -> no new kernel, logged to console

On Wed, Aug 25, 2021 at 10:35:19AM +0200, Sebastien Marie wrote:
| - does it integrate well with syspatch ?
| 
|   yes, syspatch will call /usr/libexec/reorder_kernel (and the
|   configuration will be applied)

Yes, I did consider this case and figured it would be fine as syspatch
just runs reorder_kernel (and even checks its exit status).

| - after install or upgrade, does the installed kernel (by installer)
|   has the configuration applied ?
| 
|   it seems not: install.sub has it owns logic and is directly calling
|   "make newbsd ; make install" and do not use reorder_kernel script.

Looking just now, install.sub runs in a chroot of the freshly
installed / upgraded system, and issues make newbsd and make
newinstall.  Fixing that would be as straightforward as the original
diff.  Since there seems to be general interest in my original diff,
I've included such a diff below (not sure if this should be a separate
commit or not).

|   I could see reason to avoid it, and reason to requiring it.
| 
| 
|   For install, no problem: the file is controlled (it doesn't
|   exist). It doesn't change anything.

Personally, I don't see a reason to avoid it.  For install, it could
exist.  site.tgz could install an /etc/kernel.conf, for those users
that need to configure their kernels to have them work after the
initial install (this will help automated installs where the operator
already knows in advance that their kernel will need some further
configuration).

|   For upgrade, the file could exists. Should the installer using it or
|   not ?
| 
| 
|   If using it, it makes the upgrade process dependent of the file: how
|   to deal with an invalid file ? should the file ignored (kernel
|   installed but not configured) ?

If you have a broken /etc/kernel.conf, it'll never work.  A bit like
screwing up your /etc/boot.conf - you get to keep all pieces of your
broken system.

|   how to deal with a format change in config(8) (file on disk in old
|   format, used config(8) understanding new format) ? but config(8)
|   doesn't change often, and could take care of both formats for one
|   release, and/or current.html could mention some required changes.

This is a good point, something I didn't consider.  But I agree with
your arguments here - seems like something that a) wouldn't happen
frequently and b) can be dealt with when it does.

On Wed, Aug 25, 2021 at 11:32:36AM +0100, Stuart Henderson wrote:
| Somebody had an earlier method for applying kernel config changes
| automatically that IIRC used a bootloader based mechanism passing the
| config to the kernel. I think that might actually be better overall
| as you could bypass it at the boot loader (rather than requiring a
| backup "clean" kernel) though that's more work and I expect difficult
| to do within space constraints on some archs.

I readily agree that that sounds like a better approach to me.
However, that approach is beyond my current skillset, I had an itch to
scratch, and this was my (relatively unintrusive) solution.

The diff below for install.sub has not been tested (yet).

Thanks again,

Paul

Index: install.sub
===
RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1172
diff -u -p -r1.1172 install.sub
--- install.sub 9 Aug 2021 13:56:17 -   1.1172
+++ install.sub 25 Aug 2021 19:42:49 -
@@ -2857,7 +2857,10 @@ finish_up() {
tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
rm -f $_kernel_dir.tgz
chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
-   make newbsd; make newinstall"
+   make newbsd; \
+   [ -e /etc/kernel.conf ] && \
+   config -e -c /etc/kernel.conf -f bsd; \
+   make newinstall"
) >/dev/null 2>&1 && echo " done." || echo " failed."
fi
 


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

allow KARL with config(8)'d kernels

[Paul de Weerd]

I have a new machine where I'd like to use IPMI.  Of course, doing
`config -e -f /bsd` will break KARL, so I tried to find a minimal way
of supporting this.  Done by introducing a new config file,
/etc/kernel.conf, which gets applied to the kernel reorder_kernel
builds and installs.

Paul 'WEiRD' de Weerd

Index: reorder_kernel.sh
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
retrieving revision 1.9
diff -u -p -r1.9 reorder_kernel.sh
--- reorder_kernel.sh   28 Sep 2019 17:30:07 -  1.9
+++ reorder_kernel.sh   24 Aug 2021 07:01:10 -
@@ -63,6 +63,7 @@ fi
 
 cd $KERNEL_DIR/$KERNEL
 make newbsd
+[ -f /etc/kernel.conf ] && config -e -c /etc/kernel.conf -f bsd
 make newinstall
 sync
 
Index: Makefile
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- Makefile21 Aug 2017 21:24:11 -  1.1
+++ Makefile24 Aug 2021 07:23:38 -
@@ -1,6 +1,7 @@
 #  $OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
 
 SCRIPT=reorder_kernel.sh
+MAN=   kernel.conf.5
 
 realinstall:
${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
Index: kernel.conf.5
===
RCS file: kernel.conf.5
diff -N kernel.conf.5
--- /dev/null   1 Jan 1970 00:00:00 -
+++ kernel.conf.5   24 Aug 2021 07:23:07 -
@@ -0,0 +1,46 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2021 Paul de Weerd 
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: August 24 2021 $
+.Dt KERNEL.CONF 5
+.Os
+.Sh NAME
+.Nm kernel.conf
+.Nd kernel configuration file
+.Sh DESCRIPTION
+The
+.Nm
+file contains configuration information for the kernel.
+If present, it is used during system startup to configure the kernel
+that will be running at the next boot.
+It can be used to enable or disable specific devices in the kernel.
+.Sh EXAMPLES
+To enable the
+.Xr ipmi 4
+driver, add the following line to
+.Nm :
+.Pp
+.Dl enable ipmi
+.Pp
+See 
+.Xr config 8
+for more details on how to configure the kernel.
+.Sh FILES
+.Bl -tag -width /etc/kernel.conf -compact
+.It Pa /etc/kernel.conf
+Kernel configuration file.
+.Sh SEE ALSO
+.Xr config 8

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

Re: ucc(4): consumer control keyboard device driver

[Paul de Weerd]

Hi Anton,

Thanks - I've applied your diff and built a kernel with it.  Full
dmesg (both before and after) at the end of this mail, diff is:

-uhid2 at uhidev3 reportid 3: input=3, output=0, feature=0
+ucc0 at uhidev3 reportid 3 keys 24, mappings 7
+wskbd3 at ucc0 mux 1

-wskbd3 at ukbd2 mux 1
-uhid3 at uhidev5 reportid 3: input=4, output=0, feature=0
-uhid4 at uhidev5 reportid 4: input=1, output=0, feature=0
-uhidpp0 at uhidev5 reportid 16
+wskbd4 at ukbd2 mux 1
+ucc1 at uhidev5 reportid 3 keys 0, mappings 0
+uhid2 at uhidev5 reportid 4: input=1, output=0, feature=0
+uhidpp0 at uhidev5 reportid 16

That is with this keyboard:

[weerd@pom] $ dmesg | grep Metadot
uhidev2 at uhub3 port 4 configuration 1 interface 0 "Metadot - Das Keyboard Das 
Keyboard" rev 2.00/1.00 addr 4
uhidev3 at uhub3 port 4 configuration 1 interface 1 "Metadot - Das Keyboard Das 
Keyboard" rev 2.00/1.00 addr 4
[weerd@pom] $ usbdevs -v -a 04
addr 04: 24f0:0140 Metadot - Das Keyboard, Das Keyboard
 full speed, power 100 mA, config 1, rev 1.00
 driver: uhidev2
 driver: uhidev3

(there's a few more deltas that I'm leaving out due to an external
AHCI controller not being detected).

Anyway, I see two ucc(4) devices - not sure why that is; assuming it's
because the keyboard itself also shows up twice.  But at least the
volume control works.  Playing an audio file with mpd and turning the
big volume knob on my keyboard changes the volume (also indicated by
sndioctl(1).  The 'mute' button doesn't do anything, but I may have to
dig a bit more into how this works first.

I'll play around with this a bit more, but initial results look very
promising - thanks for this new driver!

Paul

--- dmesg before applying diff ---
OpenBSD 6.9-current (GENERIC.MP) #179: Wed Aug 11 22:49:10 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34243899392 (32657MB)
avail mem = 33190125568 (31652MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (88 entries)
bios0: vendor Dell Inc. version "A25" date 05/30/2019
bios0: Dell Inc. OptiPlex 9020
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT 
ASF! DMAR
acpi0: wakeup devices UAR1(S3) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP05(S4) 
PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) 
HDEF(S4) PEG0(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.99 MHz, 06-3c-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.49 MHz, 06-3c-03
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.48 MHz, 06-3c-03
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.48 MHz, 06-3c-03
cpu3: 

ntpd constraints and caching proxies (CDNs)

[Paul de Weerd]

Hi all,

I was investigating some 'unsupported date format' messages that ntpd
was logging and found that one constraint server served a time that
was quite a ways off from actual time.

Turns out that the website in question is fronted by some CDN that
caches the page, including the date:-header.  To account for this,
they add an age:-header that reflects when the page was last updated
from upstream.  These stale date:-headers could be problematic when
using them for ntpd constraints; the server I found was about 8
minutes behind the others, significantly more than
CONSTRAINT_ERROR_MARGIN (set to 4).

Of course, there are also CDNs that send a current date:-header *AND*
an age:-header - so I don't think this can be fixed in code by just
adding 'age:' seconds to the time learned from 'date:'.  Perhaps
comparing both 'date:' and 'date: + age:' with other constraints or
NTP time and then picking one of the two could work, but that way lies
madness, I fear.

For now, i've checked all constraints I have configured and removed
those that send an age:-header.  Of course any website may change to a
CDN at any time, so periodic checking makes sense.

Would it make sense to alert the user to this potential pitfall in the
manpage?  A first stab included below, although I'm not very happy
with the wording myself.

While looking into this, I also found a typo in a comment in
ntpd/client.c, a patch for that is also included.

Cheers,

Paul 'WEiRD' de Weerd

PS: In the end, the 'unsupported date format' was ANOTHER site that
sends "UTC" instead of "GMT" in the date:-header - also removed that
from my config.

[1]: http://man.openbsd.org/ntpd.conf#CONSTRAINTS

Index: ntpd.conf.5
===
RCS file: /home/OpenBSD/cvs/src/usr.sbin/ntpd/ntpd.conf.5,v
retrieving revision 1.47
diff -u -p -r1.47 ntpd.conf.5
--- ntpd.conf.5 6 Jan 2021 13:03:13 -   1.47
+++ ntpd.conf.5 4 Jun 2021 15:35:36 -
@@ -213,6 +213,8 @@ man-in-the-middle attacks.
 Received NTP packets with time information falling outside of a range
 near the constraint will be discarded and such NTP servers
 will be marked as invalid.
+Care must be taken to use HTTPS websites that aren't cached by CDNs
+or otherwise serve poor time.
 .Bl -tag -width Ds
 .It Ic constraint from Ar url [ip...]
 Specify the URL, IP address or the hostname of an HTTPS server to



Index: client.c
===
RCS file: /home/OpenBSD/cvs/src/usr.sbin/ntpd/client.c,v
retrieving revision 1.116
diff -u -p -r1.116 client.c
--- client.c21 Apr 2021 09:38:11 -  1.116
+++ client.c4 Jun 2021 15:59:04 -
@@ -267,7 +267,7 @@ handle_auto(uint8_t trusted, double offs
 
 /*
  * -1: Not processed, not an NTP message (e.g. icmp induced  ECONNREFUSED)
- *  0: Not prrocessed due to validation issues
+ *  0: Not processed due to validation issues
  *  1: NTP message validated and processed
  */
 int

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

Re: httpd(8): fastcgi & Content-Length: 0

[Paul de Weerd]

For the record: I tested this on a WordPress instance and it fixed the
problem for me.  It was also visible in roundcubemail and wikimedia
(firefox and safari showed the issue, chrome on the company laptop
did not).

Thanks Florian!

Paul

On Wed, May 19, 2021 at 08:44:47PM +0200, Florian Obser wrote:
| The whole point of using Transfer-Encoding: chunked for fastcgi was so
| that we do not need to provide a Content-Length header if upstream
| doesn't give us one. (We'd need to slurp in all the data ugh).
| 
| Now turns out that if we disable chunked encoding for zero sized bodies
| some browsers are picky and want a Content-Length: 0 (Firefox, Safari)
| or they'll just sit there and wait for the connection to close.
| 
| Problem reported by Matthias Pressfreund with wordpress.
| Debugged with the help of weerd@ who pointed out that the problem is
| actually browser dependent. From there it was pretty clear what the
| problem was.
| 
| OK?
| 
| diff --git server_fcgi.c server_fcgi.c
| index 31d7322e9f7..b9dc4f6fe04 100644
| --- server_fcgi.c
| +++ server_fcgi.c
| @@ -636,6 +636,13 @@ server_fcgi_header(struct client *clt, unsigned int code)
|   if (kv_add(>http_headers,
|   "Transfer-Encoding", "chunked") == NULL)
|   return (-1);
| + } else {
| + key.kv_key = "Content-Length";
| + if ((kv = kv_find(>http_headers, )) == NULL) {
| + if (kv_add(>http_headers,
| + "Content-Length", "0") == NULL)
| + return (-1);
| + }
|   }
|  
|   /* Is it a persistent connection? */
| 
| -- 
| I'm not entirely sure you are real.
| 

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

Re: setitimer(2): don't round up it_value

[Paul de Weerd]

Hi Scott,

Thanks for this work!  I see significant improvement with my test code
(see below; obviously focussing quite specificially on one thing).
Before your diff (snapshot from a few days ago; OpenBSD 6.9-current
(GENERIC.MP) #1: Mon May  3 11:04:25 MDT 2021) I got:

[weerd@pom] $ ./measure
Running for 100 loops

timeout  80us min/avg/max/std-dev: 800054/809727.250/810115/1609.611 us
timeout  40us min/avg/max/std-dev: 409668/41.406/410362/121.568 us
timeout  20us min/avg/max/std-dev: 209421/209997.953/210553/97.505 us
timeout  10us min/avg/max/std-dev: 109818/109997.078/110167/39.038 us
timeout   5us min/avg/max/std-dev: 59887/59995.539/60108/27.651 us
timeout   25000us min/avg/max/std-dev: 29648/29993.961/30316/50.629 us
timeout   12500us min/avg/max/std-dev: 19910/19994.100/20098/24.265 us
timeout6250us min/avg/max/std-dev: 19932/19994.020/20067/20.760 us
timeout3125us min/avg/max/std-dev: 19806/19993.980/20221/33.121 us
timeout1562us min/avg/max/std-dev: 19519/19993.971/20470/71.215 us
timeout 781us min/avg/max/std-dev: 19778/19993.980/20214/35.454 us
timeout 390us min/avg/max/std-dev: 19784/19994.029/20188/32.626 us
timeout 195us min/avg/max/std-dev: 19891/19994.230/20096/23.237 us
timeout  97us min/avg/max/std-dev: 19938/19994.170/20044/17.468 us
timeout  48us min/avg/max/std-dev: 19876/19994.010/20115/26.334 us
timeout  24us min/avg/max/std-dev: 19535/19994.199/20458/67.628 us
timeout  12us min/avg/max/std-dev: 19941/19994.240/20079/18.478 us
timeout   6us min/avg/max/std-dev: 19949/19994.150/20051/16.916 us
timeout   3us min/avg/max/std-dev: 19880/19994.221/20109/23.377 us
timeout   1us min/avg/max/std-dev: 19940/19994.289/20053/17.575 us

[I should add that these numbers are from an otherwise mostly idle
machine; they improved when my machine was busy building a new kernel]

After upgrading my local snap, cvs-up'ing, patching in your diff and
building + rebooting into a new kernel:

[weerd@pom] $ ./measure
Running for 100 loops

timeout  80us min/avg/max/std-dev: 800041/808010.312/810021/2992.553 us
timeout  40us min/avg/max/std-dev: 401639/402001.281/402373/-nan us
timeout  20us min/avg/max/std-dev: 200959/200997.922/201041/-nan us
timeout  10us min/avg/max/std-dev: 100456/100495.977/100533/37.185 us
timeout   5us min/avg/max/std-dev: 50141/50244.809/50351/30.089 us
timeout   25000us min/avg/max/std-dev: 28917/30144.590/31396/175.702 us
timeout   12500us min/avg/max/std-dev: 20048/20094.420/20143/10.583 us
timeout6250us min/avg/max/std-dev: 10016/10044.260/10084/9.683 us
timeout3125us min/avg/max/std-dev: 9974/10044.060/10140/14.810 us
timeout1562us min/avg/max/std-dev: 10016/10044.190/10078/6.827 us
timeout 781us min/avg/max/std-dev: 9964/10044.140/10143/14.516 us
timeout 390us min/avg/max/std-dev: 9578/10044.150/10507/66.234 us
timeout 195us min/avg/max/std-dev: 9981/10044.170/10122/16.570 us
timeout  97us min/avg/max/std-dev: 10010/10044.150/10117/10.721 us
timeout  48us min/avg/max/std-dev: 10004/10044.140/10083/10.331 us
timeout  24us min/avg/max/std-dev: 10016/10044.220/10078/6.487 us
timeout  12us min/avg/max/std-dev: 10014/10044.210/10079/6.802 us
timeout   6us min/avg/max/std-dev: 10013/10044.300/10085/9.871 us
timeout   3us min/avg/max/std-dev: 10007/10044.030/10090/8.477 us
timeout   1us min/avg/max/std-dev: 9980/10044.350/10135/13.301 us

(obviously some bug in the std-dev calculation there with the -nan)

Thanks again,

Paul

--- measure.c 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define LOOPCOUNT 100

volatile sig_atomic_t trigger;

void
sighdlr(int signum) {
trigger = signum;
}

int
main() {
int long long   count, d, sum, min, max, tsumsq;
longtimeout;
struct timeval  str, end;
struct itimervalnew_timer;
double  avg, dev;

new_timer.it_interval.tv_sec = 0;
new_timer.it_interval.tv_usec = 0;
new_timer.it_value.tv_sec = 0;

signal(SIGALRM, sighdlr);

printf("Running for %d loops\n\n", LOOPCOUNT);

for (timeout = 80; timeout != 0; timeout /= 2) {
new_timer.it_value.tv_usec = timeout;
min = 10;
max = 0;
sum = 0;
tsumsq = 0;
for (count = 0; count != LOOPCOUNT; count++) {
trigger = 0;
setitimer(ITIMER_REAL, _timer, NULL);
gettimeofday(, NULL);
while (trigger == 0)
pause();
gettimeofday(, NULL);
d = (end.tv_sec - str.tv_sec) * 100 + \
end.tv_usec - str.tv_usec;
sum += 

Re: find -exec util {} arg + confusion

[Paul de Weerd]

On Tue, Nov 17, 2020 at 01:06:05AM +0100, Alexander Hall wrote:
| On Mon, Nov 16, 2020 at 09:04:53AM +0100, Paul de Weerd wrote:
| > Hi Alexander,
| > 
| > On Sun, Nov 15, 2020 at 10:22:32PM +0100, Alexander Hall wrote:
| > | I googled for "POSIX find", and hit this:
| > | 
| > | https://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html
| > | 
| > | => "Only a plus sign that follows an argument containing the two
| > | characters "{}" shall punctuate the end of the primary expression.
| > | Other uses of the plus sign shall not be treated as special."
| > 
| > Yep, I also found that when looking into this.  It's unforunate, as it
| > implies you can't use `-exec {} ... +` with e.g. ln, mv or cp, but oh
| > well.
| > 
| > (also, nitpicking, 'an argument containing the two characters "{}"'
| > includes an argument like "hh}hh{hh", which I'm pretty sure is not
| > what they mean)
| > 
| > | What you do in your diff is exactly that, treating it special.
| > 
| > I'm not sure I agree.  I make sure I do not treat it special unless
|^^
| > it's at the end of the argument to 'exec'.  Can you elaborate on what
|   ^
| > you mean here?
| 
| If it is not following {}, then it should not be treated as such. You
| are assuming (or guessing) it was meant to be that special '+'.
| 
| Carefully crafted example of failing quoting of ';':
| 
| $ obj/find . -exec echo + ;# Just print a '+' for every entry
| find: -exec: "+" should follow {}

In this case, I would say the error is correct: the + *is* at the end
of the argument to exec, and for -exec to work with +, it should
follow {}.

Since you failed to escape the semi-colon, the shell (not find)
discards it (uses it to separate find from the next command), so find
never sees the ';', you're actually doing `find . -exec echo +`; the
plus doesn't follow the requisite {}.

I could change the diff to see if there is no {} at all (as in your
carefully crafted example), and change the output based on that again.
However, using the diff that you proposed earlier in this thread (that
results in 'no terminating ";" or "{} +"') is probably the best way
forward (less code, still clear what the issue is).

| The more I read and think about it, I feel the original error message is
| actually correct in that there is no terminating ";" or "+", since the
| required condition for it is not fullfilled...

I still think the error is confusing for the user who, familiar with
'find -exec command {} arg \;', might assume the same would work for +.
Now, your diff seems like a better approach, given your argument.

Paul

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

Re: find -exec util {} arg + confusion

[Paul de Weerd]

Hi Andreas,

On Mon, Nov 16, 2020 at 08:53:36AM +0100, Andreas Kusalananda Kähäri wrote:
| On Thu, Nov 12, 2020 at 08:51:22PM +0100, Paul de Weerd wrote:
| > Hi all,
| > 
| > I misread find(1) and did:
| > 
| > [weerdpom] $ find path/to/cam -name \*.JPG -exec cp {} path/to/store +
| > find: -exec no terminating ";" or "+"
| 
| Not really what you're asking for, but...
| 
| What you seem to want to do can be done with
| 
|   find path/to/cam -name '*.JPG' -exec sh -c 'cp "$@" path/to/store' sh 
{} +

Thanks, I've solved this in the past with small scripts in my homedir
or going to `find | xargs -J`.  I'll add your suggestion to my list.

| Or, with GNU coreutils installed,
| 
|   find path/to/cam -name '*.JPG' -exec gcp -t path/to/store {} +

Ugh, installing GNU stuff for something like this... :)  Besides, the
problem is more generic than just cp(1).  Do all GNU tools that (by
default) have the target argument as the last argument support -t?  I
mean, I know cp, mv and ln do, but do they all?

| I quite like Alexander's proposed smaller diff.

Making it more clear to the user that + must follow {} is the thing
I'd like to achieve, so yeah :)  No strong feelings over his vs my
diff.

Cheers,

Paul

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

Re: find -exec util {} arg + confusion

[Paul de Weerd]

Hi Alexander,

On Sun, Nov 15, 2020 at 10:22:32PM +0100, Alexander Hall wrote:
| I googled for "POSIX find", and hit this:
| 
| https://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html
| 
| => "Only a plus sign that follows an argument containing the two
| characters "{}" shall punctuate the end of the primary expression.
| Other uses of the plus sign shall not be treated as special."

Yep, I also found that when looking into this.  It's unforunate, as it
implies you can't use `-exec {} ... +` with e.g. ln, mv or cp, but oh
well.

(also, nitpicking, 'an argument containing the two characters "{}"'
includes an argument like "hh}hh{hh", which I'm pretty sure is not
what they mean)

| What you do in your diff is exactly that, treating it special.

I'm not sure I agree.  I make sure I do not treat it special unless
it's at the end of the argument to 'exec'.  Can you elaborate on what
you mean here?

Thanks!

Paul

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

Re: find -exec util {} arg + confusion

[Paul de Weerd]

Hi all,

It was pointed out to me off-list that I introduced a regression for
the case that has '+' as one of its arguments, e.g.:

[weerd@pom] $ find /var/empty -exec echo + {} +
find: -exec: "+" should follow {}

Updated diff fixes that case:

[weerd@pom] $ ./find /var/empty -exec echo cp {} /tmp/dest +
find: -exec: "+" should follow {}
[weerd@pom] $ ./find /var/empty -exec echo + {} +
+ /var/empty

Any thoughts or concerns?  Other regressions?

Thanks,

Paul

Index: function.c
===
RCS file: /home/OpenBSD/cvs/src/usr.bin/find/function.c,v
retrieving revision 1.49
diff -u -p -r1.49 function.c
--- function.c  9 Apr 2020 15:07:49 -   1.49
+++ function.c  15 Nov 2020 18:12:04 -
@@ -572,9 +572,14 @@ c_exec(char *unused, char ***argvp, int 
brace = 1;
if (strcmp(*ap, ";") == 0)
break;
-   if (strcmp(*ap, "+") == 0 && lastbrace) {
-   new->flags |= F_PLUSSET;
-   break;
+   if (strcmp(*ap, "+") == 0) {
+   if (lastbrace) {
+   new->flags |= F_PLUSSET;
+   break;
+   } else if (!*(ap+1)) {
+   errx(1, "%s: \"+\" should follow {}",
+  isok ? "-ok" : "-exec");
+       }
}
}
 


On Thu, Nov 12, 2020 at 08:51:22PM +0100, Paul de Weerd wrote:
| Hi all,
| 
| I misread find(1) and did:
| 
| [weerdpom] $ find path/to/cam -name \*.JPG -exec cp {} path/to/store +
| find: -exec no terminating ";" or "+"
| 
| That was somewhat surprising - there is a terminating "+".  The error
| really is that the "+" doesn't follow immediately after the "{}"
| (which the manpage of course told me).  Although it would be nice to
| be able to use tools like cp and mv to -exec with +, I suspect there
| to be dragons.  So I'm proposing to change the error to point this out
| to the unsuspecting user.
| 
| Cheers,
| 
| Paul 'WEiRD' de Weerd
| 
| Index: function.c
| ===
| RCS file: /home/OpenBSD/cvs/src/usr.bin/find/function.c,v
| retrieving revision 1.49
| diff -u -p -r1.49 function.c
| --- function.c9 Apr 2020 15:07:49 -   1.49
| +++ function.c12 Nov 2020 19:42:49 -
| @@ -572,9 +572,14 @@ c_exec(char *unused, char ***argvp, int 
|   brace = 1;
|   if (strcmp(*ap, ";") == 0)
|   break;
| - if (strcmp(*ap, "+") == 0 && lastbrace) {
| - new->flags |= F_PLUSSET;
| - break;
| + if (strcmp(*ap, "+") == 0) {
| + if (lastbrace) {
| + new->flags |= F_PLUSSET;
| + break;
| + } else {
| + errx(1, "%s: \"+\" should follow {}",
| +isok ? "-ok" : "-exec");
| + }
|   }
|   }
|  
| 
| -- 
| >[<++>-]<+++.>+++[<-->-]<.>+++[<+
| +++>-]<.>++[<>-]<+.--.[-]
|  http://www.weirdnet.nl/ 
| 

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

find -exec util {} arg + confusion

[Paul de Weerd]

Hi all,

I misread find(1) and did:

[weerdpom] $ find path/to/cam -name \*.JPG -exec cp {} path/to/store +
find: -exec no terminating ";" or "+"

That was somewhat surprising - there is a terminating "+".  The error
really is that the "+" doesn't follow immediately after the "{}"
(which the manpage of course told me).  Although it would be nice to
be able to use tools like cp and mv to -exec with +, I suspect there
to be dragons.  So I'm proposing to change the error to point this out
to the unsuspecting user.

Cheers,

Paul 'WEiRD' de Weerd

Index: function.c
===
RCS file: /home/OpenBSD/cvs/src/usr.bin/find/function.c,v
retrieving revision 1.49
diff -u -p -r1.49 function.c
--- function.c  9 Apr 2020 15:07:49 -   1.49
+++ function.c  12 Nov 2020 19:42:49 -
@@ -572,9 +572,14 @@ c_exec(char *unused, char ***argvp, int 
brace = 1;
if (strcmp(*ap, ";") == 0)
break;
-   if (strcmp(*ap, "+") == 0 && lastbrace) {
-   new->flags |= F_PLUSSET;
-   break;
+   if (strcmp(*ap, "+") == 0) {
+   if (lastbrace) {
+   new->flags |= F_PLUSSET;
+   break;
+   } else {
+   errx(1, "%s: \"+\" should follow {}",
+  isok ? "-ok" : "-exec");
+   }
}
}
 

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

missing support for OHMS and ENERGY sensors in sensorsd

[Paul de Weerd]

Hi all,

While browsing sensorsd.c for inspiration for a small project I'm
working on, I noticed that both src/usr.sbin/sensorsd/sensorsd.c and
src/sbin/sysctl/sysctl.c have a 'print_sensor' function that
returns/prints the value of the given sensor, including unit.  

However, sensorsd doesn't handle sensors with type SENSOR_OHMS or
SENSOR_ENERGY.  That doesn't seem right.  Below is a diff that adds
support for these types of sensors to sensorsd(8), using the same
format string as the print_sensor in sysctl(8).

I'm not sure if these kinds of sensors even exist (I don't have
them), so I've not been able to test this outside of compiling the
program and seeing that it starts normally.

Cheers,

Paul

Index: sensorsd.c
===
RCS file: /home/OpenBSD/cvs/src/usr.sbin/sensorsd/sensorsd.c,v
retrieving revision 1.67
diff -u -p -r1.67 sensorsd.c
--- sensorsd.c  22 Jul 2020 15:33:49 -  1.67
+++ sensorsd.c  21 Sep 2020 21:37:24 -
@@ -654,6 +654,9 @@ print_sensor(enum sensor_type type, int6
case SENSOR_VOLTS_AC:
snprintf(fbuf, RFBUFSIZ, "%.2f V AC", value / 100.0);
break;
+   case SENSOR_OHMS:
+   snprintf(fbuf, RFBUFSIZ, "%lld ohm", value);
+   break;
case SENSOR_WATTS:
snprintf(fbuf, RFBUFSIZ, "%.2f W", value / 100.0);
break;
@@ -707,6 +710,9 @@ print_sensor(enum sensor_type type, int6
break;
case SENSOR_VELOCITY:
snprintf(fbuf, RFBUFSIZ, "%4.3f m/s", value / 100.0);
+   break;
+   case SENSOR_ENERGY:
+   snprintf(fbuf, RFBUFSIZ, "%.2f J", value / 10.0);
break;
default:
snprintf(fbuf, RFBUFSIZ, "%lld ???", value);

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

Re: sensor value last change time not updated?

[Paul de Weerd]

On Tue, Aug 25, 2020 at 01:38:20PM -0600, Theo de Raadt wrote:
| What you are doing wasn't the purpose of the time field.  It was added
| only for time sensors, and it looks like someone added it to other
| sensors.  And now it must suddenly be for all of them??

Sorry - I may have introduced some confusion.  As far as I can tell,
no other sensor drivers touch the tv member outside of

- gpiodcf
- hypervic
- vmmci
- vmt
- udcf

(all time sensors)

| Collecting the microtime on every sensor read, on every time through
| the processing loop, is not free.

That makes sense; I wasn't expecting it to be free (I'm adding code)
but I also didn't look at the actual cost.

I've deleted my changes and will reconsider the options for what I was
originally doing in userland :)

Thanks,

Paul

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

Re: sensor value last change time not updated?

[Paul de Weerd]

Hi Theo,

On Tue, Aug 25, 2020 at 01:33:28PM -0600, Theo de Raadt wrote:
| > I don't understand the point.  None of the sensor drivers set that
| > member except the timedelta sensors.  I don't think adding code to do
| > so to all sensor drivers makes sense.
| 
| That is correct.  Non-time drivers should probably report 0 in that field.
| 
| And to follow, it means the microtime() calls should be deleted from
| other non-time-sensor drivers where it occurs.

Thanks.  As Hiltjo pointed out earlier, that doesn't seem to happen.
At least, I couldn't find any instances of it either.  So I don't
think there's anything to change, and I'll drop the diffs.

Cheers,

Paul

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

Re: sensor value last change time not updated?

[Paul de Weerd]

Hi Mark,

Thanks for your reply.

On Tue, Aug 25, 2020 at 09:27:20PM +0200, Mark Kettenis wrote:
| > I've dug out my stash of weird usb devices and found another sensor (a
| > uthum(4), with only temperature support).  I have a few other sensors
| > in live machines too (acpitz(4), cpu(4), admtemp(4), it(4), maybe some
| > more) that I could look into.
| > 
| > Is there any interest in adding support for setting the tv member for
| > non-time sensitive sensors?  Or should I drop this quest?
| 
| I don't understand the point.  None of the sensor drivers set that
| member except the timedelta sensors.  I don't think adding code to do
| so to all sensor drivers makes sense.

I'm inspecting it to only register "new" samples (even if the value
itself doesn't change).  My logic is that if the tv member has
changed, then the sensor value has been updated, so there's new
"data".  The fact that it's the same temperature / humidity / other
sensed value can also be interesting.

But if that doesn't make sense, then I can drop the patches and just
do periodic sampling at the same interval the kernel uses (which I've
not found yet, it seems that at least ugold(4) just sends data
periodically (every ~6 seconds) which the kernel then presents to
userland through sysctl).

Cheers,

Paul

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

Re: sensor value last change time not updated?

[Paul de Weerd]

Hi all,

I've dug out my stash of weird usb devices and found another sensor (a
uthum(4), with only temperature support).  I have a few other sensors
in live machines too (acpitz(4), cpu(4), admtemp(4), it(4), maybe some
more) that I could look into.

Is there any interest in adding support for setting the tv member for
non-time sensitive sensors?  Or should I drop this quest?

uhidev6 at uhub3 port 1 configuration 1 interface 0 "Ten X Technology, Inc. 
PCsensor Temper" rev 1.10/1.50 addr 10
uhidev6: iclass 3/1
uthum0 at uhidev6
uhidev7 at uhub3 port 1 configuration 1 interface 1 "Ten X Technology, Inc. 
PCsensor Temper" rev 1.10/1.50 addr 10
uhidev7: iclass 3/0
uthum1 at uhidev7
uthum1: type ds75/12bit (temperature)

Paul 'WEiRD' de Weerd

(following diff has been compile tested only so far)

Index: uthum.c
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/uthum.c,v
retrieving revision 1.34
diff -u -p -r1.34 uthum.c
--- uthum.c 14 Feb 2020 14:55:30 -  1.34
+++ uthum.c 25 Aug 2020 19:15:45 -
@@ -662,6 +662,7 @@ uthum_refresh_temperhum(struct uthum_sof
sc->sc_sensor[UTHUM_TEMPERHUM_TEMP].sensor.flags &= ~SENSOR_FINVALID;
sc->sc_sensor[UTHUM_TEMPERHUM_HUM].sensor.value = rh;
sc->sc_sensor[UTHUM_TEMPERHUM_HUM].sensor.flags &= ~SENSOR_FINVALID;
+   microtime(>sc_sensor[UTHUM_TEMPERHUM_HUM].sensor.tv);
 }
 
 void
@@ -699,6 +700,7 @@ uthum_refresh_temper(struct uthum_softc 
 
sc->sc_sensor[sensor].sensor.value = (temp * 1) + 27315;
sc->sc_sensor[sensor].sensor.flags &= ~SENSOR_FINVALID;
+   microtime(>sc_sensor[sensor].sensor.tv);
 }
 
 void
@@ -733,6 +735,7 @@ uthum_refresh_temperntc(struct uthum_sof
temp += sc->sc_sensor[sensor].cal_offset * 1;
sc->sc_sensor[sensor].sensor.value = temp;
sc->sc_sensor[sensor].sensor.flags &= ~SENSOR_FINVALID;
+   microtime(>sc_sensor[sensor].sensor.tv);
    }
 }
 

On Sat, Aug 15, 2020 at 10:08:56AM +0200, Paul de Weerd wrote:
| Thanks Hiltjo, that made me look at ugold.c.
| 
| With the below diff, my simple test program shows a value for the tv
| struct member.
| 
| [weerd@pom] $ ./sensor_last_change
| 1597477798.557355: 28.72
| 
| However, given what Hiltjo showed, the tv member seems to only be used
| for time-sensors, so it may be completely on purpose that other
| sensors don't expose this.  My rationale for inspecting tv is to
| ensure that I only take 'unique' samples (so when tv of the new sample
| differs from the previous one - while the actual value may remain the
| same).
| 
| Is this worth adding?
| 
| Cheers,
| 
| Paul 'WEiRD' de Weerd
| 
| Index: ugold.c
| ===
| RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/ugold.c,v
| retrieving revision 1.14
| diff -u -p -r1.14 ugold.c
| --- ugold.c   5 Oct 2017 17:29:00 -   1.14
| +++ ugold.c   15 Aug 2020 07:32:42 -
| @@ -270,11 +270,13 @@ ugold_ds75_intr(struct uhidev *addr, voi
|   case 4:
|   temp = ugold_ds75_temp(buf[4], buf[5]);
|   sc->sc_sensor[UGOLD_OUTER].value = temp;
| + microtime(>sc_sensor[UGOLD_OUTER].tv);
|   sc->sc_sensor[UGOLD_OUTER].flags &= ~SENSOR_FINVALID;
|   /* FALLTHROUGH */
|   case 2:
|   temp = ugold_ds75_temp(buf[2], buf[3]);
|   sc->sc_sensor[UGOLD_INNER].value = temp;
| + microtime(>sc_sensor[UGOLD_INNER].tv);
|   sc->sc_sensor[UGOLD_INNER].flags &= ~SENSOR_FINVALID;
|   break;
|   default:
| @@ -394,9 +396,11 @@ ugold_si700x_intr(struct uhidev *addr, v
|   sc->sc_hdev.sc_dev.dv_xname, buf[1]);
|   temp = ugold_si700x_temp(sc->sc_type, buf[2], buf[3]);
|   sc->sc_sensor[UGOLD_INNER].value = (temp * 1000) + 27315;
| + microtime(>sc_sensor[UGOLD_INNER].tv);
|   sc->sc_sensor[UGOLD_INNER].flags &= ~SENSOR_FINVALID;
|   rhum = ugold_si700x_rhum(sc->sc_type, buf[4], buf[5], temp);
|   sc->sc_sensor[UGOLD_HUM].value = rhum;
| + microtime(>sc_sensor[UGOLD_HUM].tv);
|   sc->sc_sensor[UGOLD_HUM].flags &= ~SENSOR_FINVALID;
|   break;
|   default:
| 
| On Fri, Aug 14, 2020 at 02:50:39PM +0200, Hiltjo Posthuma wrote:
| | On Fri, Aug 14, 2020 at 01:46:57PM +0200, Paul de Weerd wrote:
| | > Hi all,
| | > 
| | > I'm trying to read temperature sensor values from my ugold(4) device.
| | > Seems to work alright (I get the same temperature reading as sysctl(8)
| | > returns for the sensor), but the 'sensor value last ch

Typo fix in comment sys/dev/usb/ugold.c

[Paul de Weerd]

While looking at ugold.c I noticed a typo in a comment.  Diff
below.

Cheers,

Paul


Index: ugold.c
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/ugold.c,v
retrieving revision 1.14
diff -u -p -r1.14 ugold.c
--- ugold.c 5 Oct 2017 17:29:00 -   1.14
+++ ugold.c 15 Aug 2020 07:29:01 -
@@ -119,7 +119,7 @@ ugold_match(struct device *parent, void 
/*
 * XXX Only match the sensor interface.
 *
-* Does it makes sense to attach various uhidev(4) to these
+* Does it make sense to attach various uhidev(4) to these
 * non-standard HID devices?
 */
uhidev_get_report_desc(uha->parent, , );

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

Re: sensor value last change time not updated?

[Paul de Weerd]

Thanks Hiltjo, that made me look at ugold.c.

With the below diff, my simple test program shows a value for the tv
struct member.

[weerd@pom] $ ./sensor_last_change
1597477798.557355: 28.72

However, given what Hiltjo showed, the tv member seems to only be used
for time-sensors, so it may be completely on purpose that other
sensors don't expose this.  My rationale for inspecting tv is to
ensure that I only take 'unique' samples (so when tv of the new sample
differs from the previous one - while the actual value may remain the
same).

Is this worth adding?

Cheers,

Paul 'WEiRD' de Weerd

Index: ugold.c
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/ugold.c,v
retrieving revision 1.14
diff -u -p -r1.14 ugold.c
--- ugold.c 5 Oct 2017 17:29:00 -   1.14
+++ ugold.c 15 Aug 2020 07:32:42 -
@@ -270,11 +270,13 @@ ugold_ds75_intr(struct uhidev *addr, voi
case 4:
temp = ugold_ds75_temp(buf[4], buf[5]);
sc->sc_sensor[UGOLD_OUTER].value = temp;
+   microtime(>sc_sensor[UGOLD_OUTER].tv);
sc->sc_sensor[UGOLD_OUTER].flags &= ~SENSOR_FINVALID;
/* FALLTHROUGH */
case 2:
temp = ugold_ds75_temp(buf[2], buf[3]);
sc->sc_sensor[UGOLD_INNER].value = temp;
+   microtime(>sc_sensor[UGOLD_INNER].tv);
sc->sc_sensor[UGOLD_INNER].flags &= ~SENSOR_FINVALID;
break;
default:
@@ -394,9 +396,11 @@ ugold_si700x_intr(struct uhidev *addr, v
sc->sc_hdev.sc_dev.dv_xname, buf[1]);
temp = ugold_si700x_temp(sc->sc_type, buf[2], buf[3]);
sc->sc_sensor[UGOLD_INNER].value = (temp * 1000) + 27315;
+   microtime(>sc_sensor[UGOLD_INNER].tv);
sc->sc_sensor[UGOLD_INNER].flags &= ~SENSOR_FINVALID;
rhum = ugold_si700x_rhum(sc->sc_type, buf[4], buf[5], temp);
sc->sc_sensor[UGOLD_HUM].value = rhum;
+   microtime(>sc_sensor[UGOLD_HUM].tv);
sc->sc_sensor[UGOLD_HUM].flags &= ~SENSOR_FINVALID;
break;
default:

On Fri, Aug 14, 2020 at 02:50:39PM +0200, Hiltjo Posthuma wrote:
| On Fri, Aug 14, 2020 at 01:46:57PM +0200, Paul de Weerd wrote:
| > Hi all,
| > 
| > I'm trying to read temperature sensor values from my ugold(4) device.
| > Seems to work alright (I get the same temperature reading as sysctl(8)
| > returns for the sensor), but the 'sensor value last change time'
| > doesn't seem to be updated.
| > 
| > [weerd@pom] $ cat sensor_last_change.c  
| > #include 
| > #include 
| > #include 
| > #include 
| > 
| > int
| > main()
| > {
| > int mib[5];
| > size_t  sensorlen;
| > struct sensor   sensor;
| > 
| > mib[0] = CTL_HW;
| > mib[1] = HW_SENSORS;
| > mib[2] = 3; /* ugold0 on my machine */
| > mib[3] = SENSOR_TEMP;
| > mib[4] = 0;
| > 
| > sensorlen = sizeof(sensor);
| > sysctl(mib, 5, , , NULL, 0);
| > printf("%lld.%06ld: %.2f\n",
| > sensor.tv.tv_sec,
| > sensor.tv.tv_usec,
| > ((sensor.value-27315)/100.0));
| > 
| > return 0;
| > }
| > [weerd@pom] $ make sensor_last_change   
| > cc -O2 -pipe   -MD -MP   -o sensor_last_change sensor_last_change.c 
| > [weerd@pom] $ ./sensor_last_change
| > 0.00: 32.32
| > [weerd@pom] $ sysctl -n hw.sensors.ugold0.temp0
| > 32.32 degC (inner)
| > 
| > The 'tv' member of struct sensor seems to always be 0.0.  Am I doing
| > something wrong?
| > 
| > Cluesticks very welcome...
| > 
| > Thanks,
| > 
| > Paul
| > 
| > -- 
| > >[<++>-]<+++.>+++[<-->-]<.>+++[<+
| > +++>-]<.>++[<>-]<+.--.[-]
| >  http://www.weirdnet.nl/ 
| > 
| 
| Hi,
| 
| I don't think you're doing anything wrong, but I don't think its supported by
| the device and it's simply not set and so stays zero.
| 
| A quick grep shows some files which do use it:
| 
| /usr/src/sys $ grep -R sc_sensor\.tv .
| ./dev/gpio/gpiodcf.c:   microtime(>sc_sensor.tv);
| ./dev/pv/hypervic.c:microtime(>sc_sensor.tv);
| ./dev/pv/vmt.c: struct timeval *guest = >sc_sensor.tv;
| ./dev/pv/vmmci.c:   struct timeval  *guest = >sc_sensor.tv;
| ./dev/usb/udcf.c:   microtime(>sc_sensor.tv);
| 
| I have a ugold(4) device and will gladly test any improvements/patches.
| 
| -- 
| Kind regards,
| Hiltjo

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

Re: acme-client config grammar improvements

[Paul de Weerd]

On Thu, Jul 16, 2020 at 07:40:35AM +0200, Daniel Eisele wrote:
| Also it would be nice to have a feature to update all domains of the
| config file. I currently do that in a shell script by parsing the output
| of acme-client -nv with sed and then calling acme-client multiple times.

What I have is this:

for DOMAIN in `awk '/^domain/ {print $2}' /etc/acme-client.conf`

As I need to update OCSP staples per domain anyway, doing a per-domain
song-and-dance makes sense for me.  Since I set the 'handle' of the
domain to the actual (DNS) domain name (no need for the domain name
option in the file), this works out quite well.

| Maybe an easy solution would be an option that prints the list of all
| domains, so I can avoid the sed parsing, as this is prone to breaking.

Why is it prone to breaking?  You can only break it yourself by
introducing changes that break your script.  Sounds like a case of
"doctor, it hurts when I do X"?

Cheers,

Paul 'WEiRD' de Weerd

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

Re: [PATCH] fast conditional console scrolling

[Paul de Weerd]

Hi John,

With both your diffs applied, results are indeed more like 3x speed-up
that I get on my machine.  Average over 7 runs ls -R /usr/ports was
64.169s making for just under 3x increase.  That's on 1920x1080 with
the standard font size for that resolution (120x33 console, so 16x32
font).

Thanks again,

Paul 'WEiRD' de Weerd

On Fri, Jun 26, 2020 at 07:49:55AM -0700, jo...@armadilloaerospace.com wrote:
| I should have been more rigorous -- I had two different changes running
| on my system, as well as forcing it to use the 12x24 font for a 160x45
| console.
| 
| If you apply the "Optimized rasops32 putchar" patch I just posted, you
| should see another significant speedup.
| 
| 
|  Original Message 
| Subject: Re: [PATCH] fast conditional console scrolling
| From: Paul de Weerd 
| Date: Fri, June 26, 2020 1:23 am
| To: jo...@armadilloaerospace.com
| Cc: "tech@openbsd.org" 
| 
| Hi John,
| 
| I tried your diff. I don't quite see the same 3x improvement that you
| report, more like 2x. I timed 7 runs of ls -R /usr/ports:
| 
| Before diff, time ls -R /usr/ports | wc -l 2.897s on average
| After diff, time ls -R /usr/ports | wc -l 2.707s on average
| 
| Before diff, time ls -R /usr/ports 2m53.067 on average
| After diff, time ls -R /usr/ports 1m30.387 on average
| 
| Note that the 'before diff' runs were with a snapshot kernel. There
| may be diffs in there that account for the difference between before
| and after of the no-output runs. See dmesg and full stats below.
| 
| So, on average, a speed-up of ~48%.
| 
| Thanks!
| 
| Paul 'WEiRD' de Weerd
| 
| 

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

Re: [PATCH] fast conditional console scrolling

[Paul de Weerd]

Hi John,

I tried your diff.  I don't quite see the same 3x improvement that you
report, more like 2x.  I timed 7 runs of ls -R /usr/ports:

Before diff, time ls -R /usr/ports | wc -l  2.897s on average
After diff,  time ls -R /usr/ports | wc -l  2.707s on average

Before diff, time ls -R /usr/ports  2m53.067 on average
After diff, time ls -R /usr/ports   1m30.387 on average

Note that the 'before diff' runs were with a snapshot kernel.  There
may be diffs in there that account for the difference between before
and after of the no-output runs.  See dmesg and full stats below.

So, on average, a speed-up of ~48%.

Thanks!

Paul 'WEiRD' de Weerd

--- full stats ---
pre-diff, no output post-diff, no output
realusersystem  realusersystem
02.94   00.58   02.40   02.70   00.58   02.12
02.88   00.56   02.37   02.71   00.39   02.32
03.03   00.46   02.60   02.70   00.43   02.26
02.85   00.52   02.36   02.69   00.54   02.18
02.88   00.45   02.43   02.62   00.53   02.10
02.87   00.50   02.38   02.72   00.62   02.11
02.83   00.57   02.29   02.81   00.45   02.36

pre-diff, with output   post-diff, with output
realusersystem  realusersystem
2m53.17 00.90   2m52.27 1m30.81 01.23   1m29.50
2m53.12 00.81   2m52.31 1m30.58 01.33   1m29.30
2m53.01 00.88   2m52.11 1m30.49 01.11   1m29.40
2m53.06 01.03   2m52.00 1m30.53 01.29   1m29.26
2m52.99 00.80   2m52.24 1m30.27 01.08   1m29.19
2m53.11 00.96   2m52.16 1m30.40 01.14   1m29.27
2m53.01 00.79   2m52,28 1m30.33 01.11   1m29.24
--

--- dmesg 
OpenBSD 6.7-current (GENERIC.MP) #296: Wed Jun 24 11:34:44 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34243903488 (32657MB)
avail mem = 33191059456 (31653MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (88 entries)
bios0: vendor Dell Inc. version "A22" date 02/01/2018
bios0: Dell Inc. OptiPlex 9020
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT 
ASF! DMAR
acpi0: wakeup devices UAR1(S3) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP05(S4) 
PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) 
HDEF(S4) PEG0(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3692.06 MHz, 06-3c-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC skew=0 observed drift=0
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.46 MHz, 06-3c-03
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: TSC skew=1 observed drift=0
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.46 MHz, 06-3c-03
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: TSC skew=12 observed drift=0
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.46 MHz, 06-3c-03
cpu3: 

randomize daily/weekly/monthly crons

[Paul de Weerd]

Really like the ~ feature in cron.  I'm moving every machine that gets
updated to -current to use this for the daily/weekly/monthly crons, so
they are randomized in the 30 minute window after the original start
time.  Especially useful on machines running a few (or more) VMs.

Something (or something like it) to consider for inclusion?

Thank you for a very useful addition!

Paul

Index: crontab
===
RCS file: /home/OpenBSD/cvs/src/etc/crontab,v
retrieving revision 1.26
diff -u -p -r1.26 crontab
--- crontab 15 Apr 2020 03:24:08 -  1.26
+++ crontab 16 Apr 2020 15:05:22 -
@@ -14,9 +14,9 @@ HOME=/var/log
 #1-59  *   *   *   *   /usr/bin/newsyslog -m
 #
 # do daily/weekly/monthly maintenance
-30 1   *   *   *   /bin/sh /etc/daily
-30 3   *   *   6   /bin/sh /etc/weekly
-30 5   1   *   *   /bin/sh /etc/monthly
+30~1   *   *   *   /bin/sh /etc/daily
+30~3   *   *   6   /bin/sh /etc/weekly
+30~5   1   *   *   /bin/sh /etc/monthly
 #~ *   *   *   *   /usr/libexec/spamd-setup
 
 #0~20  9   *   *   *   -n rpki-client -v && bgpctl reload

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

Re: Opportunistic DoT for unwind(8)

[Paul de Weerd]

On Thu, Oct 24, 2019 at 11:27:24AM +0100, Kevin Chadwick wrote:
| 
| > The purpose of unwind is to provide secure DNS services even when
| > the available nameservers are broken or filtered like in many hotels.
| > To do that, it prefers DNSSEC whenever possible and changes to do
| > resolving by itself if needed.
| > 
| > DNSSEC only offers integrity and authenticity.  To protect
| > eavesdropping on the requests in transit, encryption is needed, as
| > offered by e.g. DNS over TLS (DoT) and DNS over HTTP (DoT). unwind
| 
| Before I jump aboard with DNSSECs failings in mind on my own networks rather
| than the mentioned hotel scenario. I believe but I am still not certain that
| services like PowerDNS have secure channels to the main primary DNS servers 
that
| apparently do not scale for the rest of us? Otherwise I worry that the network
| security target is a more singular centralised target compared to e.g. 
unbound.

These solutions (DoT / DoH, or the older DNSCrypt) encrypt DNS queries
from client to resolver, authorities are not available through these
protocols (yet).

This topic of DNS has lots of different attack vectors and risks
associated with it.  Slowly but surely, things are improving .. but
there's no big-bang solution that gets rid of all the issues in one
go.

If you want to use encrypted DNS from your client to your own resolver
then you can also do that.  Unbound is in base, look at the
tls-service-* and tls-port: options in unbound.conf(5).

The downside of using your own resolver (e.g. by running unbound on
your laptop), its traffic is more easily tied to a specific user.
There's an anonymizing power in using a bigger (shared) resolver (with
the downside that you then give your queries to a resolver that's
probably outside of your control - different risks and all that)

If you don't want to trust the freely available PowerDNS recursor then
that's your prerogative; it's just an easy option that's available
should you wish to test Otto's diff.

Cheers,

Paul 'WEiRD' de Weerd

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

Re: [PATCH] Add swich to enable/disable re-link the kernel at startup

[Paul de Weerd]

Hi Stefan,

On Tue, May 21, 2019 at 09:10:51PM +0200, Stefan Sperling wrote:
| > Reminds me that I should find some bigger CF to stick in there; 2GB
| > really doesn't cut it anymore these days.
| 
| My alix survives reorder_kernel just fine with 2GB of swap space,
| though 1GB would probably be more than sufficient (I just lazily
| added all unused paritions as swap and haven't had an issue since).

2GB of swap .. wow :)  2GB is the total amount of space on my alix:

[weerd@twix] $ dmesg | grep wd0
wd0 at pciide0 channel 0 drive 0: 
wd0: 4-sector PIO, LBA, 1953MB, 4001760 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
root on wd0a (85814e48b96fac91.a) swap on wd0b dump on wd0b

Ahh!  Found a 4GB CF.  Will upgrade...

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

Re: grep ".one\|.two" doesn't work on OpenBSD. Is it expected?

[Paul de Weerd]

On Mon, May 20, 2019 at 08:01:12PM +0200, Juan Francisco Cantero Hurtado wrote:
| I've a test in one of my ports similar to this:
| 
| $ cat test.txt
| 
$TESTTMP/hgcache/master/packs/7bcd2d90b99395ca43172a0dd24e18860b2902f9.histpack
| 
$TESTTMP/hgcache/master/packs/dc8f8fdc76690ce27791ce9f53a18da379e50d37.datapack
| $ cat test.txt | grep ".datapack\|.histpack"
| $ cat test.txt | ggrep ".datapack\|.histpack"
| 
$TESTTMP/hgcache/master/packs/7bcd2d90b99395ca43172a0dd24e18860b2902f9.histpack
| 
$TESTTMP/hgcache/master/packs/dc8f8fdc76690ce27791ce9f53a18da379e50d37.datapack
| 
| The grep command works with GNU, NetBSD, FreeBSD and BusyBox. It fails
| on OpenBSD and Solaris 11. I'm suggesting upstream to change the command
| to "grep -e ".datapack" -e ".histpack"" but I would like to know if this
| is a bug or we just don't support the | in the grep patterns.

Try grep -E, or egrep, for extended regular expression matching:

[weerd@pom] $ cat sample 
a
b
c
[weerd@pom] $ grep 'a|b' sample
[weerd@pom] $ grep -E 'a|b' sample
a
b

The standard grep(1) defaults to "basic" Regular Expressions, whereas
the branch-feature is part of Extended Regular Expressions (ERE).  See
re_format(7) for details.

Cheers,

Paul 'WEiRD' de Weerd

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

Re: [PATCH] Add swich to enable/disable re-link the kernel at startup

[Paul de Weerd]

Hi Stuart,

On Mon, May 20, 2019 at 12:14:56PM +0100, Stuart Henderson wrote:
| On 2019/05/20 10:46, Paul de Weerd wrote:
| > However, library_aslr delays the boot sequence (because libraries must
| > be completed before the system can boot up) while kernel_aslr does not
| > - it only introduces a bit of extra load on your machine.
| 
| That depends if reorder_kernel can run without killing the machine,
| it doesn't do very well on my alixes.

Fair point - for such machines the suggestion from my previous mail to
put the "wrong" hash in /var/db/kernel.SHA256 may help, as alixes tend
to not be super fast and have slow storage.

However, the one alix I still run in production personally doesn't
have too much of an issue with the reorder_kernel run.

Reminds me that I should find some bigger CF to stick in there; 2GB
really doesn't cut it anymore these days.

Cheers,

Paul

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

Re: [PATCH] Add swich to enable/disable re-link the kernel at startup

[Paul de Weerd]

On Sun, May 19, 2019 at 01:04:53PM +0200, Ricardo Fraile wrote:
| Hi all,
| 
| As exists the variable "library_aslr" to disable library randomization on
| rc, it would be helpful to have the same option for the kernel. Here is the
| patch to add the "kernel_aslr" swich.

If you must do this: `doas sha256 -h /var/db/kernel.SHA256 /dev/null`

To undo: `doas sha256 -h /var/db/kernel.SHA256 /bsd`

You can put these in a simple script to make it easier for you, or in
/etc/rc.local to survive upgrades.


However, library_aslr delays the boot sequence (because libraries must
be completed before the system can boot up) while kernel_aslr does not
- it only introduces a bit of extra load on your machine.  What
problem are you trying to solve?

Paul 'WEiRD' de Weerd

| Regards,
| Ricardo F.
| 
| 
| diff --git etc/rc etc/rc
| index 9a3917986cc..df2abbaa652 100644
| --- etc/rc
| +++ etc/rc
| @@ -615,7 +615,9 @@ echo '.'
| 
|  # Re-link the kernel, placing the objects in a random order.
|  # Replace current with relinked kernel and inform root about it.
| -/usr/libexec/reorder_kernel &
| +if [[ $kernel_aslr == YES ]]; then
| + /usr/libexec/reorder_kernel &
| +fi
| 
|  date
|  exit 0
| diff --git etc/rc.conf etc/rc.conf
| index a513b7575d4..30d1ca8953b 100644
| --- etc/rc.conf
| +++ etc/rc.conf
| @@ -101,6 +101,7 @@ multicast=NO  # Reject IPv4 multicast packets 
by default
|  # miscellaneous other flags
|  amd_master=/etc/amd/master   # AMD 'master' map
|  library_aslr=YES # set to NO to disable library randomization
| +kernel_aslr=YES  # set to NO to disable kernel 
randomization
|  savecore_flags=  # "-z" to compress
|  spamd_black=NO   # set to YES to run spamd without 
greylisting
|  shlib_dirs=  # extra directories for ldconfig, separated
| diff --git etc/rc.d/rc.subr etc/rc.d/rc.subr
| index 6a8e05e3b3e..3dafbba3e7e 100644
| --- etc/rc.d/rc.subr
| +++ etc/rc.d/rc.subr
| @@ -140,8 +140,9 @@ _rc_parse_conf() {
|   typeset -l _key
|   local _l _rcfile _val
|   set -A _allowed_keys -- \
| - accounting amd_master check_quotas ipsec library_aslr \
| - multicast nfs_server pexp pf pkg_scripts shlib_dirs spamd_black
| + accounting amd_master check_quotas ipsec kernel_aslr \
| + library_aslr multicast nfs_server pexp pf pkg_scripts \
| + shlib_dirs spamd_black
| 
|   [ $# -gt 0 ] || set -- /etc/rc.conf /etc/rc.conf.local
|   for _rcfile; do
| 

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

Re: [3/4] Re: Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

This may have gotten lost in the noise - but I forgot to update the
DESCRIPTION section of the umbg(4) manpage.

Diff again:

Index: umbg.4
===
RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
retrieving revision 1.5
diff -u -p -r1.5 umbg.4
--- umbg.4  22 Mar 2019 12:04:25 -  1.5
+++ umbg.4  22 Mar 2019 14:47:14 -
@@ -25,8 +25,9 @@
 .Sh DESCRIPTION
 The
 .Nm
-driver provides support for the Meinberg Funkuhren USB5131, a time signal
-station receiver for the German DCF77 station.
+driver provides support for the Meinberg Funkuhren USB5131 and the
+Meinberg Funkuhren DCF600USB, two time signal station receivers for
+the German DCF77 station.
 .Nm
 implements a timedelta sensor and the delta (in nanoseconds) between the
 received time information and the local time can be accessed through the


Thanks,

Paul

On Fri, Mar 22, 2019 at 04:00:06PM +0100, Paul de Weerd wrote:
| Whoops.  I had missed one change to the manpage that's still needed:
| the DESCRIPTION section also mentions the supported devices.  This now
| supports two models, but I don't think it makes sense to turn this
| into a list of supported hardware just yet.
| 
| 
| Index: umbg.4
| ===
| RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
| retrieving revision 1.5
| diff -u -p -r1.5 umbg.4
| --- umbg.422 Mar 2019 12:04:25 -  1.5
| +++ umbg.422 Mar 2019 14:47:14 -
| @@ -25,8 +25,9 @@
|  .Sh DESCRIPTION
|  The
|  .Nm
| -driver provides support for the Meinberg Funkuhren USB5131, a time signal
| -station receiver for the German DCF77 station.
| +driver provides support for the Meinberg Funkuhren USB5131 and the
| +Meinberg Funkuhren DCF600USB, two time signal station receivers for
| +the German DCF77 station.
|  .Nm
|  implements a timedelta sensor and the delta (in nanoseconds) between the
|  received time information and the local time can be accessed through the
| 
| 
| On Fri, Mar 22, 2019 at 10:04:19AM +0100, Paul de Weerd wrote:
| | 
| | Index: share/man/man4/umbg.4
| | ===
| | RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
| | retrieving revision 1.4
| | diff -u -p -r1.4 umbg.4
| | --- share/man/man4/umbg.4   16 Jul 2013 16:05:49 -  1.4
| | +++ share/man/man4/umbg.4   20 Mar 2019 12:16:03 -
| | @@ -19,7 +19,7 @@
| |  .Os
| |  .Sh NAME
| |  .Nm umbg
| | -.Nd Meinberg Funkuhren USB5131 timedelta sensor
| | +.Nd Meinberg Funkuhren USB5131 and DCF600USB timedelta sensors
| |  .Sh SYNOPSIS
| |  .Cd "umbg* at uhub?"
| |  .Sh DESCRIPTION
| | Index: sys/dev/usb/umbg.c
| | ===
| | RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/umbg.c,v
| | retrieving revision 1.25
| | diff -u -p -r1.25 umbg.c
| | --- sys/dev/usb/umbg.c  30 Dec 2017 20:47:00 -  1.25
| | +++ sys/dev/usb/umbg.c  22 Mar 2019 08:29:40 -
| | @@ -156,8 +156,9 @@ umbg_match(struct device *parent, void *
| | if (uaa->iface == NULL)
| | return UMATCH_NONE;
| |  
| | -   return uaa->vendor == USB_VENDOR_MEINBERG &&
| | -   uaa->product == USB_PRODUCT_MEINBERG_USB5131 ?
| | +   return uaa->vendor == USB_VENDOR_MEINBERG && (
| | +   uaa->product == USB_PRODUCT_MEINBERG_USB5131 ||
| | +   uaa->product == USB_PRODUCT_MEINBERG_DCF600USB) ?
| | UMATCH_VENDOR_PRODUCT : UMATCH_NONE;
| |  }
| |  
| | @@ -172,6 +173,7 @@ umbg_attach(struct device *parent, struc
| | usb_endpoint_descriptor_t *ed;
| | usbd_status err;
| | int signal;
| | +   const char *desc;
| |  #ifdef UMBG_DEBUG
| | char fw_id[MBG_ID_LEN];
| |  #endif
| | @@ -182,7 +184,18 @@ umbg_attach(struct device *parent, struc
| |  
| | sc->sc_timedelta.type = SENSOR_TIMEDELTA;
| | sc->sc_timedelta.status = SENSOR_S_UNKNOWN;
| | -   strlcpy(sc->sc_timedelta.desc, "USB5131",
| | +   
| | +   switch (uaa->product) {
| | +   case USB_PRODUCT_MEINBERG_DCF600USB:
| | +   desc = "DCF600USB";
| | +   break;
| | +   case USB_PRODUCT_MEINBERG_USB5131:
| | +   desc = "USB5131";
| | +   break;
| | +   default:
| | +   desc = "Unspecified Radio clock";
| | +   }
| | +   strlcpy(sc->sc_timedelta.desc, desc,
| | sizeof(sc->sc_timedelta.desc));
| | sensor_attach(>sc_sensordev, >sc_timedelta);
| |  
| | 
| | -- 
| | >[<++>-]<+++.>+++[<-->-]<.>+++[<+
| | +++>-]<.>++[<>-]<+.--.[-]
| |  http://www.weirdnet.nl/ 
| | 
| 
| -- 
| >

Re: usb drivers & arches (Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4))

[Paul de Weerd]

On Fri, Mar 22, 2019 at 11:53:20AM +, Stuart Henderson wrote:
| This is a more general thing actually, the list of USB drivers is rather
| haphazard at the moment. List below (to fit <80 cols I've snipped i386
| which has all drivers present in any other GENERIC config, amd64 which
| is only missing umbg, and sgi with all its various different configs). 
| 
| Would it make sense to try unifying these for all/some arches? are
| there particular space constraints for some (IIRC maybe the case on sgi,
| not sure about others) or other reasons to restrict them?

One thing that could be considered is putting all USB devices into a
separate file that gets included from the various arch-specific
GENERIC config files.  That would look a bit like the below for amd64
(although the 'USB' file would then probably move to sys/conf/).

This has some obvious downsides, so this is probably not such a hot
idea.  There's some upsides too, though.  Obviously, this is above my
pay-grade - I cannot oversee the full implications.


Index: GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.467
diff -u -p -r1.467 GENERIC
--- GENERIC 22 Mar 2019 12:05:45 -  1.467
+++ GENERIC 22 Mar 2019 16:08:19 -
@@ -89,7 +89,6 @@ hvn*  at hyperv?  # Hyper-V NetVSC
 hvs*   at hyperv?  # Hyper-V StorVSC
 
 option PCIVERBOSE
-option USBVERBOSE
 
 pchb*  at pci? # PCI-Host bridges
 aapic* at pci? # AMD 8131 IO apic
@@ -211,120 +210,7 @@ usb*  at ehci?
 usb*   at uhci?
 usb*   at ohci?
 
-# USB devices
-uhub*  at usb? # USB Hubs
-uhub*  at uhub?# USB Hubs
-urng*  at uhub?# USB Random Number Generator
-uonerng* at uhub?  # Moonbase Otago OneRNG
-umodem*at uhub?# USB Modems/Serial
-ucom*  at umodem?
-uvisor*at uhub?# Handspring Visor
-ucom*  at uvisor?
-uvscom*at uhub?# SUNTAC Slipper U VS-10U serial
-ucom*  at uvscom?
-ubsa*  at uhub?# Belkin serial adapter
-ucom*  at ubsa?
-uftdi* at uhub?# FTDI FT8U100AX serial adapter
-ucom*  at uftdi?
-uplcom* at uhub?   # I/O DATA USB-RSAQ2 serial adapter
-ucom*  at uplcom?
-umct*  at uhub?# MCT USB-RS232 serial adapter
-ucom*  at umct?
-uslcom*at uhub?# Silicon Laboratories CP210x serial
-ucom*  at uslcom?
-uscom* at uhub?# Simple USB serial adapters
-ucom*  at uscom?
-uark*  at uhub?# Arkmicro ARK3116 serial
-ucom*  at uark?
-moscom*at uhub?# MosChip MCS7703 serial
-ucom*  at moscom?
-umcs*  at uhub?# MosChip MCS78x0 serial
-ucom*  at umcs?
-uipaq* at uhub?# iPAQ serial adapter
-ucom*  at uipaq?
-umsm*  at uhub?# Qualcomm MSM EVDO
-ucom*  at umsm?
-uchcom*at uhub?# WinChipHead CH341/340 serial
-ucom*  at uchcom?
-uticom*at uhub?# TI serial
-ucom*  at uticom?
-uaudio* at uhub?   # USB Audio
-audio* at uaudio?
-umidi* at uhub?# USB MIDI
-midi*  at umidi?
-ulpt*  at uhub?# USB Printers
-umass* at uhub?# USB Mass Storage devices
-ubcmtp*at uhub?# Broadcom USB trackpad
-wsmouse* at ubcmtp? mux 0
-uhidev*at uhub?# Human Interface Devices
-ums*   at uhidev?  # USB mouse
-wsmouse* at ums? mux 0
-umt*   at uhidev?  # USB multitouch touchpad
-wsmouse* at umt? mux 0
-uts*   at uhub?# USB touchscreen
-wsmouse* at uts? mux 0
-uwacom*at uhidev?  # USB Wacom tablet
-wsmouse* at uwacom? mux 0
-ukbd*  at uhidev?  # USB keyboard
-wskbd* at ukbd? mux 1
-ucycom*at uhidev?  # Cypress serial
-ucom*  at ucycom?
-uslhcom* at uhidev?# Silicon Labs CP2110 USB HID UART
-ucom*  at uslhcom?
-uhid*  at uhidev?  # USB generic HID support
-upd*   at uhidev?  # USB Power Devices sensors
-aue*   at uhub?# ADMtek AN986 Pegasus Ethernet
-atu*   at uhub?# Atmel AT76c50x based 802.11b
-axe*   at uhub?# ASIX Electronics AX88172 USB Ethernet
-axen*  at uhub?# ASIX Electronics AX88179 USB Ethernet
-cue*   at uhub?# CATC USB-EL1201A based Ethernet
-kue*   at uhub?# Kawasaki KL5KUSB101B based Ethernet
-smsc*  at uhub?# SMSC LAN95xx Ethernet
-cdce*  at uhub?# CDC Ethernet
-urndis*at uhub?# Remote NDIS Ethernet
-upl*   at uhub?# Prolific PL2301/PL2302 host-to-host `network'
-ugl*   at uhub?# Genesys Logic GL620USB-A host-to-host 
`network'
-udav*  at uhub?  

Re: [3/4] Re: Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

Whoops.  I had missed one change to the manpage that's still needed:
the DESCRIPTION section also mentions the supported devices.  This now
supports two models, but I don't think it makes sense to turn this
into a list of supported hardware just yet.


Index: umbg.4
===
RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
retrieving revision 1.5
diff -u -p -r1.5 umbg.4
--- umbg.4  22 Mar 2019 12:04:25 -  1.5
+++ umbg.4  22 Mar 2019 14:47:14 -
@@ -25,8 +25,9 @@
 .Sh DESCRIPTION
 The
 .Nm
-driver provides support for the Meinberg Funkuhren USB5131, a time signal
-station receiver for the German DCF77 station.
+driver provides support for the Meinberg Funkuhren USB5131 and the
+Meinberg Funkuhren DCF600USB, two time signal station receivers for
+the German DCF77 station.
 .Nm
 implements a timedelta sensor and the delta (in nanoseconds) between the
 received time information and the local time can be accessed through the


On Fri, Mar 22, 2019 at 10:04:19AM +0100, Paul de Weerd wrote:
| 
| Index: share/man/man4/umbg.4
| ===
| RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
| retrieving revision 1.4
| diff -u -p -r1.4 umbg.4
| --- share/man/man4/umbg.4 16 Jul 2013 16:05:49 -  1.4
| +++ share/man/man4/umbg.4 20 Mar 2019 12:16:03 -
| @@ -19,7 +19,7 @@
|  .Os
|  .Sh NAME
|  .Nm umbg
| -.Nd Meinberg Funkuhren USB5131 timedelta sensor
| +.Nd Meinberg Funkuhren USB5131 and DCF600USB timedelta sensors
|  .Sh SYNOPSIS
|  .Cd "umbg* at uhub?"
|  .Sh DESCRIPTION
| Index: sys/dev/usb/umbg.c
| ===
| RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/umbg.c,v
| retrieving revision 1.25
| diff -u -p -r1.25 umbg.c
| --- sys/dev/usb/umbg.c30 Dec 2017 20:47:00 -  1.25
| +++ sys/dev/usb/umbg.c22 Mar 2019 08:29:40 -
| @@ -156,8 +156,9 @@ umbg_match(struct device *parent, void *
|   if (uaa->iface == NULL)
|   return UMATCH_NONE;
|  
| - return uaa->vendor == USB_VENDOR_MEINBERG &&
| - uaa->product == USB_PRODUCT_MEINBERG_USB5131 ?
| + return uaa->vendor == USB_VENDOR_MEINBERG && (
| + uaa->product == USB_PRODUCT_MEINBERG_USB5131 ||
| + uaa->product == USB_PRODUCT_MEINBERG_DCF600USB) ?
|   UMATCH_VENDOR_PRODUCT : UMATCH_NONE;
|  }
|  
| @@ -172,6 +173,7 @@ umbg_attach(struct device *parent, struc
|   usb_endpoint_descriptor_t *ed;
|   usbd_status err;
|   int signal;
| + const char *desc;
|  #ifdef UMBG_DEBUG
|   char fw_id[MBG_ID_LEN];
|  #endif
| @@ -182,7 +184,18 @@ umbg_attach(struct device *parent, struc
|  
|   sc->sc_timedelta.type = SENSOR_TIMEDELTA;
|   sc->sc_timedelta.status = SENSOR_S_UNKNOWN;
| - strlcpy(sc->sc_timedelta.desc, "USB5131",
| + 
| + switch (uaa->product) {
| + case USB_PRODUCT_MEINBERG_DCF600USB:
| + desc = "DCF600USB";
| + break;
| + case USB_PRODUCT_MEINBERG_USB5131:
| + desc = "USB5131";
| + break;
| + default:
| + desc = "Unspecified Radio clock";
| + }
| + strlcpy(sc->sc_timedelta.desc, desc,
|   sizeof(sc->sc_timedelta.desc));
|   sensor_attach(>sc_sensordev, >sc_timedelta);
|  
| 
| -- 
| >[<++>-]<+++.>+++[<-->-]<.>+++[<+
| +++>-]<.>++[<>-]<+.--.[-]
|  http://www.weirdnet.nl/ 
| 

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

Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

On Fri, Mar 22, 2019 at 10:22:15AM +, Stuart Henderson wrote:
| $ for i in */conf/GENERIC; do grep -q ^udcf $i && grep -q ^umbg $i || echo 
${i%%/*}; done

Did you want to only find archs which DO have udcf(4) but not umbg(4)?
Because not all of those in your list have udcf.  This adds ubmg where
we already have udcf.

As mentioned, this has not been tested at all.

Index: arm64/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/arm64/conf/GENERIC,v
retrieving revision 1.96
diff -u -p -r1.96 GENERIC
--- arm64/conf/GENERIC  3 Feb 2019 14:03:36 -   1.96
+++ arm64/conf/GENERIC  22 Mar 2019 10:50:20 -
@@ -299,6 +299,7 @@ urtw*   at uhub?# Realtek 8187
 rsu*   at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU
 urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
 udcf*  at uhub?# Gude Expert mouseCLOCK
+umbg*  at uhub?# Meinberg Funkuhren USB5131/DCF600USB
 uthum* at uhidev?  # TEMPerHUM sensor
 ugold* at uhidev?  # gold TEMPer sensor
 utrh*  at uhidev?  # USBRH sensor
Index: armv7/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.121
diff -u -p -r1.121 GENERIC
--- armv7/conf/GENERIC  12 Jan 2019 19:37:16 -  1.121
+++ armv7/conf/GENERIC  22 Mar 2019 10:50:34 -
@@ -326,6 +326,7 @@ urtw*   at uhub?# Realtek 8187
 rsu*   at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU
 urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
 udcf*  at uhub?# Gude Expert mouseCLOCK
+umbg*  at uhub?# Meinberg Funkuhren USB5131/DCF600USB
 uthum* at uhidev?  # TEMPerHUM sensor
 ugold* at uhidev?  # gold TEMPer sensor
 utrh*  at uhidev?  # USBRH sensor
Index: landisk/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/landisk/conf/GENERIC,v
retrieving revision 1.53
diff -u -p -r1.53 GENERIC
--- landisk/conf/GENERIC22 Aug 2018 15:38:46 -  1.53
+++ landisk/conf/GENERIC22 Mar 2019 10:50:53 -
@@ -162,6 +162,7 @@ rsu*at uhub?# Realtek 
RTL8188SU/RTL81
 urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
 zyd*   at uhub?# Zydas ZD1211
 udcf*  at uhub?# Gude Expert mouseCLOCK
+umbg*  at uhub?# Meinberg Funkuhren USB5131/DCF600USB
 uthum* at uhidev?  # TEMPerHUM sensor
 ugold* at uhidev?  # gold TEMPer sensor
 utwitch* at uhidev?# YUREX BBU sensor
Index: loongson/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/loongson/conf/GENERIC,v
retrieving revision 1.59
diff -u -p -r1.59 GENERIC
--- loongson/conf/GENERIC   22 Aug 2018 15:38:46 -  1.59
+++ loongson/conf/GENERIC   22 Mar 2019 10:51:09 -
@@ -192,6 +192,7 @@ wi* at uhub?# WaveLAN IEEE 802.11DS
 zyd*   at uhub?# Zydas ZD1211
 uberry*at uhub?# Research In Motion BlackBerry 
 udcf*  at uhub?# Gude Expert mouseCLOCK
+umbg*  at uhub?# Meinberg Funkuhren USB5131/DCF600USB
 uthum* at uhidev?  # TEMPerHUM sensor
 ugold* at uhidev?  # gold TEMPer sensor
 utwitch*   at uhidev?  # YUREX BBU sensor

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

Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

On Fri, Mar 22, 2019 at 10:22:15AM +, Stuart Henderson wrote:
| it's missing on some others too;
| 
| $ for i in */conf/GENERIC; do grep -q ^udcf $i && grep -q ^umbg $i || echo 
${i%%/*}; done
| alpha
| amd64
| arm64
| armv7
| hppa
| landisk
| loongson
| luna88k
| socppc

Yes.  I have some of those (some even in a working condition), but
haven't tried yet.  My amd64 is the fastest machine (platform) I have,
the others I would first need to dig out, update and get a source tree
on.  That'll take me a lot more time - I wanted to send this out
before going down that route.

Paul

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

[5/4] Re: Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

Bonus diff - make explicit in the GENERIC configs that already have
umbg(4), that this driver now supports DCF600USB too


Index: i386/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.839
diff -u -p -r1.839 GENERIC
--- i386/conf/GENERIC   18 Jan 2019 01:34:50 -  1.839
+++ i386/conf/GENERIC   22 Mar 2019 09:08:51 -
@@ -318,7 +318,7 @@ urtw*   at uhub?# Realtek 8187
 rsu*   at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU
 urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
 udcf*  at uhub?# Gude Expert mouseCLOCK
-umbg*  at uhub?# Meinberg Funkuhren USB5131
+umbg*  at uhub?# Meinberg Funkuhren USB5131/DCF600USB
 umb*   at uhub?# Mobile Broadband Interface Model
 uthum* at uhidev?  # TEMPerHUM sensor
 ugold* at uhidev?  # gold TEMPer sensor
Index: macppc/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/macppc/conf/GENERIC,v
retrieving revision 1.266
diff -u -p -r1.266 GENERIC
--- macppc/conf/GENERIC 21 Sep 2018 12:42:34 -  1.266
+++ macppc/conf/GENERIC 22 Mar 2019 09:08:56 -
@@ -293,7 +293,7 @@ zyd*at uhub?# Zydas ZD1211
 upgt*  at uhub?# Conexant/Intersil PrismGT SoftMAC USB
 urtw*  at uhub?# Realtek 8187
 udcf*  at uhub?# Gude Expert mouseCLOCK
-umbg*  at uhub?# Meinberg Funkuhren USB5131
+umbg*  at uhub?# Meinberg Funkuhren USB5131/DCF600USB
 uthum* at uhidev?  # TEMPerHUM sensor
 ugold* at uhidev?  # gold TEMPer sensor
 utrh*  at uhidev?  # USBRH sensor
Index: octeon/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/octeon/conf/GENERIC,v
retrieving revision 1.45
diff -u -p -r1.45 GENERIC
--- octeon/conf/GENERIC 12 Jan 2019 16:59:38 -  1.45
+++ octeon/conf/GENERIC 22 Mar 2019 09:08:58 -
@@ -175,7 +175,7 @@ urtw*   at uhub?# Realtek 8187
 rsu*   at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU
 urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
 udcf*  at uhub?# Gude Expert mouseCLOCK
-umbg*  at uhub?# Meinberg Funkuhren USB5131
+umbg*  at uhub?# Meinberg Funkuhren USB5131/DCF600USB
 uthum* at uhidev?  # TEMPerHUM sensor
 ugold* at uhidev?  # gold TEMPer sensor
 utrh*  at uhidev?  # USBRH sensor
Index: sparc64/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/sparc64/conf/GENERIC,v
retrieving revision 1.309
diff -u -p -r1.309 GENERIC
--- sparc64/conf/GENERIC29 Jan 2019 02:43:05 -  1.309
+++ sparc64/conf/GENERIC22 Mar 2019 09:09:04 -
@@ -247,7 +247,7 @@ udsbr*  at uhub?# D-Link DSB-R100 radio
 radio* at udsbr?   # USB radio
 ugen*  at uhub?# USB Generic driver
 udcf*  at uhub?# Gude Expert mouseCLOCK
-umbg*  at uhub?# Meinberg Funkuhren USB5131
+umbg*  at uhub?# Meinberg Funkuhren USB5131/DCF600USB
 uthum* at uhidev?  # TEMPerHUM sensor
 ugold* at uhidev?  # gold TEMPer sensor
 utwitch* at uhidev?# UYUREX BBU sensor

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

[2/4] Re: Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

Index: usbdevs.h
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.707
diff -u -p -r1.707 usbdevs.h
--- usbdevs.h   24 Feb 2019 17:35:44 -  1.707
+++ usbdevs.h   22 Mar 2019 07:48:28 -
@@ -1,10 +1,10 @@
-/* $OpenBSD: usbdevs.h,v 1.707 2019/02/24 17:35:44 patrick Exp $   */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
  *
  * generated from:
- * OpenBSD: usbdevs,v 1.694 2019/01/14 03:28:03 jmatthew Exp 
+ * OpenBSD: usbdevs,v 1.695 2019/02/24 17:35:29 patrick Exp 
  */
 /* $NetBSD: usbdevs,v 1.322 2003/05/10 17:47:14 hamajima Exp $ */
 
@@ -2931,6 +2931,7 @@
 
 /* Meinberg Funkuhren products */
 #defineUSB_PRODUCT_MEINBERG_USB51310x0301  /* USB 5131 
DCF77 - Radio Clock */
+#defineUSB_PRODUCT_MEINBERG_DCF600USB  0x0302  /* DCF600USB - 
Radio Clock */
 
 /* Melco, Inc products */
 #defineUSB_PRODUCT_MELCO_LUATX10x0001  /* LUA-TX 
Ethernet */
Index: usbdevs_data.h
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.701
diff -u -p -r1.701 usbdevs_data.h
--- usbdevs_data.h  24 Feb 2019 17:35:44 -  1.701
+++ usbdevs_data.h  22 Mar 2019 07:48:28 -
@@ -1,10 +1,10 @@
-/* $OpenBSD: usbdevs_data.h,v 1.701 2019/02/24 17:35:44 patrick Exp $  
*/
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
  *
  * generated from:
- * OpenBSD: usbdevs,v 1.694 2019/01/14 03:28:03 jmatthew Exp 
+ * OpenBSD: usbdevs,v 1.695 2019/02/24 17:35:29 patrick Exp 
  */
 /* $NetBSD: usbdevs,v 1.322 2003/05/10 17:47:14 hamajima Exp $ */
 
@@ -7016,6 +7016,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_MEINBERG, USB_PRODUCT_MEINBERG_USB5131,
"USB 5131 DCF77 - Radio Clock",
+   },
+   {
+   USB_VENDOR_MEINBERG, USB_PRODUCT_MEINBERG_DCF600USB,
+   "DCF600USB - Radio Clock",
},
{
USB_VENDOR_MELCO, USB_PRODUCT_MELCO_LUATX1,

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

[4/4] Re: Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

Index: GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.466
diff -u -p -r1.466 GENERIC
--- GENERIC 19 Jan 2019 03:24:18 -  1.466
+++ GENERIC 22 Mar 2019 08:10:33 -
@@ -306,6 +306,7 @@ urtw*   at uhub?# Realtek 8187
 rsu*   at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU
 urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
 udcf*  at uhub?# Gude Expert mouseCLOCK
+umbg*  at uhub?# Meinberg Funkuhren USB5131/DCF600USB
 umb*   at uhub?# Mobile Broadband Interface Model
 uthum* at uhidev?  # TEMPerHUM sensor
 ugold* at uhidev?  # gold TEMPer sensor


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

[3/4] Re: Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

Index: share/man/man4/umbg.4
===
RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
retrieving revision 1.4
diff -u -p -r1.4 umbg.4
--- share/man/man4/umbg.4   16 Jul 2013 16:05:49 -  1.4
+++ share/man/man4/umbg.4   20 Mar 2019 12:16:03 -
@@ -19,7 +19,7 @@
 .Os
 .Sh NAME
 .Nm umbg
-.Nd Meinberg Funkuhren USB5131 timedelta sensor
+.Nd Meinberg Funkuhren USB5131 and DCF600USB timedelta sensors
 .Sh SYNOPSIS
 .Cd "umbg* at uhub?"
 .Sh DESCRIPTION
Index: sys/dev/usb/umbg.c
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/umbg.c,v
retrieving revision 1.25
diff -u -p -r1.25 umbg.c
--- sys/dev/usb/umbg.c  30 Dec 2017 20:47:00 -  1.25
+++ sys/dev/usb/umbg.c  22 Mar 2019 08:29:40 -
@@ -156,8 +156,9 @@ umbg_match(struct device *parent, void *
if (uaa->iface == NULL)
return UMATCH_NONE;
 
-   return uaa->vendor == USB_VENDOR_MEINBERG &&
-   uaa->product == USB_PRODUCT_MEINBERG_USB5131 ?
+   return uaa->vendor == USB_VENDOR_MEINBERG && (
+   uaa->product == USB_PRODUCT_MEINBERG_USB5131 ||
+   uaa->product == USB_PRODUCT_MEINBERG_DCF600USB) ?
UMATCH_VENDOR_PRODUCT : UMATCH_NONE;
 }
 
@@ -172,6 +173,7 @@ umbg_attach(struct device *parent, struc
usb_endpoint_descriptor_t *ed;
usbd_status err;
int signal;
+   const char *desc;
 #ifdef UMBG_DEBUG
char fw_id[MBG_ID_LEN];
 #endif
@@ -182,7 +184,18 @@ umbg_attach(struct device *parent, struc
 
sc->sc_timedelta.type = SENSOR_TIMEDELTA;
sc->sc_timedelta.status = SENSOR_S_UNKNOWN;
-   strlcpy(sc->sc_timedelta.desc, "USB5131",
+   
+   switch (uaa->product) {
+   case USB_PRODUCT_MEINBERG_DCF600USB:
+   desc = "DCF600USB";
+   break;
+   case USB_PRODUCT_MEINBERG_USB5131:
+   desc = "USB5131";
+   break;
+   default:
+   desc = "Unspecified Radio clock";
+   }
+   strlcpy(sc->sc_timedelta.desc, desc,
sizeof(sc->sc_timedelta.desc));
sensor_attach(>sc_sensordev, >sc_timedelta);
 

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

[1/4] Re: Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

Index: usbdevs
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.695
diff -u -p -r1.695 usbdevs
--- usbdevs 24 Feb 2019 17:35:29 -  1.695
+++ usbdevs 20 Mar 2019 11:55:44 -
@@ -2924,6 +2924,7 @@ product MEI S2000 0x1101  Series 2000
 
 /* Meinberg Funkuhren products */
 product MEINBERG USB5131   0x0301  USB 5131 DCF77 - Radio Clock
+product MEINBERG DCF600USB 0x0302  DCF600USB - Radio Clock
 
 /* Melco, Inc products */
 product MELCO LUATX1   0x0001  LUA-TX Ethernet

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

Add support for Meinberg DCF600USB to umbg(4)

[Paul de Weerd]

Hi all,

After Peter J. Philipp asked about Meinberg DCF clock support on misc@
in https://marc.info/?l=openbsd-misc=155205024420585=2 I was also
interested in the question he asked.  After some consideration, I
decided to try, so I bought a Meinberg DCF600USB which was delivered
yesterday.  I unpacked it this morning and hooked it up to find the
kernel reporting:

2019-03-22T07:46:55.515Z pom /bsd: ugen0 at uhub3 port 2 "Meinberg DCF600USB" 
rev 2.00/1.13 addr 7

After that I

1/3: added the USB product ID (0x0302) to usbdevs
2/3: ran `make usbdevs` to update usbdevs{_data,}.h
3/3: updated the driver (and manpage) to support DCF600USB

Unfortunately, after a reboot I still got

2019-03-22T08:00:48.096Z pom /bsd: ugen0 at uhub3 port 2 "Meinberg DCF600USB" 
rev 2.00/1.13 addr 3

Turns out umbg(4) was never added to GENERIC for amd64.  So after

4/3: add umbg(4) to amd64 GENERIC kernel config

I now have

[weerd@pom] $ dmesg | grep umbg0
umbg0 at uhub3 port 2 configuration 1 interface 0 "Meinberg DCF600USB" rev 
2.00/1.13 addr 3
umbg0: not synchronized, freerun

(full dmesg at the bottom of this mail)

Immediately after boot, it's not synced:

[weerd@pom] $ sysctl hw.sensors.umbg0
hw.sensors.umbg0.percent0=100.00% (Signal), WARNING, Fri Mar 22 09:39:18.964
hw.sensors.umbg0.timedelta0=-0.436787 secs (DCF600USB), OK, Fri Mar 22 
09:39:18.964

but after some uptime:

[weerd@pom] $ sysctl hw.sensors.umbg0
hw.sensors.umbg0.percent0=100.00% (Signal), OK, Fri Mar 22 09:58:14.412
hw.sensors.umbg0.timedelta0=-0.008610 secs (DCF600USB), OK, Fri Mar 22 
09:58:14.412

And ntpd is happy with this sensor:

[weerd@pom] $ ntpctl -s Sensors
sensor
   wt gd st  next  poll  offset  correction
umbg0  
1  1  0   15s   15s 8.598ms 0.000ms

I'm sending the 4 diffs in separate e-mails; comments and/or commits
very welcome.

Paul

OpenBSD 6.5-beta (GENERIC.MP) #14: Fri Mar 22 09:32:08 CET 2019
we...@pom.alm.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34243903488 (32657MB)
avail mem = 33195778048 (31657MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (88 entries)
bios0: vendor Dell Inc. version "A22" date 02/01/2018
bios0: Dell Inc. OptiPlex 9020
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT 
ASF! DMAR
acpi0: wakeup devices UAR1(S3) PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) 
RP05(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) 
HDEF(S4) PEG0(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3692.03 MHz, 06-3c-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.46 MHz, 06-3c-03
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.46 MHz, 06-3c-03
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.46 MHz, 06-3c-03
cpu3: 

Re: what.1: remove BUGS section

[Paul de Weerd]

Hi Ingo,

On Sun, Jan 20, 2019 at 03:11:55PM +0100, Ingo Schwarze wrote:
| > Talking about BSD not being able to distribute SCCS doesn't help
| > anyone;
| > not behaving like the original SCCS is obvious considering the
| > STANDARDS section specifically notes OpenBSD extensions and
| > compliance with POSIX.
| 
| I almost felt like proposing to delete the utility outright.
| We stopped embedding identifier strings into binaries many years ago.
| 
| Then again, who knows whether some scripts somewhere still call it.
| Keeping it costs almost nothing, and it is not dangerous.

It's not completely useless:

[weerd@pom] $ doas what /bsd
/bsd
OpenBSD 6.4-current (GENERIC.MP) #597: Thu Jan 10 21:47:25 MST 2019
[weerd@pom] $ what `which ksh`
/bin/ksh
PD KSH v5.2.14 99/07/13.2

Cheers,

Paul 'WEiRD' de Weerd

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

Re: sbin/wsconsctl: show more data

[Paul de Weerd]

Lots of negativity here, so I just wanted to chime in - really love
the new console font!  Crisp and easily readable letters, big enough
to be readable, with a reasonable number of letters per line
(${COLUMNS}) en lines per screen (${LINES}).  It does mean pretty big
characters on big screens when in console mode, but on big screens I
want to run X anyway, so it's all good.  What I understand of the
algorithm to pick the font size makes a lot of sense to me.

Thank you Frederic for all the effort you put into this font and
making it happen on the console and in X through the fonts/spleen
port!

Cheers,

Paul 'WEiRD' de Weerd

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

Re: Add acpipci(4) on amd64

[Paul de Weerd]

Hi Mark,

On Mon, Oct 22, 2018 at 09:45:06PM +0200, Mark Kettenis wrote:
| I'd like to see this tested on a wide range of amd64 hardware, but
| especially on laptops.  Please reply with a diff of your dmesg before
| and after.  Make sure you run make config before building a new kernel.

Thanks for your work!  Not much difference on my GPD Win (pocket)
computer.  Diff and full dmesg below.

Note that there's a kernel page fault when running bwfm attach hooks;
this happens frequently, I avoid it by booting a kernel with bwfm
disabled.

Cheers,

Paul

--- /home/weerd/taco.20181019.dmesg Wed Oct 24 08:52:07 2018
+++ /home/weerd/taco.20181024.dmesg Wed Oct 24 08:52:07 2018
@@ -1,7 +1,7 @@
-OpenBSD 6.4-current (GENERIC.MP) #370: Fri Oct 19 13:09:31 MDT 2018
-dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
+OpenBSD 6.4-current (GENERIC.MP) #7: Wed Oct 24 07:42:29 CEST 2018
+we...@pom.alm.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 4182315008 (3988MB)
-avail mem = 4046282752 (3858MB)
+avail mem = 4046286848 (3858MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
@@ -15,7 +15,7 @@
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
-cpu0: Intel(R) Atom(TM) x7-Z8700 CPU @ 1.60GHz, 1600.26 MHz, 06-4c-03
+cpu0: Intel(R) Atom(TM) x7-Z8700 CPU @ 1.60GHz, 1600.25 MHz, 06-4c-03
 cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
 cpu0: 1MB 64b/line 16-way L2 cache
 cpu0: smt 0, core 0, package 0
@@ -28,12 +28,12 @@
 cpu1: 1MB 64b/line 16-way L2 cache
 cpu1: smt 0, core 1, package 0
 cpu2 at mainbus0: apid 4 (application processor)
-cpu2: Intel(R) Atom(TM) x7-Z8700 CPU @ 1.60GHz, 1599.95 MHz, 06-4c-03
+cpu2: Intel(R) Atom(TM) x7-Z8700 CPU @ 1.60GHz, 1599.96 MHz, 06-4c-03
 cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
 cpu2: 1MB 64b/line 16-way L2 cache
 cpu2: smt 0, core 2, package 0
 cpu3 at mainbus0: apid 6 (application processor)
-cpu3: Intel(R) Atom(TM) x7-Z8700 CPU @ 1.60GHz, 1599.95 MHz, 06-4c-03
+cpu3: Intel(R) Atom(TM) x7-Z8700 CPU @ 1.60GHz, 1599.96 MHz, 06-4c-03
 cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
 cpu3: 1MB 64b/line 16-way L2 cache
 cpu3: smt 0, core 3, package 0
@@ -96,6 +96,7 @@
 "INT33FE" at iic0 addr 0x54 not configured
 chvgpio2 at acpi0: GPO0 uid 1 addr 0xfed8/0x8000 irq 49, 56 pins
 chvgpio3 at acpi0: GPO2 uid 3 addr 0xfed9/0x8000 irq 50, 24 pins
+acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
 sdhc0 at acpi0 SDHA addr 0xa1a3a000/0x1000 irq 45
 sdhc0: SDHC 3.0, 200 MHz base clock
 sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma
@@ -197,15 +198,15 @@
 vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation)
 efifb at mainbus0 not configured
 sdmmc1: can't enable card
-scsibus1 at sdmmc0: 2 targets, initiator 0
-sd0 at scsibus1 targ 1 lun 0:  SCSI2 0/direct removable
-sd0: 59640MB, 512 bytes/sector, 122142720 sectors
+scsibus1 at sdmmc2: 2 targets, initiator 0
+sd0 at scsibus1 targ 1 lun 0:  SCSI2 0/direct removable
+sd0: 61071MB, 512 bytes/sector, 125073408 sectors
+scsibus2 at sdmmc0: 2 targets, initiator 0
+sd1 at scsibus2 targ 1 lun 0:  SCSI2 0/direct removable
+sd1: 59640MB, 512 bytes/sector, 122142720 sectors
 uhidev0 at uhub0 port 2 configuration 1 interface 0 "HK-XBOXKB-US-A0-10-00 USB 
KEYBOARD" rev 1.10/1.00 addr 2
 uhidev0: iclass 3/1
 ukbd0 at uhidev0: 8 variable keys, 6 key codes
-scsibus2 at sdmmc2: 2 targets, initiator 0
-sd1 at scsibus2 targ 1 lun 0:  SCSI2 0/direct removable
-sd1: 61071MB, 512 bytes/sector, 125073408 sectors
 wskbd0 at ukbd0: console keyboard, using wsdisplay0
 uhidev1 at uhub0 port 2 configuration 1 interface 1 "HK-XBOXKB-US-A0-10-00 USB 
KEYBOARD" rev 1.10/1.00 addr 2
 uhidev1: iclass 3/0, 9 report ids
@@ -224,14 +225,17 @@
 ukbd1 at uhidev3: 8 variable keys, 6 key codes
 wskbd1 at ukbd1 mux 1
 wskbd1: connecting to wsdisplay0
-ure0 at uhub0 port 9 configuration 1 interface 0 "Realtek USB 10/100/1000 LAN" 
rev 3.00/30.00 addr 4
-ure0: ver 5c20, address 00:e0:97:00:65:53
-rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0
 vscsi0 at root
 scsibus3 at vscsi0: 256 targets
 softraid0 at root
 scsibus4 at softraid0: 256 

Re: nsd 4.1.24

[Paul de Weerd]

On Wed, Aug 15, 2018 at 03:12:19PM +0200, Florian Obser wrote:
| When this goes in I think we should switch the default control socket
| and stop listening on localhost.

This makes a lot of sense to me, please make the UDS the default
control socket.

Thanks Florian!

Paul

| OK?
| 
| diff --git etc/nsd.conf etc/nsd.conf
| index 729a5f620ba..94710bfa5ae 100644
| --- etc/nsd.conf
| +++ etc/nsd.conf
| @@ -19,6 +19,7 @@ server:
|  
|  remote-control:
|   control-enable: yes
| + control-interface: /var/run/nsd.sock
|  
|  ## tsig key example
|  #key:
| 
| 
| -- 
| I'm not entirely sure you are real.
| 

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

Re: call for testing: rad(8) - a rtadvd(8) replacement

[Paul de Weerd]

On Wed, Jul 18, 2018 at 08:54:51AM +0200, Florian Obser wrote:
| During g2k18 I commited rad(8).
| 
| The latest amd64 and i386 snapshots should contain it with enough
| features to replace rtadvd(8). If you are using rtadvd(8) I'd
| appreciate if you could switch to rad(8) and report back if any
| features are missing.
| 
| The plan is to unhook rtadvd(8) from the build sooner rather than
| later and to ship 6.4 with rad(8) only.
| 
| If you are running rtadvd(8) with out any configuration and only have
| rtadvd_flags=em1 the /etc/rad.conf file will be
| 
| ---8<---
| interface em0
| ---8<---
| 
| Once that is inplace disable rtadvd and enable rad:
| 
| # rcctl stop rtadvd
| # rcctl disable rtadvd
| # rcctl enable rad
| # rcctl start rad
| 
| see man rad.conf for documentation on the config file format. Good
| news: it's no longer termcap based!

Works well.  Love the configuration format, although I never did have
any special or interesting config for rtadvd:

[root@tuna] # grep -e rad -e rtadvd /etc/rc.conf.local 
/var/backups/etc_rc.conf.local.current 
/etc/rc.conf.local:rad_flags=
/var/backups/etc_rc.conf.local.current:rtadvd_flags="em1 em2 em3"
[root@tuna] # cat /etc/rad.conf
interface em1
interface em2
interface em3

Seems to work as advertised just fine.  I do see the logging bits
Sebastien already mentioned, but that will disappear with the next
snapshot upgrade as I see you've already committed some fixes.

Thanks for working on this Florian .. it's pretty rad!

Cheers,

Paul

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

Re: 6.3 and Prolific PL-2303 USB serial adapter

[Paul de Weerd]

Updated diff included below.  I've set the product name to LD220.
This diff lacks the updates to usbdevs{,_data}.h, whoever commits
should update those too.

Any takers to commit this?  Tested by an owner of the actual device,
so that's good.  Jan-Piet, maybe you can share a dmesg of the machine
with the device attached as uplcom(4)?

Thanks!

Paul

Index: uplcom.c
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/uplcom.c,v
retrieving revision 1.71
diff -u -p -r1.71 uplcom.c
--- uplcom.c27 Apr 2018 09:40:59 -  1.71
+++ uplcom.c18 Jun 2018 17:25:51 -
@@ -140,6 +140,7 @@ static const struct usb_devno uplcom_dev
{ USB_VENDOR_ELECOM, USB_PRODUCT_ELECOM_UCSGT },
{ USB_VENDOR_ELECOM, USB_PRODUCT_ELECOM_UCSGT0 },
{ USB_VENDOR_HAL, USB_PRODUCT_HAL_IMR001 },
+   { USB_VENDOR_HP, USB_PRODUCT_HP_LD220 },
{ USB_VENDOR_IODATA, USB_PRODUCT_IODATA_USBRSAQ },
{ USB_VENDOR_IODATA, USB_PRODUCT_IODATA_USBRSAQ5 },
{ USB_VENDOR_LEADTEK, USB_PRODUCT_LEADTEK_9531 },
Index: usbdevs
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.684
diff -u -p -r1.684 usbdevs
--- usbdevs 11 Apr 2018 04:15:26 -  1.684
+++ usbdevs 18 Jun 2018 17:25:36 -
@@ -2190,6 +2190,7 @@ product HP R1500G20x1fe0  R1500 G2 UPS
 product HP T750G2  0x1fe1  T750 G2 UPS
 product HP 640C0x2004  DeskJet 640c
 product HP 10200x2b17  LaserJet 1020
+product HP LD220   0x3524  LD220
 product HP P1100   0x3102  Photosmart P1100
 product HP 10180x4117  LaserJet 1018
 product HP HN210E  0x811c  HN210E Ethernet

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

Re: 6.3 and Prolific PL-2303 USB serial adapter

[Paul de Weerd]

Hi Jan-Piet!

On Mon, Jun 18, 2018 at 04:16:34PM +0200, Jan-Piet Mens wrote:
| > Only one way to find out :)
| 
| I spare you a lot of details by pointing you at a photo I just took of the
| working display: if you'd please scroll to the bottom of [1] .. ?
| 
| A final (hah!) question: will your patch be incorporated into OpenBSD?

That's pretty awesome!  Thanks for testing the diff.

As is, I don't think the patch should be incorporated.  I've made up a
product name (the "product HP USB2SER 0x3524 Prolific uplcom" part of
the diff).  That should be improved first.  Do you have a model name
for this HP product?  Any additional stickers that help identify it?
A URL from the HP website for this product?

My description is now very generic, we should try to improve that
before asking people with commit access to put it in.

Note though that it'll only be in OpenBSD from that day, and won't be
backported to 6.3.  That means that, if you want to keep running the
released version (i.e. no snapshots), you'll have to keep your
self-compiled kernel until 6.4 comes out.

Cheers,

Paul

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

Re: 6.3 and Prolific PL-2303 USB serial adapter

[Paul de Weerd]

On Sun, Jun 17, 2018 at 07:30:34PM +0200, Jan-Piet Mens wrote:
| Hi Paul,
| 
| > Is there any specific marking on the device to suggest it's from HP?
| 
| oh, indeed. The photo at [1] shows the display with a prominent "HP" logo.
| 
| [1] https://mastodon.social/@jpmens/100220482259778231

Oh, that looks like a weird device, that may not be uplcom(4) at all.
On the other hand, it may still be, just with a uplcom chip in it to
talk to it.  Only one way to find out :)

| > Will it work with the uplcom(4) driver?  Who knows.  Try this (written
| > against -current, so may apply with a little bit of fuzz:
| 
| I'll have to learn how to build from source and find the time to do so.  I
| don't know when I'll be able to do so but will then report back.

To test that I didn't screw up the diff I sent you, I did build a
kernel with it.  If you trust me (you shouldn't I'm a stranger from
the internet), I'm happy to send you my kernel so you can give it a
try.  I *think* it should work without problems on 6.3, but I'm not
100% sure.  At least you should be able to boot in single user mode
(boot -s) and see if the device works that way.

Contact me off-list if you want to give it a try :)

Cheers,

Paul

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

Re: 6.3 and Prolific PL-2303 USB serial adapter

[Paul de Weerd]

Hi Jan-Piet,

This seems to be a USB to serial adapter made by HP, given the output
from Fedora's lsusb:

>   idVendor   0x03f0 Hewlett-Packard
>   idProduct  0x3524 
>   bcdDevice3.10
>   iManufacturer   1 Prolific Technology Inc.
>   iProduct2 USB-Serial Controller

Is there any specific marking on the device to suggest it's from HP?
Or is it just a cheap knock-off that (ab)used the HP vendor?

Will it work with the uplcom(4) driver?  Who knows.  Try this (written
against -current, so may apply with a little bit of fuzz:


Index: uplcom.c
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/uplcom.c,v
retrieving revision 1.71
diff -u -p -r1.71 uplcom.c
--- uplcom.c27 Apr 2018 09:40:59 -  1.71
+++ uplcom.c17 Jun 2018 16:42:58 -
@@ -140,6 +140,7 @@ static const struct usb_devno uplcom_dev
{ USB_VENDOR_ELECOM, USB_PRODUCT_ELECOM_UCSGT },
{ USB_VENDOR_ELECOM, USB_PRODUCT_ELECOM_UCSGT0 },
{ USB_VENDOR_HAL, USB_PRODUCT_HAL_IMR001 },
+   { USB_VENDOR_HP, USB_PRODUCT_HP_USB2SER },
{ USB_VENDOR_IODATA, USB_PRODUCT_IODATA_USBRSAQ },
{ USB_VENDOR_IODATA, USB_PRODUCT_IODATA_USBRSAQ5 },
{ USB_VENDOR_LEADTEK, USB_PRODUCT_LEADTEK_9531 },
Index: usbdevs
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.684
diff -u -p -r1.684 usbdevs
--- usbdevs 11 Apr 2018 04:15:26 -  1.684
+++ usbdevs 17 Jun 2018 16:42:30 -
@@ -2190,6 +2190,7 @@ product HP R1500G20x1fe0  R1500 G2 UPS
 product HP T750G2  0x1fe1  T750 G2 UPS
 product HP 640C0x2004  DeskJet 640c
 product HP 10200x2b17  LaserJet 1020
+product HP USB2SER 0x3524  Prolific uplcom
 product HP P1100   0x3102  Photosmart P1100
 product HP 10180x4117  LaserJet 1018
 product HP HN210E  0x811c  HN210E Ethernet
Index: usbdevs.h
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.696
diff -u -p -r1.696 usbdevs.h
--- usbdevs.h   11 Apr 2018 04:18:18 -  1.696
+++ usbdevs.h   17 Jun 2018 16:43:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.696 2018/04/11 04:18:18 bket Exp $  */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -2197,6 +2197,7 @@
 #defineUSB_PRODUCT_HP_T750G2   0x1fe1  /* T750 G2 UPS */
 #defineUSB_PRODUCT_HP_640C 0x2004  /* DeskJet 640c */
 #defineUSB_PRODUCT_HP_1020 0x2b17  /* LaserJet 1020 */
+#defineUSB_PRODUCT_HP_USB2SER  0x3524  /* Prolific uplcom */
 #defineUSB_PRODUCT_HP_P11000x3102  /* Photosmart P1100 */
 #defineUSB_PRODUCT_HP_1018 0x4117  /* LaserJet 1018 */
 #defineUSB_PRODUCT_HP_HN210E   0x811c  /* HN210E Ethernet */
Index: usbdevs_data.h
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.690
diff -u -p -r1.690 usbdevs_data.h
--- usbdevs_data.h  11 Apr 2018 04:18:18 -  1.690
+++ usbdevs_data.h  17 Jun 2018 16:43:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.690 2018/04/11 04:18:18 bket Exp $ */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -4604,6 +4604,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_HP, USB_PRODUCT_HP_1020,
"LaserJet 1020",
+   },
+   {
+   USB_VENDOR_HP, USB_PRODUCT_HP_USB2SER,
+   "Prolific uplcom",
},
{
USB_VENDOR_HP, USB_PRODUCT_HP_P1100,

Cheers,

Paul 'WEiRD' de Weerd

On Sun, Jun 17, 2018 at 04:51:12PM +0200, Jan-Piet Mens wrote:
| Hello!
| 
| Mike Belopuhov suggested I contact you with an issue I'm having [1] with a
| "Prolific USB-Serial Controller" for which USB manufacturer/product IDs are
| not being recognized.
| 
| Is the information I'm attaching sufficient? (I took the liberty of also
| attaching a Fedora `lsusb -v' output where the same device is recognized,
| hoping that helps.
| 
| Regards,
| 
|   -JP
| 
| 
| [1] https://mastodon.social/@jpmens/100220482259778231

| OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
| dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
| real mem = 16972566528 (16186MB)
| avail mem = 16451108864 (15689MB)
| mpath0 at root
| scsibus0 at mpath0: 256 targets
| mainbus0 at root
| bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries)
| bios0: vendor LENOVO version "G2ET94WW (2.54 )" date 04/30/2013
| bios0: LENOVO 2325Y2G
| acpi0 at bios0: rev 2
| acpi0: sleep states S0 S3 S4 S5

Re: ping.c minor bug discrepancy between reported size of icmp packet

[Paul de Weerd]

Hi Tom,

This is documented in ping(8):

 -s packetsize
 Specify the number of data bytes to be sent.  The default
 is 56, which translates into 64 ICMP data bytes when
 combined with the 8 bytes of ICMP header data.  The
 maximum packet size is 65467 for IPv4 and 65527 for IPv6.

You can play around with the 56 bytes, but those 8 are non-negotiable:
they're always added.  Note that it says 56 *data* bytes versus 64
(total) bytes.

On Fri, Jun 08, 2018 at 08:52:17PM +0100, Tom Smyth wrote:
| Hello I see a small discrepancy between the measurement
| of sent and received packets as displayed by ping command
| 
| on the wire the sent and received packets are the same size
| I had a brief go
| 
| foo# ping 5.134.88.1
| PING 5.134.88.1 (5.134.88.1): 56 data bytes
| 64 bytes from 5.134.88.1: icmp_seq=0 ttl=53 time=91.719 ms
| 
| it would appear that one measurement is the ICMP Payload only
| and the other is the ICMP payload + ICMP header  (8 byte difference)
| 
| 
| foo# grep -n " data bytes" /root/ping.c
| 760:printf("%s): %d data bytes\n", pr_addr(dst, dst->sa_len), datalen);
| foo# grep -n " bytes from" /root/ping.c
| 1248:   printf("%d bytes from %s: icmp_seq=%u", cc,
| 1292:   printf("%d bytes from %s: ", cc, pr_addr(from, fromlen));
| 
| looking at the source code it looks like the size = %d but %d is presenting
| different values
| I didnt see where %d was being changed between line 760 and line 1248
| It has been a while since I looked at C programming in anger and im a bit
| rusty...
| any pointers on where i should be looking so that I can submit a patch

You seem to be misunderstanding the format string passed that you
found.  %d is part of a format string, see printf(3).  The "%"
indicates a conversion specification, the "d" indicates the type of
conversion, in this case a signed integer.  The arguments following
the format string are filled in where a conversion specification is
given in the format string, in the order given.  So in this example:

#include ;

int main() {
int number;
const char* test;

text = "Hi Tom!";
number = 42;

printf("string: %s\nnumber: %d\n", string, number)
return 0;
}

The printf(3) function gets called with three arguments.  The first is
the format string: "string: %s\nnumber: %d\n".  As you can see,
there's two conversion specifications in there, "%s" and "%d".  "%s"
is for a "char*" argument, it gets replaced with the second argument
to the function (the variable 'string', which we gave the value "Hi
Tom!").  "%d" is for the integer argument, it gets replaced with a
decimal representation of the value of the third argument to the
function (the variable 'number', which we gave the value 42).

Applying this knowledge to the three lines you found in the ping
source:
In line 760, %d gets the value from variable 'datalen'.
In lines 1248 and 1292, %d gets the value from variable 'cc'.

Note that 'cc' could be changed between those two lines, so the value
printed in the end doesn't *have* to be the same - that depends on the
rest of the code.

Cheers,

Paul

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

Re: ifconfig(8): pltime and vltime are measured in seconds

[Paul de Weerd]

Hi Jason,

Thanks for your reply.  Yes, that's better.  Here you go:


Index: ifconfig.8
===
RCS file: /home/OpenBSD/cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.305
diff -u -p -r1.305 ifconfig.8
--- ifconfig.8  16 Mar 2018 19:45:13 -  1.305
+++ ifconfig.8  5 May 2018 13:25:12 -
@@ -1197,7 +1197,7 @@ Fill the interface index
 .Pq the lowermost 64th bit of an IPv6 address
 automatically.
 .It Cm pltime Ar n
-Set preferred lifetime for the address.
+Set preferred lifetime for the address, in seconds.
 .It Cm soii
 Enable persistent Semantically Opaque Interface Identifiers (SOIIs),
 as per RFC 7217, for link local and SLAAC addresses on the interface.
@@ -1219,7 +1219,7 @@ Set the IPv6 tentative address bit.
 .It Cm -tentative
 Clear the IPv6 tentative address bit.
 .It Cm vltime Ar n
-Set valid lifetime for the address.
+Set valid lifetime for the address, in seconds.
 .El
 .Sh INTERFACE GROUPS
 .Nm ifconfig

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

ifconfig(8): pltime and vltime are measured in seconds

[Paul de Weerd]

During a discussion on IPv6 with Undeadly editor Ross Richardson, he
pointed out that ifconfig(8) doesn't mention the unit of the arguments
to the pltime and vltime options.  Here's a diff to fix that:


Index: ifconfig.8
===
RCS file: /home/OpenBSD/cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.305
diff -u -p -r1.305 ifconfig.8
--- ifconfig.8  16 Mar 2018 19:45:13 -  1.305
+++ ifconfig.8  5 May 2018 11:45:03 -
@@ -1197,7 +1197,9 @@ Fill the interface index
 .Pq the lowermost 64th bit of an IPv6 address
 automatically.
 .It Cm pltime Ar n
-Set preferred lifetime for the address.
+Set preferred lifetime for the address,
+.Ar n
+is given in seconds.
 .It Cm soii
 Enable persistent Semantically Opaque Interface Identifiers (SOIIs),
 as per RFC 7217, for link local and SLAAC addresses on the interface.
@@ -1219,7 +1221,9 @@ Set the IPv6 tentative address bit.
 .It Cm -tentative
 Clear the IPv6 tentative address bit.
 .It Cm vltime Ar n
-Set valid lifetime for the address.
+Set valid lifetime for the address,
+.Ar n
+is given in seconds.
 .El
 .Sh INTERFACE GROUPS
 .Nm ifconfig

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

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

[Paul de Weerd]

ping

Anyone?  Buehler? :)

Paul

On Mon, Dec 25, 2017 at 12:23:44PM +0100, Paul de Weerd wrote:
| Hi all,
| 
| Sorry to keep harping on this script stuff, but I'd really like to see
| this committed.  I've just upgraded my laptop while doing some
| vlan-bridging debugging and suddenly script(1) lost my new favorite
| feature.
| 
| The manpage bits are OK jmc@; job@ and ian@ (off-list) OK'd the diff.
| Is anyone willing to commit it with those?
| 
| Thanks,
| 
| Paul
| 
| On Sat, Dec 16, 2017 at 09:45:02AM +0100, Paul de Weerd wrote:
| | On Fri, Dec 15, 2017 at 12:24:45PM +0100, Paul de Weerd wrote:
| | | I've updated the diff to add this example as per jmc's suggestion.  It
| | | now has:
| | | 
| | |   - add the `-c command` feature
| | |   - updates usage
| | |   - removes /* ARGSUSED */ lint comments
| | |   - documents the -c feature
| | |   - adds an example to the manpage
| | 
| | jmc@ pointed out a missing colon at the end of the example.  Apologies
| | for the extra noise.  Updated diff (still covers the above five
| | changes) included.
| | 
| | Cheers,
| | 
| | 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.115 Jan 2012 20:06:40 -  1.14
| | +++ script.116 Dec 2017 08:42:24 -
| | @@ -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
| | @@ -102,6 +108,11 @@ Name of the shell to be forked by
| |  If not set, the Bourne shell is assumed.
| |  (Most shells set this variable automatically.)
| |  .El
| | +.Sh EXAMPLES
| | +Start a virtual machine and log all console output to a file:
| | +.Bd -literal -offset indent
| | +$ script -c "vmctl start myvm -c" myvm.typescript
| | +.Ed
| |  .Sh HISTORY
| |  A predecessor called
| |  .Nm dribble
| | 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.c12 Apr 2017 14:49:05 -  1.33
| | +++ script.c14 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(s

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

[Paul de Weerd]

Hi all,

Sorry to keep harping on this script stuff, but I'd really like to see
this committed.  I've just upgraded my laptop while doing some
vlan-bridging debugging and suddenly script(1) lost my new favorite
feature.

The manpage bits are OK jmc@; job@ and ian@ (off-list) OK'd the diff.
Is anyone willing to commit it with those?

Thanks,

Paul

On Sat, Dec 16, 2017 at 09:45:02AM +0100, Paul de Weerd wrote:
| On Fri, Dec 15, 2017 at 12:24:45PM +0100, Paul de Weerd wrote:
| | I've updated the diff to add this example as per jmc's suggestion.  It
| | now has:
| | 
| | - add the `-c command` feature
| | - updates usage
| | - removes /* ARGSUSED */ lint comments
| | - documents the -c feature
| | - adds an example to the manpage
| 
| jmc@ pointed out a missing colon at the end of the example.  Apologies
| for the extra noise.  Updated diff (still covers the above five
| changes) included.
| 
| Cheers,
| 
| 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  16 Dec 2017 08:42:24 -
| @@ -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
| @@ -102,6 +108,11 @@ Name of the shell to be forked by
|  If not set, the Bourne shell is assumed.
|  (Most shells set this variable automatically.)
|  .El
| +.Sh EXAMPLES
| +Start a virtual machine and log all console output to a file:
| +.Bd -literal -offset indent
| +$ script -c "vmctl start myvm -c" myvm.typescript
| +.Ed
|  .Sh HISTORY
|  A predecessor called
|  .Nm dribble
| 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 {
| + 

cross ref ocspcheck in httpd.conf(5)

[Paul de Weerd]

I've been playing a bit with OCSP stapling in httpd and found the
documentation a bit lacking / confusing.  httpd says:

  ocsp file
  Specify an OCSP response to be stapled during TLS
  handshakes with this server.  The file should contain a
  DER-format OCSP response retrieved from an OCSP server
  for the certificate in use.  The default is to not use
  OCSP stapling.  If the OSCP response in file is empty,
  OCSP stapling will not be used.

But from this bit of text it's not clear that we have ocspcheck(8) to
create these files.  Only much further down is there a Xr to this
program.  I've added a Xr in the description of the ocsp option to
make this easier to find for the uninitiated.

While there, I was rather surprised that the file argument is relative
to the root of the system, not the chroot of the httpd process.  That
suggests (at least to me) that cron(8)'ing staple updates with
ocspcheck will require an httpd reload.  Why can't that simply be read
from the chroot during runtime, so updates to the file take effect
without a restart?  I have my staple file in the docroot (since I
understand it to be public data), is that a bad idea?

Anyway, thought it prudent to also add some words about this too, but
am less convinced it's correct.

Cheers,

Paul

Index: httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.87
diff -u -p -r1.87 httpd.conf.5
--- httpd.conf.529 Nov 2017 16:55:08 -  1.87
+++ httpd.conf.520 Dec 2017 07:26:20 -
@@ -557,10 +557,16 @@ should contain a DER-format OCSP respons
 OCSP server for the
 .Ar certificate
 in use.
+The
+.Xr ocspcheck 8
+utility can be used to create files in the proper format.
 The default is to not use OCSP stapling.
 If the OSCP response in
 .Ar file
 is empty, OCSP stapling will not be used.
+Note that the path to
+.Ar file
+is not relative to the chroot.
 .It Ic protocols Ar string
 Specify the TLS protocols to enable for this server.
 If not specified, the value


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

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

[Paul de Weerd]

On Fri, Dec 15, 2017 at 12:24:45PM +0100, Paul de Weerd wrote:
| I've updated the diff to add this example as per jmc's suggestion.  It
| now has:
| 
|   - add the `-c command` feature
|   - updates usage
|   - removes /* ARGSUSED */ lint comments
|   - documents the -c feature
|   - adds an example to the manpage

jmc@ pointed out a missing colon at the end of the example.  Apologies
for the extra noise.  Updated diff (still covers the above five
changes) included.

Cheers,

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.115 Jan 2012 20:06:40 -  1.14
+++ script.116 Dec 2017 08:42:24 -
@@ -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
@@ -102,6 +108,11 @@ Name of the shell to be forked by
 If not set, the Bourne shell is assumed.
 (Most shells set this variable automatically.)
 .El
+.Sh EXAMPLES
+Start a virtual machine and log all console output to a file:
+.Bd -literal -offset indent
+$ script -c "vmctl start myvm -c" myvm.typescript
+.Ed
 .Sh HISTORY
 A predecessor called
 .Nm dribble
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.c12 Apr 2017 14:49:05 -  1.33
+++ script.c14 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/ 

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

[Paul de Weerd]

On Thu, Dec 14, 2017 at 08:49:18AM +, Jason McIntyre wrote:
| 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"
| 
| you could add this as an EXAMPLES section, since it nicely describes
| another way to use script(1).

I've updated the diff to add this example as per jmc's suggestion.  It
now has:

- add the `-c command` feature
- updates usage
- removes /* ARGSUSED */ lint comments
- documents the -c feature
- adds an example to the manpage

There was a bit of off-list discussion with jmc@ on further
improvements that could be made to the manpage, but in order not to
add too much in one diff I decided to keep it at this.

Anybody any other comments?  Could this go in as it is now?

Cheers,

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.115 Jan 2012 20:06:40 -  1.14
+++ script.114 Dec 2017 10:04:09 -
@@ -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
@@ -102,6 +108,11 @@ Name of the shell to be forked by
 If not set, the Bourne shell is assumed.
 (Most shells set this variable automatically.)
 .El
+.Sh EXAMPLES
+Start a virtual machine and log all console output to a file
+.Bd -literal -offset indent
+$ script -c "vmctl start myvm -c" myvm.typescript
+.Ed
 .Sh HISTORY
 A predecessor called
 .Nm dribble
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.c12 Apr 2017 14:49:05 -  1.33
+++ script.c14 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/ 

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

[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 "-c command" option to script(1)

[Paul de Weerd]

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.115 Jan 2012 20:06:40 -  1.14
+++ script.114 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.c12 Apr 2017 14:49:05 -  1.33
+++ script.c14 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/ 

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

[Paul de Weerd]

Hi all,

As seen in NetBSD, FreeBSD and Linux, script(1) could do with a way to
tell it what command to run instead of your $SHELL.  This implements
the "-c command" option.  I've taken the logic to start the command
(and its arguments, if any) from crontab(1), execv'ing `sh -c
`.

I wrote this because I got fed up with typing `cu -l cuaU3 -s 19200`
right after starting script every time: it annoys my command line
editing fingers that I can't just recall what I did before.

There's a roundabout way of achieving something similar by setting
SHELL to some script that runs your command with its arguments, but
that's just silly (and nasty).

NetBSD: uses "-c command", executes the command using system(3)
Linux: uses "-c command", didn't look at the implementation
FreeBSD: uses arguments after the filename, wields execvp(3)

(these three have a bunch more extra options, all of which mostly look
like bullshit - specifying an alternative command seems the only
useful thing to me)

Illumos: feature parity with current OpenBSD, no -c command


My implementation worked from the get go, so there must be something
wrong with it.  All comments and feedback appreciated; asbestos
underwear at the ready.

Sample output:
[weerd@pom] $ obj/script -c "ls -l" output.`date +%s`
Script started, output file is output.1513183391
total 36
drwxr-xr-x  2 weerd  wsrc   512 May  9  2017 CVS
-rw-r--r--  1 weerd  wsrc   131 Sep 21  1997 Makefile
lrwxrwx---  1 weerd  wsrc23 Dec 13 17:42 obj -> /usr/obj/usr.bin/script
-rw-r--r--  1 weerd  wsrc 0 Dec 13 17:43 output.1513183391
-rw-r--r--  1 weerd  wsrc  3642 Dec 13 17:42 script.1
-rw-r--r--  1 weerd  wsrc  8464 Dec 13 17:41 script.c
Script done, output file is output.1513183391


Paul 'WEiRD' de Weerd

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.115 Jan 2012 20:06:40 -  1.14
+++ script.113 Dec 2017 12:27:32 -
@@ -39,6 +39,7 @@
 .Sh SYNOPSIS
 .Nm script
 .Op Fl a
+.Op Fl c Ar command
 .Op Ar file
 .Sh DESCRIPTION
 .Nm
@@ -65,6 +66,13 @@ 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
+.Ar command
+with its own arguments, enclose it in quotes.
 .El
 .Pp
 The script ends when the forked shell exits (a control-D
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.c12 Apr 2017 14:49:05 -  1.33
+++ script.c13 Dec 2017 12:15:20 -
@@ -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,15 +102,20 @@ 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);
exit(1);
@@ -163,7 +168,7 @@ main(int argc, char *argv[])
if (child)
dooutput();
else
-   doshell();
+   doshell(cmd);
}
 
bzero(, sizeof sa);
@@ -302,9 +307,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 +319,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/ 

Re: Have installboot default to the device carrying /

[Paul de Weerd]

On Tue, Nov 07, 2017 at 12:38:17AM -0700, Theo de Raadt wrote:
| >On Mon, Nov 06, 2017 at 03:24:30PM -0700, Theo de Raadt wrote:
| >| > Here's a diff that will make it default to the device carrying the
| >| > root filesystem.  Result this:
| >| 
| >| I disagree strongly with this.  installboot is a disruptive operation,
| >| and you should specify the device.
| >
| >Fair enough.  I thought it an easy diff that can't do harm (sane
| >defaults), but I see your point.  Thanks for the feedback.
| 
| You must be smoking something really strong.

Well .. I *am* Dutch, so... ;)

| It is never a good default for any program to open a raw partition and
| write something to it, based upon incomplete information.
| 
| All the installboot uses in the tree already know what disk and
| partition to write to, and I can assure you it is not the root
| partition, it tends to be a vnd0.  They are all explicit.
| 
| You can be explicit also.

And I will be.  My attempt at more laziness failed ;)

Paul

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

Re: Have installboot default to the device carrying /

[Paul de Weerd]

On Mon, Nov 06, 2017 at 03:24:30PM -0700, Theo de Raadt wrote:
| > Here's a diff that will make it default to the device carrying the
| > root filesystem.  Result this:
| 
| I disagree strongly with this.  installboot is a disruptive operation,
| and you should specify the device.

Fair enough.  I thought it an easy diff that can't do harm (sane
defaults), but I see your point.  Thanks for the feedback.

Paul

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

Re: Have installboot default to the device carrying /

[Paul de Weerd]

Now with manpage diff, fixed usage and less magic numbers (thanks to
florian@ again for the last two).

Paul

On Mon, Nov 06, 2017 at 03:58:50PM +0100, Paul de Weerd wrote:
| installboot(8) will error out when not given a device to install to:
| 
| [weerd@pom] $ doas installboot
| usage: installboot [-nv] [-r root] disk [stage1 [stage2]]
| 
| Here's a diff that will make it default to the device carrying the
| root filesystem.  Result this:
| 
| [weerd@pom] $ doas obj/installboot -v
| Using / as root
| installing bootstrap on /dev/rsd10c
| using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
| sd10: softraid volume with 1 disk(s)
| sd10: installing boot loader on softraid volume
| /usr/mdec/boot is 5 blocks x 16384 bytes
| sd0a: installing boot blocks on /dev/rsd0c, part offset 144
| master boot record (MBR) at sector 0
| partition 3: type 0xA6 offset 64 size 1953520001
| /usr/mdec/biosboot will be written at sector 64
| 
| Thanks to fobser@ for the cluebat, preventing me from diving too deep
| into pcreapi(3)...
| 
| Comments?
| 
| Paul 'WEiRD' de Weerd

Index: installboot.8
===
RCS file: /cvs/src/usr.sbin/installboot/installboot.8,v
retrieving revision 1.4
diff -u -p -r1.4 installboot.8
--- installboot.8   18 Jan 2014 18:14:21 -  1.4
+++ installboot.8   6 Nov 2017 15:12:54 -
@@ -24,8 +24,7 @@
 .Nm installboot
 .Op Fl nv
 .Op Fl r Ar root
-.Ar disk
-.Op Ar stage1 Op Ar stage2
+.Op Ar disk Op Ar stage1 Op Ar stage2
 .Sh DESCRIPTION
 .Nm
 installs bootstrap on the specified disk.
@@ -52,6 +51,7 @@ Specify the
 to install the bootstrap on.
 This may be specified using a full pathname, an abbreviated disk form,
 or a disklabel UID.
+It defaults to the device with the root filesystem.
 .It Ar stage1
 Specify the file to use for the primary bootstrap.
 If not specified, the default for this architecture will be used.
Index: installboot.c
===
RCS file: /cvs/src/usr.sbin/installboot/installboot.c,v
retrieving revision 1.11
diff -u -p -r1.11 installboot.c
--- installboot.c   29 Nov 2015 00:14:07 -  1.11
+++ installboot.c   6 Nov 2017 15:14:21 -
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "installboot.h"
 
@@ -39,7 +41,7 @@ usage(void)
 {
extern char *__progname;
 
-   fprintf(stderr, "usage: %s [-nv] [-r root] disk [stage1%s]\n",
+   fprintf(stderr, "usage: %s [-nv] [-r root] [disk [stage1%s]]\n",
__progname, (stages >= 2) ? " [stage2]" : "");
 
exit(1);
@@ -50,6 +52,7 @@ main(int argc, char **argv)
 {
char *dev, *realdev;
int devfd, opt;
+   struct statfs buf;
 
md_init();
 
@@ -74,10 +77,18 @@ main(int argc, char **argv)
argc -= optind;
argv += optind;
 
-   if (argc < 1 || argc > stages + 1)
+   if (argc > stages + 1)
usage();
 
-   dev = argv[0];
+   /* default to the device carrying the root filesystem */
+   if (argc == 0) {
+   statfs("/", );
+   dev = _mntfromname[sizeof("/dev/") - 1];
+   dev[strlen(dev) - 1] = '\0';
+   } else {
+   dev = argv[0];
+   }
+
if (argc > 1)
stage1 = argv[1];
if (argc > 2)

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

Have installboot default to the device carrying /

[Paul de Weerd]

installboot(8) will error out when not given a device to install to:

[weerd@pom] $ doas installboot
usage: installboot [-nv] [-r root] disk [stage1 [stage2]]

Here's a diff that will make it default to the device carrying the
root filesystem.  Result this:

[weerd@pom] $ doas obj/installboot -v
Using / as root
installing bootstrap on /dev/rsd10c
using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
sd10: softraid volume with 1 disk(s)
sd10: installing boot loader on softraid volume
/usr/mdec/boot is 5 blocks x 16384 bytes
sd0a: installing boot blocks on /dev/rsd0c, part offset 144
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 1953520001
/usr/mdec/biosboot will be written at sector 64

Thanks to fobser@ for the cluebat, preventing me from diving too deep
into pcreapi(3)...

Comments?

Paul 'WEiRD' de Weerd

Index: installboot.c
===
RCS file: /cvs/src/usr.sbin/installboot/installboot.c,v
retrieving revision 1.11
diff -u -p -r1.11 installboot.c
--- installboot.c   29 Nov 2015 00:14:07 -  1.11
+++ installboot.c   6 Nov 2017 14:52:23 -
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "installboot.h"
 
@@ -50,6 +52,7 @@ main(int argc, char **argv)
 {
char *dev, *realdev;
int devfd, opt;
+   struct statfs buf;
 
md_init();
 
@@ -74,10 +77,18 @@ main(int argc, char **argv)
argc -= optind;
argv += optind;
 
-   if (argc < 1 || argc > stages + 1)
+   if (argc > stages + 1)
usage();
 
-   dev = argv[0];
+   /* default to the device carrying the root filesystem */
+   if (argc == 0) {
+   statfs("/", );
+   dev = _mntfromname[5];
+   dev[strlen(dev) - 1] = '\0';
+   } else {
+   dev = argv[0];
+   }
+
if (argc > 1)
stage1 = argv[1];
if (argc > 2)


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

Re: inteldrm(4) diff needs review and testing

[Paul de Weerd]

Hi Mark,

On Sun, Jul 16, 2017 at 03:19:41PM +0200, Mark Kettenis wrote:
| Can somebody test the following diff on Ivy Bridge or Haswell (Intel
| HD Graphics 2500/4000/4600/4700/5000/5100/5200)?
| 
| When I added support for the command parser, I took a bit of a
| shortcut and implemented the hash tables as a single linked list.
| This diff fixes that.
| 
| For the hash function I used a "mode (size-1)" approach that leaves
| one of the hash table entries unused.  Perhaps somebody with a CS
| background has a better idea that isn't too complicated to implement?
| 
| Paul, Stuart, there is a small chance that this will improve the
| vncviewer performance.

It doesn't (vncviewer still consumes a full CPU core), but otherwise
there are no regressions from the previous situation.

Thanks Mark!

Paul

OpenBSD 6.1-current (GENERIC.MP) #6: Mon Jul 17 09:52:56 CEST 2017
we...@pom.alm.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34243919872 (32657MB)
avail mem = 33200308224 (31662MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (88 entries)
bios0: vendor Dell Inc. version "A12" date 05/06/2015
bios0: Dell Inc. OptiPlex 9020
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT 
ASF! DMAR
acpi0: wakeup devices UAR1(S3) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) 
PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) HDEF(S4) PEG0(S4) 
PEGP(S4) PEG1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.85 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 3392845890 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.15 MHz
cpu5: 

Re: [PATCH] cp(1): add -v option for verbosity

[Paul de Weerd]

On Sun, Jun 25, 2017 at 10:49:04PM +0200, Landry Breuil wrote:
| > | Alternatively one can use rsync(1), but that is not part of the base.
| > 
| > That may work for cp(1), but it's hard to replicate mv(1) behavior
| > with rsync (only metadata changes when on the same fs) or even
| > impossible to replciate rm(1) behavior.
| 
| Technically it could be possible to replicate mv with rsync
| --remove-source-files ... :)

rsync will still copy the file first, while mv can simply move the
file to another directory without the copy operation when it's on the
same filesystem (my comment about 'only metadata changes').

Cheers,

Paul

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

Re: [PATCH] rm(1): add -v option for verbosity

[Paul de Weerd]

Hi Ingo,

On Sun, Jun 25, 2017 at 03:12:26PM +0200, Ingo Schwarze wrote:
| Hi,
| 
| Job Snijders wrote on Sun, Jun 25, 2017 at 02:06:16PM +0200:
| 
| > This patch adds a '-v' option to rm(1) for more verbose output.
| 
| Do not add new options to standard utilities, unless you can show
| that they are unusually useful in practice *and* practically
| every other system out there has them, with a compatible user
| interface across practically all systems.
| 
| Adding -v to rm(1) probably wouldn't make the very high bar against
| adding non-standard options even if almost everybody else had it
| (which i didn't check, to not waste time) because it's completely
| useless.
| 
| If you are really unsure, study the output of
| 
|   $ find *
| 
| first, before typing
| 
|   $ rm -rf *
| 
| No non-standard option is needed at all for this.

Very bad example.  You study the output of find * and another process
writes a new file in the mean time.  With rm -v, you would've known.

The solution here (currently) is to find * -delete -print.  That
solves it for rm (well, it moves the problem elsewhere (and is more to
type)), but doesn't help the mv or cp cases.  And I'd say that for
completeness' sake, the option should be added to all three of these
(or none, as is currently the case).

| It's also strongly in violation of the UNIX philosophy (each utility,
| do one thing, and do it well).  rm(1) removes files, and does so
| well.  rm(1) does *not* trespass on ls(1) and find(1) territory to
| list files.

Well, find(1) trespasses the rm(1) territory with its -delete option,
the only real solution to doing what you suggested.

Reporting on what you did is still doing your job.  Just a bit more
verbose (which, in certain situations, I would consider a BETTER job).

Comparing rm(1) to ls(1) is weird: ls doesn't delete files.  In this
case, rm(1) isn't "listing" the files as ls(1) does, it *reports* on
files that have been deleted.  A small, but significant difference.

|  Besides, they way your proposed rm(1) extension lists
| files is not doing it well at all.  The output is awful.

Agreed.  Just listing the filename(s) would suffice.

Paul 'WEiRD' de Weerd

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

Re: [PATCH] cp(1): add -v option for verbosity

[Paul de Weerd]

On Sun, Jun 25, 2017 at 06:22:05PM +0200, Job Snijders wrote:
| Dear Alexander,
| 
| On Sun, Jun 25, 2017 at 06:13:40PM +0200, Alexander Hall wrote:
| > On June 25, 2017 2:06:20 PM GMT+02:00, Job Snijders  
wrote:
| > >This patch adds a -v option to cp(1) for more verbose output.
| > >
| > >   $ touch a b; mkdir c
| > >   $ cp -v a b c
| > >   'a' -> 'c/a'
| > >   'b' -> 'c/b'
| > >   $ cp -rv c d
| > >   'c' -> 'd/'
| > >   'c/a' -> 'd/a'
| > >   'c/b' -> 'd/b'
| > 
| > Pardon my ignorance, but why?
| 
| A fair question.  I myself have two use cases, but others may have their
| own to add.
| 
| When a glob pattern is used, it can be beneficial to immediately observe
| (during the execution of the command) which files have been copied.
| 
| When copying very large trees, the -v option provides some insight as to
| what progress the cp operation has made so far.

I like the -v option for the above reason most (and have missed it on
several occassions): copy, move or remove a whole bunch of files; it
takes a while.  Is it working?  Or is NFS stalling / IO to the storage
device otherwise acting up?

Also, when using these tools in crons, it can be very useful to have
cron send out reports of the files copied/moved/deleted.  Note that
directories can be altered outside of the control of said script: it
is impossible to deterministically figure out what cp/mv/rm did after
(or before, as the 'study `find *`' hint suggests) they are run.

| Alternatively one can use rsync(1), but that is not part of the base.

That may work for cp(1), but it's hard to replicate mv(1) behavior
with rsync (only metadata changes when on the same fs) or even
impossible to replciate rm(1) behavior.

Cheers,

Paul 'WEiRD' de Weerd

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

Re: Finish the link-kit job

[Paul de Weerd]

On Fri, Jun 23, 2017 at 07:53:35AM -0600, Theo de Raadt wrote:
| > Perhaps we'll come up with a simpler way down the road, but it isn't
| > *that* hard for manual upgrades. once you've installed the kernels, make
| > sure you've got the correct hash:
| > 
| > sha256 -h /var/db/kernel.SHA256 /bsd
| > 
| > and the rc script will do the rest after the next reboot. I think this
| > is bearable.
| 
| I think that is bad advice.  At next reboot, it will build a new
| kernel using the link kit.  But where's the step that updates the link
| kit??  You didn't describe it, so uhm... two boots later you'll be
| running something different than intended.

The compile.tgz tarball will have been updated, but not yet extracted.
Something /etc/rc will do at the next boot.

The "problem" with Theo (Buehler)'s approach is that that next boot
will still not use a relinked kernel, so you need yet another reboot
to relink.  (like after an install or upgrade you're still booting
into the release or snapshot kernel, instead of a relinked one)

That's the benefit of having a simple to use script to call from
userland *before* the reboot: you get that "every computer is
unique"-feel you mentioned.

Of course, that's not guaranteed to work and has issues with the
bsd.rd environment as you pointed out.

| The correct process is much simpler.  In a kernel compile directory,
| simply type
| 
|make install
| 
| That updates the kernel, the link kit, and the hash.

Although a very cool solution for those machines where I (and other
people) build kernels, this is about an in-place upgrade using
snapshot or release kernels and file sets: the kernel compile
directory doesn't necessarily exist.

Paul 'WEiRD' de Weerd

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

Re: Finish the link-kit job

[Paul de Weerd]

On Fri, Jun 23, 2017 at 04:28:15AM -0600, Theo de Raadt wrote:
| > /mnt/usr/sbin/chroot /mnt /usr/local/libexec/reorder_kernel
| >
| > ...
| > 
| > +   mail -Es "$(hostname) Kernel relink info" root >/dev/null
| 
| No, that isn't cool.
| 
| Yes, we are going to link in the install media.  But not by reusing code
| that way.  Any chroot handling must be done much more carefully, and
| select the right commands/subsystems to use more carefully.

Hmm, I see your point.  I liked the idea of moving the rc bits into a
separate script so people following 'Upgrading manually' could benefit
more easily, but obviously didn't think the constraints of bsd.rd through
enough.

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

Re: Finish the link-kit job

[Paul de Weerd]

On Wed, Jun 21, 2017 at 01:13:31PM -0600, Theo de Raadt wrote:
| Future work should be to see if we can build a fresh kernel at
| install/upgrade time, for that "every computer is unique" feel.

How about we move the rc bits out from rc and into a small script
that we call from rc.  Now we can also easily call it from the install
and/or upgrade script with something like 

/mnt/usr/sbin/chroot /mnt /usr/local/libexec/reorder_kernel

and have a new kernel always.  Not sure if that's feasible in this
case, but it looks doable.  Here's the diff that moves the rc bits
into a separate script.  Not included are the bits for the install
script.


Index: etc/rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.504
diff -u -p -u -r1.504 rc
--- etc/rc  22 Jun 2017 16:03:36 -  1.504
+++ etc/rc  23 Jun 2017 07:58:50 -
@@ -219,38 +219,6 @@ reorder_libs() {
fi
 }
 
-# Re-link the kernel, placing the objects in a random order.
-# Replace current with relinked kernel and inform root about it.
-reorder_kernel() {
-   (
-   set -e
-   _compile_dir=/usr/share/compile
-   _kernel=$(sysctl -n kern.osversion)
-   _kernel=${_kernel%#*}
-   _kernel_dir=$_compile_dir/$_kernel
-   _sha256=/var/db/kernel.SHA256
-
-   if [[ -f /usr/share/compile.tgz ]]; then
-   rm -rf $_compile_dir
-   mkdir -m 700 -p $_compile_dir
-   tar -C $_compile_dir -xzf /usr/share/compile.tgz $_kernel
-   rm -f /usr/share/compile.tgz
-   fi
-
-   sha256 -q -C $_sha256 /bsd
-
-   cd $_kernel_dir
-   make newbsd   >$_kernel_dir/log 2>&1
-   make newinstall >>$_kernel_dir/log 2>&1
-   (umask 077 && sha256 -h $_sha256 /bsd)
-
-   (echo "Kernel has been relinked and is active on next reboot\n"; \
-   cat $_sha256; echo "\nRelink log:\n"; cat $_kernel_dir/log ) |
-   mail -Es "$(hostname) Kernel relink info" root >/dev/null
-
-   ) >/dev/null 2>&1 &
-}
-
 # Run rc.* script and email output to root.
 # Usage: run_upgrade_script firsttime|sysmerge
 run_upgrade_script() {
@@ -619,7 +587,9 @@ echo -n 'starting local daemons:'
 start_daemon apmd sensorsd hotplugd watchdogd cron wsmoused xenodm
 echo '.'
 
-reorder_kernel
+# Re-link the kernel, placing the objects in a random order.
+# Replace current with relinked kernel and inform root about it.
+/usr/libexec/reorder_kernel
 
 date
 exit 0
Index: libexec/Makefile
===
RCS file: /cvs/src/libexec/Makefile,v
retrieving revision 1.65
diff -u -p -u -r1.65 Makefile
--- libexec/Makefile26 Nov 2015 19:13:14 -  1.65
+++ libexec/Makefile23 Jun 2017 07:32:35 -
@@ -6,7 +6,7 @@
 SUBDIR= comsat fingerd ftpd getty ld.so lockspool login_chpass \
login_lchpass login_passwd login_radius login_reject \
login_skey login_token login_yubikey mail.local \
-   rpc.rquotad rpc.rstatd rpc.rusersd rpc.rwalld \
+   reorder_kernel rpc.rquotad rpc.rstatd rpc.rusersd rpc.rwalld \
security spamd spamd-setup spamlogd talkd tradcpp
 
 .include 
Index: libexec/reorder_kernel/Makefile
===
RCS file: libexec/reorder_kernel/Makefile
diff -N libexec/reorder_kernel/Makefile
--- /dev/null   1 Jan 1970 00:00:00 -
+++ libexec/reorder_kernel/Makefile 23 Jun 2017 07:56:12 -
@@ -0,0 +1,11 @@
+#  $Id$
+
+MAN=   reorder_kernel.8
+
+SCRIPT=reorder_kernel.sh
+
+realinstall:
+${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
+   ${.CURDIR}/${SCRIPT} ${DESTDIR}${BINDIR}/reorder-kernel
+
+.include 
Index: libexec/reorder_kernel/reorder_kernel.8
===
RCS file: libexec/reorder_kernel/reorder_kernel.8
diff -N libexec/reorder_kernel/reorder_kernel.8
--- /dev/null   1 Jan 1970 00:00:00 -
+++ libexec/reorder_kernel/reorder_kernel.8 23 Jun 2017 07:56:34 -
@@ -0,0 +1,13 @@
+.Dd $Mdocdate$
+.Dt REORDER_KERNEL 8
+.Os
+.Sh NAME
+.Nm reorder_kernel
+.Nd build a new /bsd with randomly ordered objects
+.Sh SYNOPSIS
+.Nm reorder_kernel
+.Oc
+.Sh DESCRIPTION
+.Nm
+will take the kernel object files from /usr/share/compile/ and build a
+new randomly ordered /bsd out of them.
Index: libexec/reorder_kernel/reorder_kernel.sh
===
RCS file: libexec/reorder_kernel/reorder_kernel.sh
diff -N libexec/reorder_kernel/reorder_kernel.sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ libexec/reorder_kernel/reorder_kernel.sh23 Jun 2017 07:53:36 -
@@ -0,0 +1,34 @@
+#!/bin/sh -
+#  $Id$
+
+# standard license here; attribution to rpe@?
+
+# Re-link the kernel, placing the objects in a random order.
+# Replace current with relinked kernel and inform root about it.
+(
+   set -e
+   

Re: mcast-proxy daemon

[Paul de Weerd]

On Sat, May 27, 2017 at 11:05:13PM +0200, Paul de Weerd wrote:
|   - lacks an rc.d init script

Here's a diff that adds an rc.d script 'mcastproxy' (other daemons
that have a '-' in their name also drop it in their rc.d script, so I
followed that example) I stuck it in /etc/rc around the startup of
other proxies, but there may be better places for it.

Cheers,

Paul 'WEiRD' de Weerd

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

Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.498
diff -u -p -r1.498 rc
--- rc  30 May 2017 12:04:26 -  1.498
+++ rc  3 Jun 2017 14:29:13 -
@@ -549,7 +549,7 @@ if ifconfig lo0 inet6 >/dev/null 2>&1; t
fi
 fi
 
-start_daemon hostapd lpd smtpd slowcgi httpd ftpd
+start_daemon hostapd lpd smtpd slowcgi httpd ftpd mcastproxy
 start_daemon ftpproxy ftpproxy6 tftpd tftpproxy identd inetd rarpd bootparamd
 start_daemon rbootd mopd vmd spamd spamlogd sndiod
 echo '.'
Index: rc.conf
===
RCS file: /cvs/src/etc/rc.conf,v
retrieving revision 1.216
diff -u -p -r1.216 rc.conf
--- rc.conf 30 May 2017 12:04:26 -  1.216
+++ rc.conf 3 Jun 2017 14:27:48 -
@@ -38,6 +38,7 @@ ldattach_flags=NO # for normal use: "[op
 ldomd_flags=NO
 ldpd_flags=NO
 lpd_flags=NO   # for normal use: "" (or "-l" for debugging)
+mcastproxy_flags=NO
 mopd_flags=NO
 mrouted_flags=NO   # be sure to enable multicast below
 npppd_flags=NO
Index: rc.d/mcastproxy
===
RCS file: rc.d/mcastproxy
diff -N rc.d/mcastproxy
--- /dev/null   1 Jan 1970 00:00:00 -
+++ rc.d/mcastproxy 3 Jun 2017 14:26:53 -
@@ -0,0 +1,11 @@
+#!/bin/sh
+#
+# $OpenBSD$
+
+daemon="/usr/sbin/mcast-proxy"
+
+. /etc/rc.d/rc.subr
+
+rc_reload=NO
+
+rc_cmd $1

Re: [PATCH] ntpd: allow to specify a source IP address for outgoing queries

[Paul de Weerd]

Works for me, verified both v4 and v6 selection actually uses that
address.  Suggested a small improvement for ntpd.conf(5) to Job
privately.

Would love to see this feature get imported :)

Thanks Job!

Paul

On Tue, May 30, 2017 at 06:10:03PM +0200, Job Snijders wrote:
| On Sun, May 28, 2017 at 10:52:24PM +0200, Sebastian Benoit wrote:
| > which makes me think:
| > would a global local-address be good enough?
| 
| Attached is a patch that allows you to specify the source for outgoing
| queries, as a global option. Example ntpd.conf:
| 
| query from 165.254.255.33
| query from 2001:728:1808::26
| servers ntp.ring.nlnog.net
| 
| I have a number of remarks myself:
| 
| - unsure about the bzero() in parse_config()
| 
| - should we check 2+ declarations of 'query from', or just use the
|   last one like this patch does now, (we don't check for duplicate
|   'weight' etc either)
| 
| - the ipv4 / ipv6 approach with 'struct dual_addr' seems clumsy, is
|   this what life is like in an ipv4 + ipv6 world? Any suggestions
|   how to improve?
| 
| Kind regards,
| 
| Job
| 
| ---
|  src/usr.sbin/ntpd/client.c| 13 +
|  src/usr.sbin/ntpd/ntp.c   |  1 +
|  src/usr.sbin/ntpd/ntpd.conf.5 |  8 
|  src/usr.sbin/ntpd/ntpd.h  |  7 +++
|  src/usr.sbin/ntpd/parse.y | 31 ++-
|  5 files changed, 59 insertions(+), 1 deletion(-)
| 
| diff --git a/src/usr.sbin/ntpd/client.c b/src/usr.sbin/ntpd/client.c
| index ddbb1281..7d921dcf 100644
| --- a/src/usr.sbin/ntpd/client.c
| +++ b/src/usr.sbin/ntpd/client.c
| @@ -137,11 +137,24 @@ client_query(struct ntp_peer *p)
|  
|   if (p->query->fd == -1) {
|   struct sockaddr *sa = (struct sockaddr *)>addr->ss;
| + struct sockaddr *qa4 = (struct sockaddr *)>query_addr.v4;
| + struct sockaddr *qa6 = (struct sockaddr *)>query_addr.v6;
|  
|   if ((p->query->fd = socket(p->addr->ss.ss_family, SOCK_DGRAM,
|   0)) == -1)
|   fatal("client_query socket");
|  
| + if (p->addr->ss.ss_family == qa4->sa_family) {
| + if (bind(p->query->fd, qa4, SA_LEN(qa4)) == -1)
| + fatal("couldn't bind to IPv4 query address: %s",
| + log_sockaddr(qa4));
| + }
| + else if (p->addr->ss.ss_family == qa6->sa_family) {
| + if (bind(p->query->fd, qa6, SA_LEN(qa6)) == -1)
| + fatal("couldn't bind to IPv6 query address: %s",
| + log_sockaddr(qa6));
| + }
| +
|   if (connect(p->query->fd, sa, SA_LEN(sa)) == -1) {
|   if (errno == ECONNREFUSED || errno == ENETUNREACH ||
|   errno == EHOSTUNREACH || errno == EADDRNOTAVAIL) {
| diff --git a/src/usr.sbin/ntpd/ntp.c b/src/usr.sbin/ntpd/ntp.c
| index f3366640..b0f80294 100644
| --- a/src/usr.sbin/ntpd/ntp.c
| +++ b/src/usr.sbin/ntpd/ntp.c
| @@ -521,6 +521,7 @@ ntp_dispatch_imsg_dns(void)
|   if (peer->addr_head.pool) {
|   npeer = new_peer();
|   npeer->weight = peer->weight;
| + npeer->query_addr = peer->query_addr;
|   h->next = NULL;
|   npeer->addr = h;
|   npeer->addr_head.a = h;
| diff --git a/src/usr.sbin/ntpd/ntpd.conf.5 b/src/usr.sbin/ntpd/ntpd.conf.5
| index 6e4e0012..b8f03b22 100644
| --- a/src/usr.sbin/ntpd/ntpd.conf.5
| +++ b/src/usr.sbin/ntpd/ntpd.conf.5
| @@ -67,6 +67,14 @@ or
|  listen on 127.0.0.1
|  listen on ::1
|  listen on 127.0.0.1 rtable 4
| +.It Xo Ic source from Ar address
| +.Xc
| +Specify a Local IP address the
| +.Xr ntpd 8
| +daemon should use for outgoing queries.
| +.Bd -literal -offset indent
| +query from 10.0.0.1
| +query from 2001:db8::1
|  .Ed
|  .It Xo Ic sensor Ar device
|  .Op Ic correction Ar microseconds
| diff --git a/src/usr.sbin/ntpd/ntpd.h b/src/usr.sbin/ntpd/ntpd.h
| index 613b29b2..ded2948a 100644
| --- a/src/usr.sbin/ntpd/ntpd.h
| +++ b/src/usr.sbin/ntpd/ntpd.h
| @@ -106,6 +106,11 @@ struct listen_addr {
|   int  rtable;
|  };
|  
| +struct dual_addr {
| + struct sockaddr_storage v4;
| + struct sockaddr_storage v6;
| +};
| +
|  struct ntp_addr {
|   struct ntp_addr *next;
|   struct sockaddr_storage  ss;
| @@ -153,6 +158,7 @@ struct ntp_peer {
|   struct ntp_query*query;
|   struct ntp_offsetreply[OFFSET_ARRAY_SIZE];
|   struct ntp_offsetupdate;
| + struct dual_addr query_addr;
|   enum client_statestate;
|   time_t   next;
|   time_t   

Re: mcast-proxy daemon

[Paul de Weerd]

Hi tech@,

I've been talking to Rafael about this piece of code over the last
week a bit, and have tried it on my home TV setup.  My ISP has a
multicast setup for watching television, with their set-top-box
connected to my TV.  Up until now, I was using net/igmpproxy on my
OpenBSD gateway to get the streams from ISP to STB.

At first, Rafael's code didn't work for me, but after some back and
forth with him we got things going with the below diff (to be applied
on top of Rafael's diff).  Obviously some things are still missing:

- runs as user _dhcp
- make install gives you /mcast-proxy
- lacks an rc.d init script
- no pledge(2) for the important part of the code

However, this is already an incredible jump forward in terms of
usability (sane defaults!) and stability, let alone safe coding
practices over igmpproxy: runs as root, doesn't drop privs, doesn't
chroot, etc.

Compare my old /etc/igmpproxy.conf with my new /etc/mcast-proxy.conf:

--- /etc/igmpproxy.conf --
quickleave
phyint vlan4 upstream ratelimit 0 threshold 1 altnet 10.0.0.0/8
phyint vlan10 downstream ratelimit 0 threshold 1
phyint lo0 disabled
phyint em0 disabled
phyint em1 disabled
phyint em2 disabled
phyint em3 disabled
phyint em4 disabled
phyint em5 disabled
phyint bridge0 disabled
phyint bridge1 disabled
phyint bridge20 disabled
phyint vlan20 disabled
phyint vlan21 disabled
--

--- /etc/mcast-proxy.conf 
interface vlan4 {
upstream
source 10.0.0.0/8
}

interface vlan10 {
downstream
}
--

It would be really awesome to have something like this in base.  Your
networking kit really isn't complete without a multicast proxying
solution!  (plus, it's nice to have something that exercises these
codepaths in base).

Cheers,

Paul 'WEiRD' de Weerd

PS: Please note that any mistakes in the below diff are mine; Rafael
guided me through writing this over e-mail.  Sending this out so
others can help test, as Rafael mentioned he'd be AFK for a few days.

diff -ur a/mcast-proxy.c b/mcast-proxy.c
--- a/mcast-proxy.c Sat May 27 22:20:02 2017
+++ b/mcast-proxy.c Sat May 27 18:25:53 2017
@@ -475,24 +475,6 @@
return 0;
}
 
-   /* IP header validations. */
-   if (ip->ip_v != IPVERSION) {
-   log_debug("%s: wrong IP version", __func__);
-   return 0;
-   }
-   hlen = ip->ip_hl << 2;
-   if (hlen < sizeof(*ip)) {
-   log_debug("%s: wrong IP header length", __func__);
-   return 0;
-   }
-   if ((ip->ip_off & IP_OFFMASK) != 0) {
-   log_debug("%s: fragmented packet", __func__);
-   return 0;
-   }
-   if (ip->ip_ttl == 0) {
-   log_debug("%s: invalid TTL", __func__);
-   return 0;
-   }
if (ip->ip_src.s_addr == INADDR_ANY ||
ip->ip_dst.s_addr == INADDR_ANY) {
log_debug("%s: invalid packet addresses", __func__);
@@ -525,6 +507,25 @@
log_debug("%s: expected IGMP message, got %d",
__func__, ip->ip_p);
return NULL;
+   }
+   /* IP header validations. */
+   if (ip->ip_v != IPVERSION) {
+   log_debug("%s: wrong IP version", __func__);
+   return 0;
+   }
+   hlen = ip->ip_hl << 2;
+   if (hlen < sizeof(*ip)) {
+   log_debug("%s: wrong IP header length", __func__);
+   return 0;
+   }
+/* Disable check to see if it makes a difference */
+/* if ((ip->ip_off & IP_OFFMASK) != 0) {
+   log_debug("%s: fragmented packet", __func__);
+   return 0;
+   }*/
+   if (ip->ip_ttl == 0) {
+   log_debug("%s: invalid TTL", __func__);
+   return 0;
}
 
hlen = ip->ip_hl << 2;
diff -ur a/mrt.c b/mrt.c
--- a/mrt.c Sat May 27 22:20:02 2017
+++ b/mrt.c Sat May 27 22:10:01 2017
@@ -514,7 +514,7 @@
 {
struct sockaddr_storage ss;
 
-   if (mr->mr_upstream == NULL) {
+   if (upstreamif == NULL) {
log_debug("%s: no upstream interface", __func__);
return;
}
@@ -538,7 +538,7 @@
if (LIST_EMPTY(>mr_molist))
return;
 
-   mcast_join(mr->mr_upstream, );
+   mcast_join(upstreamif, );
mr->mr_state = MS_JOINED;
break;
 
@@ -547,7 +547,7 @@
if (!LIST_EMPTY(>mr_molist))
return;
 
-   mcast_leave(mr->mr_upstream, );
+   mcast_leave(upstreamif, );
mr->mr_state = MS_NOTJOINED;
break;
 


On Fri, May 19, 2017 at 06:25:01PM +0200, Rafael Zalamena wrote:
| Hello tech@,
| 
| I 

HP C8000 workstations

[Paul de Weerd]

Hi all,

I have a couple of HP C8000 workstations collecting dust at home.  Now
that the hppa64 port has been cancelled, my chances of ever running
OpenBSD on one of them have gone from slim to none.  They're not
supported, something with the chipset (ZX1?) that is undocumented, I
believe.  So no OpenBSD/hppa on these babies either.

I offer these to anyone interested, free of charge.  Shipping we'll
need to sort out (they're *heavy*!), pick-up is always possible (I
live in Almere, The Netherlands).

Please ping me off-list if you're interested.

# Specs as listed by seller (never verified)
CPU PA8800 - 900mhz
Mem: 2GB
HDD - 36GB SCSI
T1 Video card

# some details about these machines:
http://www.openpa.net/systems/hp_c8000.html

# a couple of pictures of one of mine:
http://www.weirdnet.nl/misc/hp.html

Again, there's three of these, free to a good home.

Cheers,

Paul 'WEiRD' de Weerd

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

Simtec USB Entropy Key

[Paul de Weerd]

Hi all,

While cleaning out my closet I found a Simtec USB Entropy Key (hidden
under those HP C8000 workstations :)

It attaches as:

May 31 13:09:26 pom /bsd: umodem0 at uhub3
May 31 13:09:26 pom /bsd:  port 5 configuration 1 interface 0 "Simtec 
Electronics Entropy Key" rev 2.00/2.00 addr 6
May 31 13:09:26 pom /bsd: umodem0: data interface 1, has no CM over data, has 
no break
May 31 13:09:26 pom /bsd: umodem0: status change notification available
May 31 13:09:26 pom /bsd: ucom0 at umodem0

I've not done anything with this thing, ever.  If there is a developer
interested in it, I'm happy to ship it world-wide.  Only one on offer
though.

Some pictures available at http://www.weirdnet.nl/misc/simtec.html

Cheers,

Paul 'WEiRD' de Weerd

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

Re: Journal Implementation

[Paul de Weerd]

On Tue, Jun 02, 2015 at 07:33:58PM +, Stefan wrote:
| http://www.openbsd.org/faq/faq8.html#Journaling

Right, that doesn't help, it's not a tip for someone interested in
*developing a journaling system for UFS*...  You can rest assured
they're already aware that OpenBSD doesn't support journaling.

| On Tue, Jun 2, 2015, 2:31 PM Walter Neto wsouz...@gmail.com wrote:
|  Hy..
| 
|  I want to help OpenBSD developing a journaling system for UFS.
| 
|  Someone can give me a tip?

Please have a look at this implementation from the FFS author:

http://www.mckusick.com/softdep/suj.pdf

I believe the code is available in FreeBSD.  All it takes is porting.

Before you start your work, keep in mind that there's no guarantee
that it will be incorporated in OpenBSD.  But, if you present your
case with proper diffs, you should at least get some attention.

Good luck!

Paul 'WEiRD' de Weerd

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

Re: Small ifconfig output tweak for inet6?

[Paul de Weerd]

On Thu, Mar 26, 2015 at 01:48:03PM +0100, Martin Pieuchot wrote:
| How do people feel about printing the prefixlen in CIDR notation?  I'm
| annoyed about outputs not fitting in 80 chars when using autoconf magic:
| 
| -inet6 fd00::f2de:f1ff:fe6a:15d1 prefixlen 64 autoconf pltime 3594 vltime 7194
| +inet6 fd00::f2de:f1ff:fe6a:15d1/64 autoconf pltime 3594 vltime 7194

Love this!  And you can still copy/paste from 'inet6' upto '64' into
an ifconfig line to get that address configured on an interface.

| While here can I convert  autoconfprivacy to  privacy or +privacy?

'autoconfprivacy' seems too long to me too, yeah...

Cheers,

Paul 'WEiRD' de Weerd

| Index: ifconfig.c
| ===
| RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
| retrieving revision 1.296
| diff -u -p -r1.296 ifconfig.c
| --- ifconfig.c5 Feb 2015 10:30:25 -   1.296
| +++ ifconfig.c26 Mar 2015 12:15:10 -
| @@ -3192,7 +3192,7 @@ in6_alias(struct in6_ifreq *creq)
|   warn(SIOCGIFNETMASK_IN6);
|   } else {
|   sin6 = (struct sockaddr_in6 *)ifr6.ifr_addr;
| - printf( prefixlen %d, prefix(sin6-sin6_addr,
| + printf(/%d, prefix(sin6-sin6_addr,
|   sizeof(struct in6_addr)));
|   }
|  
| @@ -3216,7 +3216,7 @@ in6_alias(struct in6_ifreq *creq)
|   if (ifr6.ifr_ifru.ifru_flags6  IN6_IFF_AUTOCONF)
|   printf( autoconf);
|   if (ifr6.ifr_ifru.ifru_flags6  IN6_IFF_PRIVACY)
| - printf( autoconfprivacy);
| + printf( privacy);
|   }
|  
|   if (scopeid)
| 

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

Re: changing ffs mount between rw and ro while preserving softdep

[Paul de Weerd]

On Thu, Aug 28, 2014 at 06:27:48PM +, Miod Vallat wrote:
|  Which is why the current way to remove softdep from a filesystem is a
|  rw+softdep - ro - rw transition, which would no longer work with your
|  diff.
|  
|  It would work, but you'd have to explicitly disable softdep, as one might
|  expect to be required when removing softdep:
| 
| Oh, indeed.
| 
| Then it's a matter of deciding whether we want mount -u to simply update
| flags (and then only toggle ro/rw, and leave softdep unchanged) or to
| update behaviour (and then clear softdep on rw-ro transition as softdep
| do not apply to read-only filesystems). You're in favour of the former,
| I am in favour of the latter. Who wants to be the referee?

I hardly qualify as a referee but I'll add that I think Boudewijn's
approach makes more sense to me.  Even though I quite often use
-ur/-uw to drop softdep from filesystems.  Especially given
Boudewijn's point that putting ro,softdep in fstab results in a
filesystem that would get (still have) softdep after -uw.

I don't have very strong feelings on the matter (but, yes, strong
enough to write this e-mail ;)

Cheers,

Paul 'WEiRD' de Weerd

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