Re: posix_spawn(3): explain that handling NULL envp is an extension
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 \&Ed Shouten Aq Mt e...@freebsd.org +.An \&Ed 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/
randomize daily/weekly/monthly crons
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: [PATCH] fast conditional console scrolling
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: FPU
Re: [PATCH] fast conditional console scrolling
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: setitimer(2): don't round up it_value
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, &new_timer, NULL); gettimeofday(&str, NULL); while (trigger == 0) pause(); gettimeofday(&end, NULL); d = (end.tv_sec - str.tv_sec) * 100 + \ end.tv_usec - str.tv_usec;
Re: httpd(8): fastcgi & Content-Length: 0
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(&resp->http_headers, | "Transfer-Encoding", "chunked") == NULL) | return (-1); | + } else { | + key.kv_key = "Content-Length"; | + if ((kv = kv_find(&resp->http_headers, &key)) == NULL) { | + if (kv_add(&resp->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/
ntpd constraints and caching proxies (CDNs)
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: ucc(4): consumer control keyboard device driver
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: 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,xTP
allow KARL with config(8)'d kernels
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: allow KARL with config(8)'d kernels
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/
Re: allow KARL with config(8)'d kernels
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 -0000 @@ -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/reo
Re: allow KARL with config(8)'d kernels
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
reduce debug logging from slowcgi
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
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&m=163024631923964&w=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 |
Re: allow KARL with config(8)'d kernels
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
Re: allow KARL with config(8)'d kernels
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 re
Re: call for testing: rad(8) - a rtadvd(8) replacement
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: nsd 4.1.24
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: Add acpipci(4) on amd64
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 tar
Re: Unwind + NSD usage question
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 @9.9
Re: Unwind + NSD usage question
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/
New hw.perfpolicy behavior
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: New hw.perfpolicy behavior
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/
Re: acme-client config grammar improvements
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/
Typo fix in comment sys/dev/usb/ugold.c
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, &desc, &size); -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: sensor value last change time not updated?
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->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->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->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->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, &sensor, &sensorlen, 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->sc_sensor.tv); | ./dev/pv/hypervic.c:microtime(&sc->sc_sensor.tv); | ./dev/pv/vmt.c: struct timeval *guest = &sc->sc_sensor.tv; | ./dev/pv/vmmci.c: struct timeval *guest = &sc->sc_sensor.tv; | ./dev/usb/udcf.c: microtime(&sc->sc_sensor.tv); | | I have a ugold(4) device and will gladly test any improvements/patches. | | -- | Kind regards, | Hiltjo -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: sensor value last change time not updated?
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->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->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->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->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->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->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->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
Re: sensor value last change time not updated?
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?
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?
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/
missing support for OHMS and ENERGY sensors in sensorsd
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/
find -exec util {} arg + confusion
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/
Re: find -exec util {} arg + confusion
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/
Re: find -exec util {} arg + confusion
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
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
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: Opportunistic DoT for unwind(8)
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: dhcpleased(8): close unneeded bpf FDs
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/
ifconfig(8): pltime and vltime are measured in seconds
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: ifconfig(8): pltime and vltime are measured in seconds
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/
Re: ping.c minor bug discrepancy between reported size of icmp packet
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: 6.3 and Prolific PL-2303 USB serial adapter
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: 6.3 and Prolific PL-2303 USB serial adapter
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
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
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: sbin/wsconsctl: show more data
Lots of negativity here, so I just wanted to chime in - really love the new console font! Crisp and easily readable letters, big enough to be readable, with a reasonable number of letters per line (${COLUMNS}) en lines per screen (${LINES}). It does mean pretty big characters on big screens when in console mode, but on big screens I want to run X anyway, so it's all good. What I understand of the algorithm to pick the font size makes a lot of sense to me. Thank you Frederic for all the effort you put into this font and making it happen on the console and in X through the fonts/spleen port! Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: what.1: remove BUGS section
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/
Add support for Meinberg DCF600USB to umbg(4)
Hi all, After Peter J. Philipp asked about Meinberg DCF clock support on misc@ in https://marc.info/?l=openbsd-misc&m=155205024420585&w=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: 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,P
[1/4] Re: Add support for Meinberg DCF600USB to umbg(4)
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/
[4/4] Re: Add support for Meinberg DCF600USB to umbg(4)
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)
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->sc_sensordev, &sc->sc_timedelta); -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
[2/4] Re: Add support for Meinberg DCF600USB to umbg(4)
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/
[5/4] Re: Add support for Meinberg DCF600USB to umbg(4)
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/
Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4)
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/
Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4)
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: [3/4] Re: Add support for Meinberg DCF600USB to umbg(4)
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->sc_sensordev, &sc->sc_timedelta); | | | -- | >[<++>-]<+++.>+++[<-->-]<.>+++[<+ | +++>-]<.>++[<>-]<+.--.[-] | http://www.weirdnet.nl/ | -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: usb drivers & arches (Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4))
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)
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->sc_sensordev, &sc->sc_timedelta); | | | | | | -- | | >[<++>-]<+++.>+++[<-->-]<.>+++[<+ | | +++>-]<.>++[<>-]<+.--.[-] | | http://www.weirdnet.nl/ |
Re: [PATCH] Add swich to enable/disable re-link the kernel at startup
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: [PATCH] Add swich to enable/disable re-link the kernel at startup
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: grep ".one\|.two" doesn't work on OpenBSD. Is it expected?
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
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: Thank you for making p2k9 possible!
On Fri, Oct 16, 2009 at 10:37:11PM -0400, STeve Andre' wrote: | You can see whats been happening if you are subscribed to the cvs src | changes list. Offhand at least 30 new ports were added, more than 250 | were updated, lots were tweaked, and the pkg_add code was worked on. | Likely I missed a lot, too--I was mostly focused on the ports changes | so more stuff was done than I saw. When you want to find out whats | happened (happening) at a hackathon, watching the commits is the | best way to see whats going on. Don't forget about the work done to libtool. The commits there show a lot of work, mostly done by ste...@. Very promising stuff... Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: patch ftp-proxy, proposal
On Tue, Jan 12, 2010 at 09:38:32AM +0100, Tiery DENYS wrote: | On Mon, Jan 11, 2010 at 2:08 PM, Bob Beck wrote: | Yes I prefer waiting here instead of sending any response on ident port. | (silent fw) How can you claim 'silent fw' if it was the source of an ftp connection ? | I will not explain the benefit of dropping packets silently. This is | something we will not change, even if it is only for ident protocol. | The problem deals with public ftp servers, like university or other | research/company and we can't reconfigure them. If we keep in mind that our | firewall will always drop packets silently, there are not a lot of | solutions. Sure, don't change your firewall, but do realize that your argument is flawed. There is traffic originatimg from the address, so it must be alive. Simply sending a RST for attempted connections to the ident port does not tell anyone anything new. What does block drop gain you over block reject in this case ? (not a question to debate on the list, just something to think about) Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: more options for top
On Sat, Jan 23, 2010 at 12:13:23AM -0500, Ted Unangst wrote: | I find it very useful to sort by command as it usually means less bouncing | around. While we're here, add sort by pid too. What's the added value of sorting by PID when ypu have randomized PIDs ? I see your 'don't jump around' argument, but sorting by command solves that already. I would see more benefit in sorting by process age, if a all possible. Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: ksh file completion bug
On Mon, Feb 22, 2010 at 10:50:39PM +0100, LEVAI Daniel wrote: | Hi! | | With ksh's Vi edit mode I've experienced the following: | If a file's size is exactly 2GiB or more, pdksh fails to complete its name | during filename completion (eg.: hitting TAB or CTRL+e or whatever). | If the file's size is just one byte short of the 2 gigs, then the completion | works fine. | | Quick way to test it: | $ dd if=/dev/zero of=./2GiB bs=1024 count=2097152 | $ ls -la 2G ... => nothing | | | Daniel | | | ps.: this is under -current and i386 That's some weird shit you've got going there... $ dd if=/dev/zero of=2gigabyte bs=2048 count=1 seek=1048575 $ echo 2g -> immediately completes to 2gigabyte. $ echo $VISUAL vi $ echo $SHELL /bin/ksh $ echo $KSH_VERSION @(#)PD KSH v5.2.14 99/07/13.2 $ sysctl kern.version kern.version=OpenBSD 4.7-beta (GENERIC.MP) #86: Wed Feb 10 07:17:52 MST 2010 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Tried it on an (admittedly older) i386 and sparc64 machine and got the same. Also tried it with a non-sparse file (seek= creates sparse files when you're writing past the end of the file) and it still worked. So .. uhm .. works for me [TM] Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: bge(4) diff needs testing.
On Sat, Apr 17, 2010 at 12:17:40PM -0400, Brad wrote: | On Sat, Apr 10, 2010 at 04:58:36PM -0400, Brad wrote: | > Please test the following diff with any bge(4) adapters. Just checking to | > ensure no regressions with known working adapters. Just check that things | > are working as usual. Just bringing in some fixes for some of the newer | > chipsets soon to appear. Nothing changed with existing chipsets though. | | oops. there was a typo in the original diff. please test this revision. This one works just fine on my older machine (Dell OptiPlex GX620) running amd64 : bge0 at pci2 dev 0 function 0 "Broadcom BCM5751" rev 0x01, BCM5750 A1 (0x4001): apic 8 int 16 (irq 11), address 00:13:72:bc:66:f7 brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 Found no issues with light use (v4, v6, multicast). Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: fxp(4) diff to make use of m_defrag()
Dug up my old i386 again. This applies cleanly and works fine with some light testing (v4 NFS/ftp, v6 ssh/ftp, basic multicast). fxp0 at pci2 dev 1 function 0 "Intel 8255x" rev 0x08, i82559: apic 2 int 17 (irq 12), address 00:02:b3:19:8b:4b inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4 Paul 'WEiRD' de Weerd On Thu, Dec 24, 2009 at 02:50:52PM -0500, Brad wrote: | The following diff replaces the hand rolled code to deal with | really long mbuf chains with the use of m_defrag(). | | | Index: fxp.c | === | RCS file: /cvs/src/sys/dev/ic/fxp.c,v | retrieving revision 1.100 | diff -u -p -r1.100 fxp.c | --- fxp.c 15 Oct 2009 17:54:54 - 1.100 | +++ fxp.c 24 Dec 2009 19:40:44 - | @@ -678,8 +678,8 @@ fxp_start(struct ifnet *ifp) | struct fxp_softc *sc = ifp->if_softc; | struct fxp_txsw *txs = sc->sc_cbt_prod; | struct fxp_cb_tx *txc; | - struct mbuf *m0, *m = NULL; | - int cnt = sc->sc_cbt_cnt, seg; | + struct mbuf *m0; | + int cnt = sc->sc_cbt_cnt, seg, error; | | if ((ifp->if_flags & (IFF_OACTIVE | IFF_RUNNING)) != IFF_RUNNING) | return; | @@ -696,33 +696,22 @@ fxp_start(struct ifnet *ifp) | if (m0 == NULL) | break; | | - if (bus_dmamap_load_mbuf(sc->sc_dmat, txs->tx_map, | - m0, BUS_DMA_NOWAIT) != 0) { | - MGETHDR(m, M_DONTWAIT, MT_DATA); | - if (m == NULL) | + error = bus_dmamap_load_mbuf(sc->sc_dmat, txs->tx_map, | + m0, BUS_DMA_NOWAIT); | + if (error != 0 && error != EFBIG) | + break; | + if (error != 0) { | + if (m_defrag(m0, M_DONTWAIT)) | break; | - if (m0->m_pkthdr.len > MHLEN) { | - MCLGET(m, M_DONTWAIT); | - if (!(m->m_flags & M_EXT)) { | - m_freem(m); | - break; | - } | - } | - m_copydata(m0, 0, m0->m_pkthdr.len, mtod(m, caddr_t)); | - m->m_pkthdr.len = m->m_len = m0->m_pkthdr.len; | if (bus_dmamap_load_mbuf(sc->sc_dmat, txs->tx_map, | - m, BUS_DMA_NOWAIT) != 0) { | - m_freem(m); | + m0, BUS_DMA_NOWAIT) != 0) | break; | - } | } | | + /* | + * WE ARE NOW COMMITTED TO TRANSMITTING THE PACKET. | + */ | IFQ_DEQUEUE(&ifp->if_snd, m0); | - if (m != NULL) { | - m_freem(m0); | - m0 = m; | - m = NULL; | - } | | txs->tx_mbuf = m0; | | | -- | This message has been scanned for viruses and | dangerous content by MailScanner, and is | believed to be clean. | -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: xl(4) diff to make use of m_defrag()
Also tested this patch on my old i386. xl0 at pci2 dev 1 function 0 "3Com 3c905B 100Base-TX" rev 0x30: apic 2 int 17 (irq 12), address 00:50:04:44:dc:5c exphy0 at xl0 phy 24: 3Com internal media interface Same tests (ftp, nfs, ssh, ipv4 and ipv6), no regressions. Paul 'WEiRD' de Weerd On Thu, Dec 24, 2009 at 03:08:54AM -0500, Brad wrote: | The following diff replaces the hand rolled code to deal with | really long mbuf chains with the use of m_defrag(). | | | Index: xl.c | === | RCS file: /cvs/src/sys/dev/ic/xl.c,v | retrieving revision 1.88 | diff -u -p -r1.88 xl.c | --- xl.c 22 Dec 2009 21:10:25 - 1.88 | +++ xl.c 24 Dec 2009 07:57:00 - | @@ -1614,23 +1614,25 @@ xl_encap(struct xl_softc *sc, struct xl_ | | map = sc->sc_tx_sparemap; | | -reload: | error = bus_dmamap_load_mbuf(sc->sc_dmat, map, | m_head, BUS_DMA_NOWAIT); | - | - if (error && error != EFBIG) { | - m_freem(m_head); | - return (1); | + if (error != 0 && error != EFBIG) | + goto drop; | + if (error != 0) { | + if (m_defrag(m_head, M_DONTWAIT)) | + goto drop; | + error = bus_dmamap_load_mbuf(sc->sc_dmat, map, | + m_head, BUS_DMA_NOWAIT); | + if (error != 0) | + goto drop; | } | | /* |* Start packing the mbufs in this chain into | - * the fragment pointers. Stop when we run out | - * of fragments or hit the end of the mbuf chain. | + * the fragment pointers. Stop when we hit the | + * end of the mbuf chain. |*/ | for (frag = 0, total_len = 0; frag < map->dm_nsegs; frag++) { | - if (frag == XL_MAXFRAGS) | - break; | total_len += map->dm_segs[frag].ds_len; | c->xl_ptr->xl_frag[frag].xl_addr = | htole32(map->dm_segs[frag].ds_addr); | @@ -1638,38 +1640,6 @@ reload: | htole32(map->dm_segs[frag].ds_len); | } | | - /* | - * Handle special case: we used up all 63 fragments, | - * but we have more mbufs left in the chain. Copy the | - * data into an mbuf cluster. Note that we don't | - * bother clearing the values in the other fragment | - * pointers/counters; it wouldn't gain us anything, | - * and would waste cycles. | - */ | - if (error) { | - struct mbuf *m_new = NULL; | - | - MGETHDR(m_new, M_DONTWAIT, MT_DATA); | - if (m_new == NULL) { | - m_freem(m_head); | - return (1); | - } | - if (m_head->m_pkthdr.len > MHLEN) { | - MCLGET(m_new, M_DONTWAIT); | - if (!(m_new->m_flags & M_EXT)) { | - m_freem(m_new); | - m_freem(m_head); | - return (1); | - } | - } | - m_copydata(m_head, 0, m_head->m_pkthdr.len, | - mtod(m_new, caddr_t)); | - m_new->m_pkthdr.len = m_new->m_len = m_head->m_pkthdr.len; | - m_freem(m_head); | - m_head = m_new; | - goto reload; | - } | - | bus_dmamap_sync(sc->sc_dmat, map, 0, map->dm_mapsize, | BUS_DMASYNC_PREWRITE); | | @@ -1708,6 +1678,10 @@ reload: | BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); | | return (0); | + | + drop: | + m_freem(m_head); | + return (1); | } | | /* | | -- | This message has been scanned for viruses and | dangerous content by MailScanner, and is | believed to be clean. | -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: pcn(4) diff to make use of m_defrag()
While digging for old fxp's and xl's I came across something I should've buried a long time ago: a pcn(4) (10Mbit only, with a 10base2 connector !). I tried the patch below, same tests (they just took a bit longer). Everything works just fine, no regressions. pcn0 at pci2 dev 1 function 0 "AMD 79c970 PCnet-PCI" rev 0x02, Am79c970, rev 1: apic 2 int 17 (irq 12), address 02:07:01:1b:b4:ac Paul 'WEiRD' de Weerd On Thu, Dec 24, 2009 at 03:15:10PM -0500, Brad wrote: | The following diff replaces the hand rolled code to deal with | really long mbuf chains with the use of m_defrag(). | | | Index: if_pcn.c | === | RCS file: /cvs/src/sys/dev/pci/if_pcn.c,v | retrieving revision 1.22 | diff -u -p -r1.22 if_pcn.c | --- if_pcn.c 13 Aug 2009 14:24:47 - 1.22 | +++ if_pcn.c 24 Dec 2009 20:12:39 - | @@ -851,7 +851,7 @@ void | pcn_start(struct ifnet *ifp) | { | struct pcn_softc *sc = ifp->if_softc; | - struct mbuf *m0, *m; | + struct mbuf *m0; | struct pcn_txsoft *txs; | bus_dmamap_t dmamap; | int error, nexttx, lasttx = -1, ofree, seg; | @@ -875,7 +875,6 @@ pcn_start(struct ifnet *ifp) | IFQ_POLL(&ifp->if_snd, m0); | if (m0 == NULL) | break; | - m = NULL; | | /* Get a work queue entry. */ | if (sc->sc_txsfree == 0) | @@ -890,23 +889,16 @@ pcn_start(struct ifnet *ifp) |* were short on resources. In this case, we'll copy |* and try again. |*/ | - if (bus_dmamap_load_mbuf(sc->sc_dmat, dmamap, m0, | - BUS_DMA_WRITE|BUS_DMA_NOWAIT) != 0) { | - MGETHDR(m, M_DONTWAIT, MT_DATA); | - if (m == NULL) | + error = bus_dmamap_load_mbuf(sc->sc_dmat, dmamap, m0, | + BUS_DMA_WRITE|BUS_DMA_NOWAIT); | + if (error != 0 && error != EFBIG) | + break; | + if (error != 0) { | + if (m_defrag(m0, M_DONTWAIT)) | break; | - if (m0->m_pkthdr.len > MHLEN) { | - MCLGET(m, M_DONTWAIT); | - if ((m->m_flags & M_EXT) == 0) { | - m_freem(m); | - break; | - } | - } | - m_copydata(m0, 0, m0->m_pkthdr.len, mtod(m, caddr_t)); | - m->m_pkthdr.len = m->m_len = m0->m_pkthdr.len; | error = bus_dmamap_load_mbuf(sc->sc_dmat, dmamap, | - m, BUS_DMA_WRITE|BUS_DMA_NOWAIT); | - if (error) | + m0, BUS_DMA_WRITE|BUS_DMA_NOWAIT); | + if (error != 0) | break; | } | | @@ -929,20 +921,13 @@ pcn_start(struct ifnet *ifp) |*/ | ifp->if_flags |= IFF_OACTIVE; | bus_dmamap_unload(sc->sc_dmat, dmamap); | - if (m != NULL) | - m_freem(m); | break; | } | | - IFQ_DEQUEUE(&ifp->if_snd, m0); | - if (m != NULL) { | - m_freem(m0); | - m0 = m; | - } | - | /* |* WE ARE NOW COMMITTED TO TRANSMITTING THE PACKET. |*/ | + IFQ_DEQUEUE(&ifp->if_snd, m0); | | /* Sync the DMA map. */ | bus_dmamap_sync(sc->sc_dmat, dmamap, 0, dmamap->dm_mapsize, | | -- | This message has been scanned for viruses and | dangerous content by MailScanner, and is | believed to be clean. | -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: ipv6 support for tftp
On Wed, Sep 08, 2010 at 09:35:10AM -0300, Gleydson Soares wrote: | On Wed, Sep 08, 2010 at 11:51:11AM -0300, Gleydson Soares wrote: | > hi, | > | > - ipv6 support for tftp client. | > | > based on an old itojun's diff. | | i forgot to attach the diff inline. Works for me: [we...@impreza] $ tftp 2001:7b8:3af::1 tftp> get bsd.rd Received 7241454 bytes in 7.5 seconds Thanks, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: mcast-proxy daemon
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->mr_molist)) return; - mcast_join(mr->mr_upstream, &ss); + mcast_join(upstreamif, &ss); mr->mr_state = MS_JOINED; break; @@ -547,7 +547,7 @@ if (!LIST_EMPTY(&mr->mr_molist)) return; - mcast_leave(mr->mr_upstream, &ss); + mcast_leave(upstreamif, &ss); mr->mr_state = MS_NOTJOINED; break; On Fri, May 19, 2017 at 06:25:01PM +0200, Rafael Zalamena wrote: | Hel
Re: [PATCH] ntpd: allow to specify a source IP address for outgoing queries
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 *)&p->addr->ss; | + struct sockaddr *qa4 = (struct sockaddr *)&p->query_addr.v4; | + struct sockaddr *qa6 = (struct sockaddr *)&p->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
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: Finish the link-kit job
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: Finish the link-kit job
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
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: [PATCH] cp(1): add -v option for verbosity
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: [PATCH] rm(1): add -v option for verbosity
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
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: inteldrm(4) diff needs review and testing
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: 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,FSGSB
HP C8000 workstations
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
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/
Have installboot default to the device carrying /
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("/", &buf); + dev = &buf.f_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: Have installboot default to the device carrying /
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("/", &buf); + dev = &buf.f_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/
Re: Have installboot default to the device carrying /
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 /
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/
Add "-c command" option to script(1)
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(&sa, 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: Add "-c command" option to script(1)
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(&sa, 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)
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(&sa, 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)
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(&sa, 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)
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(&sa, 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/
cross ref ocspcheck in httpd.conf(5)
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)
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(&sa, 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 execu
Re: Add "-c command" option to script(1)
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(&sa, 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); |
Re: NOINET6 by default
Hi Henning, Thanks, I really like this. On Wed, May 14, 2014 at 11:29:20PM +0200, Henning Brauer wrote: | the only use case that needs config adoption: people ONLY using | link-local, they will need to put +inet6 in the corresponding | hostname.if file. People that set net.inet6.ip6.accept_rtadv=1 but don't actively do router solicitation will now no longer get an IPv6 address (a real one, not just link local) after some time (when there are router advertisements on the network). This seems blatantly obvious, but might still warrant an entry in current.html as it's contrary to previous behavior. Suggested diff included, Anyway, I've verified that my system now comes up with ::1 and fe80::1%lo0 on lo0 but other interfaces (software ones like vether(4) and real ones like re(4) and iwn(4)) don't get an address after just bringing the interface up. Using +inet6 works and gets me a link-local address (and, when I do this on a network with router advertisements, I get an address and an autoconfprivacy address after some time). And of course, configuring IPv6 works as usual. | ok? This makes a whole lot of sense to me. Please make OpenBSD the first OS to do (this part of) v6 in a sensible way. Paul 'WEiRD' de Weerd Index: current.html === RCS file: /cvs/www/faq/current.html,v retrieving revision 1.508 diff -u -p -r1.508 current.html --- current.html7 May 2014 13:38:43 - 1.508 +++ current.html14 May 2014 22:01:30 - @@ -52,6 +52,7 @@ 2014/04/21 - lpd(8): hosts.equiv removed 2014/04/22 - kerberosV removed 2014/05/03 - bcrypt hash advanced to $2b$ mode +2014/05/16 - IPv6 defaults to off when not configured @@ -490,6 +491,14 @@ manually or use the kerberos packages wh The bcrypt(3) hash has been advanced to the new $2b$ mode. Newly created hashes will follow this form. Older systems may not understand this format. + + +2014/05/16 - IPv6 defaults to off when not configured< + +Interfaces no longer get a link-local address configured by default +when no other IPv6 configuration is present. If you want the old +behaviour restored for sepcific interfaces, add "+inet6" to the +hostname.if(5) file or on the ifconfig(8) command line. | Index: sys/net/if.c | === | RCS file: /cvs/src/sys/net/if.c,v | retrieving revision 1.288 | diff -u -p -r1.288 if.c | --- sys/net/if.c 13 May 2014 14:33:25 - 1.288 | +++ sys/net/if.c 14 May 2014 21:03:45 - | @@ -429,6 +429,9 @@ if_attach(struct ifnet *ifp) | #else | TAILQ_INSERT_TAIL(&ifnet, ifp, if_list); | #endif | +#ifdef INET6 | + ifp->if_xflags |= IFXF_NOINET6; | +#endif | | m_clinitifp(ifp); | | Index: sbin/ifconfig/ifconfig.8 | === | RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v | retrieving revision 1.241 | diff -u -p -r1.241 ifconfig.8 | --- sbin/ifconfig/ifconfig.8 22 Apr 2014 10:11:32 - 1.241 | +++ sbin/ifconfig/ifconfig.8 13 May 2014 14:58:58 - | @@ -283,8 +283,12 @@ Disable | on the given interface and remove all configured | .Xr inet6 4 | addresses, including the link-local ones. | -To turn it on again, assign any inet6 address or run | +To turn it on again, use +inet6, assign any inet6 address or run | .Xr rtsol 8 . | +.It +inet6 | +Enable | +.Xr inet6 4 | +and assign a link local address if the interface doesn't have one yet. | .It Cm instance Ar minst | Set the media instance to | .Ar minst . | Index: sbin/ifconfig/ifconfig.c | === | RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v | retrieving revision 1.283 | diff -u -p -r1.283 ifconfig.c | --- sbin/ifconfig/ifconfig.c 12 May 2014 08:47:37 - 1.283 | +++ sbin/ifconfig/ifconfig.c 13 May 2014 14:56:25 - | @@ -412,6 +412,7 @@ const struct cmd { | { "-flowdst", 1,0, unsetpflow_receiver }, | { "pflowproto", NEXTARG,0, setpflowproto }, | { "-inet6", IFXF_NOINET6, 0, setifxflags } , | + { "+inet6", 0, 0, setia6eui64 }, | { "keepalive", NEXTARG2, 0, NULL, setkeepalive }, | { "-keepalive", 1, 0, unsetkeepalive }, | { "add",NEXTARG,0, bridge_add }, | @@ -1310,7 +1311,9 @@ setia6eui64(const char *cmd, int val) | const struct in6_addr *lladdr = NULL; | struct in6_addr *in6; | | - if (afp->af_af != AF_INET6) | + if (!strcmp(cmd, "+inet6")) | + setifxflags("inet6", -IFXF_NOINET6); | + else if (afp->af_af != AF_INET6) | errx(1, "%s not allowed for the AF", cmd); | in6 = (struct in6_addr *)&in6_addreq.ifra_addr.sin6_addr; | if (memcmp(&in6addr_any.s6_addr[8], &in6->s6_a
link-local address issues
Hi all, Martin, There seems to be an issue with generating eui64 addresses. [weerd@pom] $ ifconfig em0 em0: flags=8843 mtu 1500 lladdr b8:ca:3a:93:03:e8 inet6 fe80::3c16:979e:9360:ec89%em0 prefixlen 64 scopeid 0x1 [weerd@pom] $ sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC.MP) #136: Mon May 19 09:40:42 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP [weerd@twix] $ ifconfig vr0 vr0: flags=48843 mtu 1500 lladdr 00:0d:b9:14:6f:08 inet6 fe80::cc08:36fd:9a4a:b30%vr0 prefixlen 64 scopeid 0x1 [weerd@twix] $ sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC) #115: Mon May 19 08:39:42 MDT 2014 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC [weerd@drop] $ ifconfig iwn0 iwn0: flags=8843 mtu 1500 lladdr 88:53:2e:d9:dd:9d inet6 fe80::c0d9:7d41:5229:b6f3%iwn0 prefixlen 64 scopeid 0x1 [weerd@drop] $ sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC.MP) #6: Sat May 17 11:23:06 CEST 2014 we...@drop.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP (ifconfig output redacted for brevity) As can be seen, the host part of the link-local address doesn't resemble the lladdr at all. This isn't a problem for outgoing connections, but when using SLAAC the global unicast address that is assigned is now suddenly different from what it used to be (so from what is in DNS), so I can't easily connect to my machines over IPv6 anymore. I'm not sure when this started, the last kernel that still worked with the 'regular' eui64 link-local address on machine 'pom' was: OpenBSD 5.5-current (GENERIC.MP) #105: Sun May 4 18:35:59 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP One final thing to note is that these 'new' addresses are persistent across reboots (so it's not a case of misapplied autoconfprivacy, I think). Before I go bisecting for the faulty commit, does anybody have an idea what might be going on? mpi, I'm CC:'ing you since you've been doing some changes in this and related areas so maybe this rings a bell with you. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: link-local address issues
On Tue, May 20, 2014 at 12:02:47PM +0200, Stefan Sperling wrote: | On Tue, May 20, 2014 at 11:33:48AM +0200, Paul de Weerd wrote: | > As can be seen, the host part of the link-local address doesn't | > resemble the lladdr at all. This isn't a problem for outgoing | > connections, but when using SLAAC the global unicast address that is | > assigned is now suddenly different from what it used to be (so from | > what is in DNS), so I can't easily connect to my machines over IPv6 | > anymore. | | I"m seeing this, too (-current built last Sunday). | | What strikes me is that the link-local address contains the same | bits as the SLAAC address (lines aligned to make this easier to see): | | lladdr 40:61:86:85:70:71 | inet6 fe80::b020:cbf3:e5a1:d0d3%re0 prefixlen 64 scopeid 0x1 | inet6 2001:67c:1407:10:b020:cbf3:e5a1:d0d3 prefixlen 64 autoconf pltime 604638 vltime 2591838 |^^^ | | The first address is supposed to be the link-local address based | on the MAC (40:61:86:85:70:71), but somehow contains the SLAAC | address bits... ??? The SLAAC address isn't the source of these bits, they're generated and then used as the eui64 host part of both the link-local and the SLAAC address. Previously, the SLAAC address would also have the same bits as the link-local address (but then they'd both be based off the lladdr with the 6th bit inverted and 0xfffe inserted in the middle). This should be the behavior that you get with mpi's diff (thanks, Martin!). I'm updating my tree and will compile a new kernel shortly but won't be able to reboot and test until tonight. Cheers, Paul 'WEiRD' de Weerd | On another box which runs a snapshot built April 29 this still | works as expected: | | lladdr 00:00:24:c9:2f:01 | inet6 fe80::200:24ff:fec9:2f01%vr1 prefixlen 64 scopeid 0x2 -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: bpf_mtap_stripvlan
On Thu, Jul 10, 2014 at 01:30:29PM +0100, Stuart Henderson wrote: | On 2014/07/10 13:11, Henning Brauer wrote: | > I committed the bpf chunk, but nothing is using it yet. pls give the | > if_vlan.c chunk a spin. | | I think weerd@ might need something similar for bridge for his tv... I'm testing this diff later today or tomorrow... -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: lynx: disable old protocols
On Sun, Jul 13, 2014 at 02:58:04AM -0500, Shawn K. Quinn wrote: | On Sun, 2014-07-13 at 01:38 -0600, Theo de Raadt wrote: | > With your attitude, I beg you to please go run some other | > operating system. | | The plan is when the first Bitrig release comes out, I'm done and switch | to that. The donations I was going to make to your project later this | year? Not anymore. They are either going to Bitrig, or maybe some even | to the FSF. Oh, the latter I would love to do especially since you keep | trashing Richard Stallman every chance you get, even after the FSF gave | you an award. (Did they ever ask for that award back? The FSF is run by | a lot of nice people. Maybe they are too nice to have asked for you to | return the award, but they should have. The lack of gratitude shown by | your ridicule of RMS after getting it is just plain atrocious and casts | a black eye on the "open source" movement you claim to be part of.) | | By the way, you would not have had BSD source code to hack on without | the efforts of RMS. Think about that next time before you insult him. | Show a little fucking gratitude for a change. And you show your gratitude for the free software that you use by telling the people that wrote it how to behave and making demands from them? Should OpenBSD keep lynx as it is because you and maybe a handful of others want it to stay that way? Some (extremely small) subset of users get to decide how things are? I believe the answer to the last question should be yes: but I don't think you are in that subset. The people maintaining OpenBSD get to maintain it. You get to use it. You choose to complain, they choose to ignore or ridicule you. | Until then, I'm going to keep a close eye on changes | under /usr/src/gnu/usr.bin/lynx and undo them on my own system if it | disables useful functionality. It's just outrageous I have to do this to | keep things like gopher support. Why is that outrageous?! Is it really outrageous that you get all the stuff you need to turn this into exactly what you want for free? Including, in this case, advance notification? Should Theo come to your house and do a little song and dance for you too? This is Open Source Software. You've stated it loud enough. | BTW, I still want to see an actual exploit. None of this "the code looks | shitty" vagueness. Look hard enough, you'll find code that looks shitty | everywhere. Why do you want to see an actual exploit? Do you want to see an actual exploit for changes that have gone into any other part of the tree? Ted (and others, I'm singling out Ted as he's become the personification of deleting stuff) has been deleting lots of arcane stuff from the tree; why are you not demanding things like fsplit are brought back, asking where exploits are? I know why not: you are not a fortran user. You don't use fsplit. You, and a few others, have stated you still use lynx with gopher and/or other protocols. Great: submit a port and use that. It's perfectly OK to actually participate in the development with submitting changes instead of getting all worked up when things don't happen the way you want them to. Things in OpenBSD have changed a lot since I started using it, and not always to my liking. I just deal with it. Why can't you? Why does anybody in OpenBSD owe you anything? Where does your sense of entitlement stem from? Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/