Re: Status of openbsd/macppc port?
Mark Cave-Ayland wrote: > On 17/08/18 13:55, Solene Rapenne wrote: > > > I'm using the macppc port since 6.1 to -current and apart failing > > harware I don't have any issue while playing Doom or rebuilind ports :) > > Hmmm. 6.1 is the latest version that I can boot to userspace, even if it > faults quickly after a few keypresses (QEMU is generally really strict > on invalid memory accesses which is basically what I see, but once the > access is tracked down it would be possible to fix it). > > I'd be interested to know if you are able to at least boot a 6.3 > installation CDROM on the Mac Mini to the installer without hanging, > which is probably the closest match to what I'm doing on real hardware. > > > ATB, > > Mark. This is interesting as I never used a CDROM for installation, I don't have a burner anymore and I'm not sure that the cdrom reader still work but boot from PXE.
Re: Status of openbsd/macppc port?
Mark Cave-Ayland wrote: > On 17/08/18 13:37, Solene Rapenne wrote: > > Mark Cave-Ayland wrote: > >> Hi all, > >> > >> I was just wondering what is the current state of the openbsd/macppc > >> port? As part of my recent work on qemu-system-ppc I now have a patch > >> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) > >> machine but I'm seeing quite a bit of instability in OpenBSD compared to > >> all my other test OSs. > > > Hello > > > > I can't help you much with your qemu issue but I can confirm you that > > the OpenBSD macppc port works really well as I use 2 macppc devices (an > > mac mini and a powerbook) often. The sad state is that less and less > > ports are running on them. > > Thanks for the response Solene. Can I ask which version of > openbsd/macppc you are currently running? > > > ATB, > > Mark. I'm using the macppc port since 6.1 to -current and apart failing harware I don't have any issue while playing Doom or rebuilind ports :)
Re: Status of openbsd/macppc port?
Mark Cave-Ayland wrote: > Hi all, > > I was just wondering what is the current state of the openbsd/macppc > port? As part of my recent work on qemu-system-ppc I now have a patch > that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) > machine but I'm seeing quite a bit of instability in OpenBSD compared to > all my other test OSs. > > For those that are interested I have included screenshots below: > > OpenBSD 6.3 > - Hangs just after USB detection > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.3.png > > OpenBSD 6.2 > - Panics just after USB detection > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.2.png > > OpenBSD 6.1 > - Boots all the way to the installer but causes qemu-system-ppc to > terminate fairly easily after pressing a few keys with "qemu: fatal: > ERROR: instruction should not need address translation" > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.1.png > > Note I also get a constant stream of messages on the console related to > OpenPIC: > > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > etc. > > > Obviously I can't categorically state that QEMU's emulation is perfect, > but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in > my local tests which makes me suspect that OpenBSD is trying to do > something different here. > > > ATB, > > Mark. Hello I can't help you much with your qemu issue but I can confirm you that the OpenBSD macppc port works really well as I use 2 macppc devices (an mac mini and a powerbook) often. The sad state is that less and less ports are running on them.
Re: iostat: add "sp" column for CP_SPIN
Naoki Fukaumi wrote:
> hi tech@,
>
> new cpu state, CP_SPIN, was added,
> https://marc.info/?l=openbsd-cvs=152630109526317=2
>
> but there is no column for it in the header of iostat,
>
> $ iostat
> tty sd0 cpu
> tin tout KB/t t/s MB/s us ni sy in id
>01 11.473 0.04 0 0 0 0 0100
>
> this patch adds "sp" for CP_SPIN.
>
> --
> FUKAUMI Naoki
>
> Index: usr.sbin/iostat/iostat.c
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> retrieving revision 1.40
> diff -u -p -u -p -r1.40 iostat.c
> --- usr.sbin/iostat/iostat.c 10 Feb 2018 19:49:50 - 1.40
> +++ usr.sbin/iostat/iostat.c 4 Sep 2018 04:19:14 -
> @@ -229,7 +229,7 @@ header(void)
> printf(" %16.16s ", cur.dk_name[i]);
>
> if (ISSET(todo, SHOW_CPU))
> - printf("cpu");
> + printf(" cpu");
> printf("\n");
>
> /* Sub-Headers. */
> @@ -254,7 +254,7 @@ header(void)
> printf(" KB xfr time ");
>
> if (ISSET(todo, SHOW_CPU))
> - printf(" us ni sy in id");
> + printf(" us ni sy sp in id");
> printf("\n");
> }
>
diff for iostat.8
not sure for the text though
is spinning time, time spent in locks?
The text could be "CPU time waiting for locks" maybe
Index: iostat.8
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
retrieving revision 1.26
diff -u -p -r1.26 iostat.8
--- iostat.817 Jan 2013 21:39:29 - 1.26
+++ iostat.85 Sep 2018 08:29:36 -
@@ -170,6 +170,8 @@ Seconds spent in disk activity
% of CPU time in user mode running niced processes
.It \
% of CPU time in system mode
+.It \
+% of CPU time spent spinning
.It \
% of CPU time processing interrupts
.It \
Re: iostat: add "sp" column for CP_SPIN
Solene Rapenne wrote:
> Naoki Fukaumi wrote:
> > hi tech@,
> >
> > new cpu state, CP_SPIN, was added,
> > https://marc.info/?l=openbsd-cvs=152630109526317=2
> >
> > but there is no column for it in the header of iostat,
> >
> > $ iostat
> > tty sd0 cpu
> > tin tout KB/t t/s MB/s us ni sy in id
> >01 11.473 0.04 0 0 0 0 0100
> >
> > this patch adds "sp" for CP_SPIN.
> >
> > --
> > FUKAUMI Naoki
> >
> > Index: usr.sbin/iostat/iostat.c
> > ===
> > RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> > retrieving revision 1.40
> > diff -u -p -u -p -r1.40 iostat.c
> > --- usr.sbin/iostat/iostat.c10 Feb 2018 19:49:50 - 1.40
> > +++ usr.sbin/iostat/iostat.c4 Sep 2018 04:19:14 -
> > @@ -229,7 +229,7 @@ header(void)
> > printf(" %16.16s ", cur.dk_name[i]);
> >
> > if (ISSET(todo, SHOW_CPU))
> > - printf("cpu");
> > + printf(" cpu");
> > printf("\n");
> >
> > /* Sub-Headers. */
> > @@ -254,7 +254,7 @@ header(void)
> > printf(" KB xfr time ");
> >
> > if (ISSET(todo, SHOW_CPU))
> > - printf(" us ni sy in id");
> > + printf(" us ni sy sp in id");
> > printf("\n");
> > }
> >
>
> diff for iostat.8
>
> not sure for the text though
> is spinning time, time spent in locks?
>
> The text could be "CPU time waiting for locks" maybe
>
> Index: iostat.8
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
> retrieving revision 1.26
> diff -u -p -r1.26 iostat.8
> --- iostat.817 Jan 2013 21:39:29 - 1.26
> +++ iostat.85 Sep 2018 08:29:36 -
> @@ -170,6 +170,8 @@ Seconds spent in disk activity
> % of CPU time in user mode running niced processes
> .It \
> % of CPU time in system mode
> +.It \
> +% of CPU time spent spinning
> .It \
> % of CPU time processing interrupts
> .It \
the right diff is this one
Index: iostat.8
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
retrieving revision 1.26
diff -u -p -r1.26 iostat.8
--- iostat.817 Jan 2013 21:39:29 - 1.26
+++ iostat.85 Sep 2018 08:29:36 -
@@ -170,6 +170,8 @@ Seconds spent in disk activity
% of CPU time in user mode running niced processes
.It \
% of CPU time in system mode
+.It \
+% of CPU time spent spinning
.It \
% of CPU time processing interrupts
.It \
Re: iostat: add "sp" column for CP_SPIN
Stuart Henderson wrote: > On 2018/09/04 14:22, Solene Rapenne wrote: > > About munin I'm trying to get a diff accepted upstream to fix cpu plugin and > > talk about this with kirby@. The cpu plugin uses sysctl kern.cp_time. While > > it's not related, I prefer to announce it here so people don't waste time > > fixing it again by looking at the thread :) > > Ah nice. When I worked on the initial munin port with mk I had intended > to try to get upstream to take the openbsd plugins separately (rather > than the current "copy similar OS and patch" approach), but I got fed up > with rrdtool performance on OpenBSD and stopped using munin before I got > round to it.. (and then I started using librenms and got fed up with > rrdtool performance once again ;) Using rrdcached the performances are really good. But that certainly depend on the number of systems. It may not scale well with more than 50 systems, this is also highly dependent on the number of plugins on each systems (as 1 value = 1 rrd file).
Re: iostat: add "sp" column for CP_SPIN
Stuart Henderson wrote:
> On 2018/09/04 12:07, Solene Rapenne wrote:
> > Naoki Fukaumi wrote:
> > > hi tech@,
> > >
> > > new cpu state, CP_SPIN, was added,
> > > https://marc.info/?l=openbsd-cvs=152630109526317=2
> > >
> > > but there is no column for it in the header of iostat,
> > >
> > > $ iostat
> > > tty sd0 cpu
> > > tin tout KB/t t/s MB/s us ni sy in id
> > >01 11.473 0.04 0 0 0 0 0100
> > >
> > > this patch adds "sp" for CP_SPIN.
> > >
> > > --
> > > FUKAUMI Naoki
> > >
> > > Index: usr.sbin/iostat/iostat.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> > > retrieving revision 1.40
> > > diff -u -p -u -p -r1.40 iostat.c
> > > --- usr.sbin/iostat/iostat.c 10 Feb 2018 19:49:50 - 1.40
> > > +++ usr.sbin/iostat/iostat.c 4 Sep 2018 04:19:14 -
> > > @@ -229,7 +229,7 @@ header(void)
> > > printf(" %16.16s ", cur.dk_name[i]);
> > >
> > > if (ISSET(todo, SHOW_CPU))
> > > - printf("cpu");
> > > + printf(" cpu");
> > > printf("\n");
> > >
> > > /* Sub-Headers. */
> > > @@ -254,7 +254,7 @@ header(void)
> > > printf(" KB xfr time ");
> > >
> > > if (ISSET(todo, SHOW_CPU))
> > > - printf(" us ni sy in id");
> > > + printf(" us ni sy sp in id");
> > > printf("\n");
> > > }
> > >
> >
> > ok solene@ for this, but the man page should be updated too, it contains the
> > list of columns displayed.
> >
>
> Is iostat(8) something where people are likely to parse output?
>
> (I first thought of sysutils/munin, iostat parsing is not enabled
> there, but there might be others).
About munin I'm trying to get a diff accepted upstream to fix cpu plugin and
talk about this with kirby@. The cpu plugin uses sysctl kern.cp_time. While
it's not related, I prefer to announce it here so people don't waste time
fixing it again by looking at the thread :)
Re: faq16: clarify ownership management
Klemens Nanni wrote: > "system" is ambigious, see `owner id` in vm.conf(5). > > OK? > > Index: faq16.html > === > RCS file: /cvs/www/faq/faq16.html,v > retrieving revision 1.2 > diff -u -p -r1.2 faq16.html > --- faq16.html25 Oct 2018 15:43:31 - 1.2 > +++ faq16.html30 Oct 2018 09:59:28 - > @@ -62,7 +62,7 @@ The following features are available: > >serial console access to the virtual machines >https://man.openbsd.org/tap;>tap(4) interfaces > - per-system user/group ownership > + per-VM user/group ownership >privilege separation >raw, qcow2 and qcow2-derived images >dumping and restoring of guest system memory seems fine to me. The original idea was to say it uses system user/group for VM ownership, but in fact the current wording doesn't make sense. ok solene@
/bin/df align inode output
the following diff makes df printing aligned inode informations.
before patch
solene@t480 /usr/src/bin/df $ df -ik
Filesystem 1K-blocks Used Avail Capacity iused ifree %iused
Mounted on
/dev/sd2a 102887813786283957414%2227 153675 1% /
/dev/sd2l 312080984 38691660 25778527613% 519480 19221190 3% /home
/dev/sd2d 4125390 7718 3911404 0% 113 545549 0% /tmp
/dev/sd2f 2061054786084 117191840% 14608 271214 5% /usr
/dev/sd2g 102887819105278638420%9211 146691 6%
/usr/X11R6
/dev/sd2h10318462 7347916 245462475% 171668 115351413%
/usr/local
/dev/sd2k 6189758150842 5729430 3%2469 803033 0%
/usr/obj
/dev/sd2j 2061054 111567884232457% 105820 18000237%
/usr/src
/dev/sd2e20124398 1498948 17619232 8% 14606 2557808 1% /var
/dev/sd2m 127381766 92115060 2889761876% 623330 15616668 4% /data
with patch
solene@t480 /usr/src/bin/df $ ./df -ik
Filesystem 1K-blocks Used Avail Capacity iusedifree %iused
Mounted on
/dev/sd2a 102887813786283957414% 2227 153675 1% /
/dev/sd2l 312080984 38691660 25778527613% 519480 19221190 3%
/home
/dev/sd2d 4125390 7718 3911404 0% 113 545549 0% /tmp
/dev/sd2f 2061054786084 117191840%14608 271214 5% /usr
/dev/sd2g 102887819105278638420% 9211 146691 6%
/usr/X11R6
/dev/sd2h10318462 7347916 245462475% 171668 115351413%
/usr/local
/dev/sd2k 6189758150842 5729430 3% 2469 803033 0%
/usr/obj
/dev/sd2j 2061054 111567884232457% 105820 18000237%
/usr/src
/dev/sd2e20124398 1498948 17619232 8%14606 2557808 1% /var
/dev/sd2m 127381766 92115060 2889761876% 623330 15616668 4%
/data
Index: df.c
===
RCS file: /cvs/src/bin/df/df.c,v
retrieving revision 1.59
diff -u -p -r1.59 df.c
--- df.c14 Aug 2016 21:07:40 - 1.59
+++ df.c25 Oct 2018 10:52:21 -
@@ -328,7 +328,7 @@ prtstat(struct statfs *sfsp, int maxwidt
if (iflag) {
inodes = sfsp->f_files;
used = inodes - sfsp->f_ffree;
- (void)printf(" %7llu %7llu %5.0f%% ", used, sfsp->f_ffree,
+ (void)printf(" %8llu %8llu %5.0f%% ", used, sfsp->f_ffree,
inodes == 0 ? 100.0 : (double)used / (double)inodes * 100.0);
} else
(void)printf(" ");
@@ -363,7 +363,7 @@ bsdprint(struct statfs *mntbuf, long mnt
maxwidth, maxwidth, "Filesystem", header);
}
if (iflag)
- (void)printf(" iused ifree %%iused");
+ (void)printf(" iusedifree %%iused");
(void)printf(" Mounted on\n");
Re: iostat: add "sp" column for CP_SPIN
Naoki Fukaumi wrote:
> hi tech@,
>
> new cpu state, CP_SPIN, was added,
> https://marc.info/?l=openbsd-cvs=152630109526317=2
>
> but there is no column for it in the header of iostat,
>
> $ iostat
> tty sd0 cpu
> tin tout KB/t t/s MB/s us ni sy in id
>01 11.473 0.04 0 0 0 0 0100
>
> this patch adds "sp" for CP_SPIN.
>
> --
> FUKAUMI Naoki
>
> Index: usr.sbin/iostat/iostat.c
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> retrieving revision 1.40
> diff -u -p -u -p -r1.40 iostat.c
> --- usr.sbin/iostat/iostat.c 10 Feb 2018 19:49:50 - 1.40
> +++ usr.sbin/iostat/iostat.c 4 Sep 2018 04:19:14 -
> @@ -229,7 +229,7 @@ header(void)
> printf(" %16.16s ", cur.dk_name[i]);
>
> if (ISSET(todo, SHOW_CPU))
> - printf("cpu");
> + printf(" cpu");
> printf("\n");
>
> /* Sub-Headers. */
> @@ -254,7 +254,7 @@ header(void)
> printf(" KB xfr time ");
>
> if (ISSET(todo, SHOW_CPU))
> - printf(" us ni sy in id");
> + printf(" us ni sy sp in id");
> printf("\n");
> }
>
ok solene@ for this, but the man page should be updated too, it contains the
list of columns displayed.
Re: make build as root fails when SUDO=doas
Marc Espie wrote:
> On Mon, Dec 10, 2018 at 01:33:49PM +0100, Solene Rapenne wrote:
> > hi
> >
> > I have SUDO=doas in /etc/mk.conf for ports, this is preventing a `make
> > build`
> > in /usr/src as root if /etc/doas.conf doesn't have a line "permit nopass
> > root
> > as root". This fails when using "doas" in regress/usr/bin/ssh/
> >
> > doas: Operation not permitted
> > *** Error 1 in regress/usr.bin/ssh (Makefile:212 'clean')
> > *** Error 1 in regress/usr.bin (:48 'cleandir')
> > *** Error 1 in regress (:48 'cleandir')
> > *** Error 1 in . (:48 'cleandir')
> > *** Error 1 in . (Makefile:86 'do-build')
> > *** Error 1 in /usr/src (Makefile:74 'build')
> >
> >
> > the issue comes from the 3rd line of that extract from Makefile:212
> >
> > clean: ${CLEAN_SUBDIR}
> > rm -f ${CLEANFILES}
> > test -z "${SUDO}" || ${SUDO} rm -f ${SUDO_CLEAN}
> > rm -rf .putty
> >
> > Not sure how to fix it. Maybe people shouldn't try to compile as root when
> > having SUDO=doas set and then, it's not an issue anymore?
>
> There are several possibilities:
> - add a test similar to the one in src/Makefile, e.g., not run
> sudo if you're root already (relatively complicated for no obvious benefit)
>
> - try to remove the files normally first
> rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f
> ${SUDO_CLEAN}
>
> this should actually fix the issue.
>
> Any other directory with that problem ?
that fix the issue and the build continues fine
Re: undocumented nfs mount option "intr"
Otto Moerbeek wrote: > On Thu, Dec 20, 2018 at 09:31:45AM +0100, Landry Breuil wrote: > > > On Thu, Dec 20, 2018 at 09:26:33AM +0100, Solene Rapenne wrote: > > > Hi > > > > > > fstab(5) has an example for a nfs mountpoint using the "intr" option. > > > > > > That option isn't documented in mount(8) or mount_nfs(8) and in fact, > > > I've not > > > been able to find it anywhere. What is it doing? > > > > I think it's the fstab shortcut for -i option in mount_nfs(8). > > > > Looking at mntopt mopts[] in mount_nfs.c there are way more nfs specifc > options that are only documented as getopt flags and not as -o flags. > > -Otto would it be accepted to add the "named options" in mount_nfs(8), something like this diff? this is a quick draft Index: mount_nfs.8 === RCS file: /data/cvs/src/sbin/mount_nfs/mount_nfs.8,v retrieving revision 1.39 diff -u -p -r1.39 mount_nfs.8 --- mount_nfs.8 6 Jun 2009 20:58:50 - 1.39 +++ mount_nfs.8 21 Dec 2018 17:24:53 - @@ -163,6 +163,9 @@ Cache file attributes for at least .Ar num seconds. The default is 5 seconds. +.It Cm intr +This option is equivalent as using the flag +.Fl i . .It Cm port Ns = Ns Ar portnumber Use the specified port number for NFS requests. The default is to query the portmapper for the NFS port.
undocumented nfs mount option "intr"
Hi fstab(5) has an example for a nfs mountpoint using the "intr" option. That option isn't documented in mount(8) or mount_nfs(8) and in fact, I've not been able to find it anywhere. What is it doing?
[patch] sh.1 getopts inaccurate
hi
I'm not familiar with getopts, first time I use it and the man page was
confusing. It says "a colon following an option indicates it may take an
argument".
I understand this as: if I use the string "s:" then I can use "-s" or "-s
something" as it **may** take an argument.
But if you use "s:", getopts reports an error "-s requires argument".
I propose to modify that sentence (not sure for the s in requires).
Index: sh.1
===
RCS file: /data/cvs/src/bin/ksh/sh.1,v
retrieving revision 1.149
diff -u -p -r1.149 sh.1
--- sh.128 Sep 2018 18:32:39 - 1.149
+++ sh.129 Nov 2018 06:44:50 -
@@ -495,7 +495,7 @@ to the index of the next variable to be
The string
.Ar optstring
contains a list of acceptable options;
-a colon following an option indicates it may take an argument.
+a colon following an option indicates it requires an argument.
If an option not recognised by
.Ar optstring
is found,
Example to reproduce it:
#!/bin/sh
while getopts s:? args
do
case "$args" in
s) VALUE=${OPTARG} ;;
*) exit 0 ;;
esac
done
echo $VALUE
solene@t480 ~/notes/perso $ ./bug.sh -s
./bug.sh[9]: -`s' requires argument
solene@t480 ~/notes/perso $ ./bug.sh -s value
value
make build as root fails when SUDO=doas
hi
I have SUDO=doas in /etc/mk.conf for ports, this is preventing a `make build`
in /usr/src as root if /etc/doas.conf doesn't have a line "permit nopass root
as root". This fails when using "doas" in regress/usr/bin/ssh/
doas: Operation not permitted
*** Error 1 in regress/usr.bin/ssh (Makefile:212 'clean')
*** Error 1 in regress/usr.bin (:48 'cleandir')
*** Error 1 in regress (:48 'cleandir')
*** Error 1 in . (:48 'cleandir')
*** Error 1 in . (Makefile:86 'do-build')
*** Error 1 in /usr/src (Makefile:74 'build')
the issue comes from the 3rd line of that extract from Makefile:212
clean: ${CLEAN_SUBDIR}
rm -f ${CLEANFILES}
test -z "${SUDO}" || ${SUDO} rm -f ${SUDO_CLEAN}
rm -rf .putty
Not sure how to fix it. Maybe people shouldn't try to compile as root when
having SUDO=doas set and then, it's not an issue anymore?
add explanations of vmctl send command in vmctl.8
This diff explains a little more about the send commands. send pauses the VM and send its memory + the start parameters. It's not obvious when you don't know vmctl. Index: vmctl.8 === RCS file: /cvs/src/usr.sbin/vmctl/vmctl.8,v retrieving revision 1.47 diff -u -p -r1.47 vmctl.8 --- vmctl.8 11 Sep 2018 04:03:16 - 1.47 +++ vmctl.8 19 Sep 2018 08:14:11 - @@ -89,7 +89,9 @@ Reset and terminate all VMs. .It Cm send Ar id Send a VM with the specified .Ar id -to standard output and terminate it. +to standard output and terminate it. The VM is paused while sending. +Data sent to standard output contains the VM parameters and its memory, +it does not contain the disk image. .It Cm show Op Ar id An alias for the .Cm status This diff adds an explanation about moving a VM from one host to another. Not sure if it should be in the man page. Index: vmctl.8 === RCS file: /cvs/src/usr.sbin/vmctl/vmctl.8,v retrieving revision 1.47 diff -u -p -r1.47 vmctl.8 --- vmctl.8 11 Sep 2018 04:03:16 - 1.47 +++ vmctl.8 19 Sep 2018 08:17:16 - @@ -89,7 +89,12 @@ Reset and terminate all VMs. .It Cm send Ar id Send a VM with the specified .Ar id -to standard output and terminate it. +to standard output and terminate it. The VM is paused while sending. +Data sent to standard output contains the VM parameters and its memory, +it does not contain the disk image. +.Pp +In order to move a VM from one host to another, disk files must be +synced between the send and the receive processes and must have the same path. .It Cm show Op Ar id An alias for the .Cm status
Re: add explanations of vmctl send command in vmctl.8
Solene Rapenne wrote: > This diff explains a little more about the send commands. > send pauses the VM and send its memory + the start parameters. > new diff with some changes, also thx bentley@ for telling me sentences should start on a newline in mdoc. Index: vmctl.8 === RCS file: /cvs/src/usr.sbin/vmctl/vmctl.8,v retrieving revision 1.47 diff -u -p -r1.47 vmctl.8 --- vmctl.8 11 Sep 2018 04:03:16 - 1.47 +++ vmctl.8 19 Sep 2018 10:20:06 - @@ -90,6 +90,13 @@ Reset and terminate all VMs. Send a VM with the specified .Ar id to standard output and terminate it. +The VM is paused while send is processing. +Data sent to standard output contains the VM parameters and its memory, +not the disk image. +.Pp +In order to move a VM from one host to another, disk files must be +synced between the send and the receive processes and must be located +under the same path. .It Cm show Op Ar id An alias for the .Cm status
Re: dynamic RTS threshold in 11n mode
On Tue, Feb 26, 2019 at 03:33:23PM +0100, Stefan Sperling wrote:
> On Tue, Feb 26, 2019 at 03:04:35PM +0100, Stefan Sperling wrote:
> > This diff makes the RTS threshold dynamic in 11n mode.
> > I am looking for tests with iwn(4), iwm(4), and athn(4) drivers.
> >
> > When there's a lot of competition for air time, RTS can do more harm than
> > good because we end up causing more RTS/CTS frames on the air than actual
> > data frames. So a fixed RTS threshold really doesn't make a lot of sense.
> >
> > This diff implements a heuristic for setting this threshold, based on
> > section
> > 5.2 of the MiRa paper. It should improve Tx throughput on busy channels
> > which
> > are especially common in the 2GHz band. In my testing it helps quite a bit.
> >
> > This diff won't change the situation in 11a/b/g modes, and it might
> > not make a difference if there are 11a/b/g networks in range.
>
> I realized the previous diff might take some time to raise throughput,
> so please try this one instead. The difference is just that the previous
> diff starts out with RTS threshold enabled, while this one starts out with
> RTS threshold disabled. This should make results look better for people
> doing quick tests rather than looking at long-term effects. :-)
>
> diff f727f040295e17987bfffe9c9952e45fd6ad7859 /usr/src
> blob - 7cf96bf074b3eef4d9fbb85c9253bac7e5550fd7
> file + sys/dev/ic/ar5008.c
> --- sys/dev/ic/ar5008.c
> +++ sys/dev/ic/ar5008.c
> @@ -1514,11 +1514,16 @@ ar5008_tx(struct athn_softc *sc, struct mbuf *m, struc
> if (!IEEE80211_IS_MULTICAST(wh->i_addr1) &&
> (wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK) ==
> IEEE80211_FC0_TYPE_DATA) {
> + int rtsthres = ic->ic_rtsthreshold;
> enum ieee80211_htprot htprot;
> -
> +
> + if (ni->ni_flags & IEEE80211_NODE_HT)
> + rtsthres = ieee80211_mira_get_rts_threshold(>mn,
> + ic, ni, totlen);
> htprot = (ic->ic_bss->ni_htop1 & IEEE80211_HTOP1_PROT_MASK);
> +
> /* NB: Group frames are sent using CCK in 802.11b/g. */
> - if (totlen > ic->ic_rtsthreshold) {
> + if (totlen > rtsthres) {
> ds->ds_ctl0 |= AR_TXC0_RTS_ENABLE;
> } else if (((ic->ic_flags & IEEE80211_F_USEPROT) &&
> athn_rates[ridx[0]].phy == IEEE80211_T_OFDM) ||
> blob - 7d7f0697a2b609f4a6e0fab09ede9a480baa7bd3
> file + sys/dev/pci/if_iwm.c
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -4216,7 +4216,7 @@ iwm_tx(struct iwm_softc *sc, struct mbuf *m, struct ie
> bus_dma_segment_t *seg;
> uint8_t tid, type;
> int i, totlen, err, pad;
> - int hdrlen2;
> + int hdrlen2, rtsthres = ic->ic_rtsthreshold;
>
> wh = mtod(m, struct ieee80211_frame *);
> hdrlen = ieee80211_get_hdrlen(wh);
> @@ -4292,9 +4292,13 @@ iwm_tx(struct iwm_softc *sc, struct mbuf *m, struct ie
> flags |= IWM_TX_CMD_FLG_ACK;
> }
>
> + if (ni->ni_flags & IEEE80211_NODE_HT)
> + rtsthres = ieee80211_mira_get_rts_threshold(>in_mn, ic, ni,
> + totlen + IEEE80211_CRC_LEN);
> +
> if (type == IEEE80211_FC0_TYPE_DATA &&
> !IEEE80211_IS_MULTICAST(wh->i_addr1) &&
> - (totlen + IEEE80211_CRC_LEN > ic->ic_rtsthreshold ||
> + (totlen + IEEE80211_CRC_LEN > rtsthres ||
> (ic->ic_flags & IEEE80211_F_USEPROT)))
> flags |= IWM_TX_CMD_FLG_PROT_REQUIRE;
>
> blob - 1dab60807c0709735799436e7a4a8e2d8d9f1ff9
> file + sys/dev/pci/if_iwn.c
> --- sys/dev/pci/if_iwn.c
> +++ sys/dev/pci/if_iwn.c
> @@ -3069,8 +3069,13 @@ iwn_tx(struct iwn_softc *sc, struct mbuf *m, struct ie
>
> /* Check if frame must be protected using RTS/CTS or CTS-to-self. */
> if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) {
> + int rtsthres = ic->ic_rtsthreshold;
> + if (ni->ni_flags & IEEE80211_NODE_HT)
> + rtsthres = ieee80211_mira_get_rts_threshold(>mn,
> + ic, ni, totlen + IEEE80211_CRC_LEN);
> +
> /* NB: Group frames are sent using CCK in 802.11b/g/n (2GHz). */
> - if (totlen + IEEE80211_CRC_LEN > ic->ic_rtsthreshold) {
> + if (totlen + IEEE80211_CRC_LEN > rtsthres) {
> flags |= IWN_TX_NEED_RTS;
> } else if ((ic->ic_flags & IEEE80211_F_USEPROT) &&
> ridx >= IWN_RIDX_OFDM6) {
> blob - 4edd26a5fde82a9d9ddfd31e0bd075c0f59d2143
> file + sys/net80211/ieee80211_mira.c
> --- sys/net80211/ieee80211_mira.c
> +++ sys/net80211/ieee80211_mira.c
> @@ -85,6 +85,9 @@ int ieee80211_mira_valid_tx_mcs(struct ieee80211com *,
> uint32_t ieee80211_mira_valid_rates(struct ieee80211com *,
> struct ieee80211_node *);
> uint32_t ieee80211_mira_mcs_below(struct ieee80211_mira_node *, int, int);
> +void ieee80211_mira_set_rts_threshold(struct ieee80211_mira_node *,
> +
Re: rework iwm(4) Tx rate selection
On Wed, Feb 20, 2019 at 04:04:13PM +0100, Stefan Sperling wrote:
> iwm(4) has been using a firmware-based approach to retrying failed
> Tx attempts with successively lower data rates. This is suboptimal
> for our kernel's Tx rate selection algorithms, which are called
> MiRA (for 11n) and AMRR (for 11a/b/g).
>
> I have observed a mismatch between the Tx rate reported by ifconfig iwm0
> and the Rx rate reported at the receiving end, and this diff fixes
> that issue for me.
>
> Because iwm firmware retries on lower rates, our own rate selection
> is fooled into believing that high rates succeed when they in fact
> don't succeed. This causes more Tx retries than necessary, which
> results in lower throughput than we could achieve otherwise.
>
> With the diff below we instead ask the firmware to always keep retrying
> at a constant Tx rate. This provides more accurate feedback to MiRa and
> AMRR, which are then able to select an initial Tx rate which is more
> likely to succeed.
>
> However, there is another reason why we were using firmware-based retries.
> In 11n mode, net80211 only knows about rates which are based on OFDM.
> On 2GHz channels, the older CCK modulation provides a larger range and can
> thus make the difference between a bad network connection and no network
> connection at all. We were relying on the firmware to retry with CCK if
> OFDM frames failed so I had to implement a similar strategy in the driver.
> This is achived by falling back to CCK rates and running AMRR instead of
> MiRA if the lowest OFDM rate is failing, until AMRR decides to start using
> OFDM again, and then switch back to OFDM + MiRA. Getting the driver to switch
> back to OFDM once it is using CCK wasn't straightforward. I eventually found
> out that feeding only actual Tx failures to AMRR makes this work well.
>
> I had to remove 11n support from AMRR which interfered with this fallback.
> This is overdue anyway since all drivers are using MiRa in 11n mode now.
>
> When testing this, please compare throughput before and after this diff.
> I run tcpbench -s on a host behind the AP and start a tcpbench client on
> my iwm laptop. With this diff, and an 11ac AP on channel 149, tcpbench
> measures up to 26 Mpbs in my environment, with an average rate above 20 Mbps.
>
> Also pay attention to changes in latency. To test this, on my iwm laptop
> I run ping and rain(6) through an SSH connection to a machine behind the AP.
>
> Tested on a 7265 device only so far.
>
> iwn(4) has the same problem and should also be fixed once this change
> has made it into the tree.
>
> diff 3cfc9cae129c023be655a6d31902cddd094fdec4 /usr/src
> blob - 45e4446d79d2da0f847170e34b9a01e25b71ea62
> file + sys/dev/pci/if_iwm.c
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -217,6 +217,7 @@ const struct iwm_rate {
> #define IWM_RIDX_MAX (nitems(iwm_rates)-1)
> #define IWM_RIDX_IS_CCK(_i_) ((_i_) < IWM_RIDX_OFDM)
> #define IWM_RIDX_IS_OFDM(_i_) ((_i_) >= IWM_RIDX_OFDM)
> +#define IWM_RVAL_IS_OFDM(_i_) ((_i_) >= 12 && (_i_) != 22)
>
> /* Convert an MCS index into an iwm_rates[] index. */
> const int iwm_mcs2ridx[] = {
> @@ -368,6 +369,7 @@ void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct
> iwm_
> int iwm_get_noise(const struct iwm_statistics_rx_non_phy *);
> void iwm_rx_rx_mpdu(struct iwm_softc *, struct iwm_rx_packet *,
> struct iwm_rx_data *);
> +void iwm_enable_ht_cck_fallback(struct iwm_softc *, struct iwm_node *);
> void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *,
> struct iwm_node *);
> void iwm_rx_tx_cmd(struct iwm_softc *, struct iwm_rx_packet *,
> @@ -447,7 +449,6 @@ int iwm_run(struct iwm_softc *);
> int iwm_run_stop(struct iwm_softc *);
> struct ieee80211_node *iwm_node_alloc(struct ieee80211com *);
> void iwm_calib_timeout(void *);
> -void iwm_setrates(struct iwm_node *);
> int iwm_media_change(struct ifnet *);
> void iwm_newstate_task(void *);
> int iwm_newstate(struct ieee80211com *, enum ieee80211_state, int);
> @@ -3574,6 +3575,37 @@ iwm_rx_rx_mpdu(struct iwm_softc *sc, struct iwm_rx_pac
> }
>
> void
> +iwm_enable_ht_cck_fallback(struct iwm_softc *sc, struct iwm_node *in)
> +{
> + struct ieee80211com *ic = >sc_ic;
> + struct ieee80211_node *ni = >in_ni;
> + struct ieee80211_rateset *rs = >ni_rates;
> + uint8_t rval = (rs->rs_rates[ni->ni_txrate] & IEEE80211_RATE_VAL);
> + uint8_t min_rval = ieee80211_min_basic_rate(ic);
> + int i;
> +
> + /* Are CCK frames forbidden in our BSS? */
> + if (IWM_RVAL_IS_OFDM(min_rval))
> + return;
> +
> + in->ht_force_cck = 1;
> +
> + ieee80211_mira_cancel_timeouts(>in_mn);
> + ieee80211_mira_node_init(>in_mn);
> + ieee80211_amrr_node_init(>sc_amrr, >in_amn);
> +
> + /* Choose initial CCK Tx rate. */
> + ni->ni_txrate = 0;
> + for (i = 0; i < rs->rs_nrates; i++) {
> + rval = (rs->rs_rates[i] & IEEE80211_RATE_VAL);
> +
Re: CRYPTO CONTAINER
On Mon, Feb 11, 2019 at 12:39:52PM +0100, Oleg Pahl wrote: > Hi All, > > Linux has one tool CRYPTSETUP. > > With this tool I can prepare one container, then open it put > some private data and close. > > I know that our OpenBSD is also Crypto Paranoid OS. > > Any idea how can I do the same procedure using OBSD default tools? > > What is recommended work flow for it (to secure file/data) ? > > P.S. I have full encrypted hard disk. But its not enough for me. > > Many thx for strong support. > > BR, > > deface > > Hi You want to make a raw file using dd if=/dev/random of=container then use vnconfig to make a disk device from that file, and then use bioctl on it to create a CRYPTO raid. You will need to be root to mount and umount it.
Re: [PATCH] [www] cvsync.html - use class="cmdbox"
On Wed, Apr 17, 2019 at 09:55:26PM +0100, Raf Czlonka wrote: > Hi all, > > Similar to other pages[0][1], use class="cmdbox", add prompt character > where appropriate, and remove superfluous indentation while there. > > [0] https://www.openbsd.org/anoncvs.html > [1] https://www.openbsd.org/ddb.html > > Regards, > > Raf this looks much better with this ok solene@
Re: [PATCH] [www] cvsync.html - use class="cmdbox"
On Thu, Apr 18, 2019 at 07:31:45AM +0200, Theo Buehler wrote: > On Wed, Apr 17, 2019 at 11:41:18PM +0100, Raf Czlonka wrote: > > On Wed, Apr 17, 2019 at 10:53:54PM BST, Theo Buehler wrote: > > > On Wed, Apr 17, 2019 at 11:34:56PM +0200, Solene Rapenne wrote: > > > > On Wed, Apr 17, 2019 at 09:55:26PM +0100, Raf Czlonka wrote: > > > > > Hi all, > > > > > > > > > > Similar to other pages[0][1], use class="cmdbox", add prompt character > > > > > where appropriate, and remove superfluous indentation while there. > > > > > > > > > > [0] https://www.openbsd.org/anoncvs.html > > > > > [1] https://www.openbsd.org/ddb.html > > > > > > > > > > Regards, > > > > > > > > > > Raf > > > > > > > > this looks much better with this > > > > > > > > ok solene@ > > > > > > > > > > Please send a diff for www/build/mirrors/cvsync.html.* instead > > > > After cvsync.html -> build/mirrors/cvsync.html.head change, the patch > > applies just fine but, as requested, re-done for the > > build/mirrors/cvsync.html.head below anyway. > > Looks good. > > ok tb > > Solene, can you take care of committing this? > > > done!
Re: scheduler small changes
On Wed, May 15, 2019 at 09:05:32AM -0500, Amit Kulkarni wrote: > Hi, > > This effort is heavily based on top of Gregor's and Michal's diffs. Tried to > incorporate feedback given by different people to them in 2011/2016. Split > the new code in a ifdef, so people can do a straight comparison, tried very > hard not to delete existing code, just shifted it around. Main motivation was > to find if it is possible to do incremental improvements in scheduler. After > sometime, have still not understood completely the load avg part, > p_priority/p_usrpri calculations, the cpuset code. Looked heavily at > Dragonfly (simpler than FreeBSD) and FreeBSD code. As a newcomer, OpenBSD > code is way easier to read. Thanks for the detailed explanations given to > Michal and also in later diffs posted to tech@, they helped a lot when trying > to understand the decisions made by other devs, the commit messages help a > little but the explanations help a lot more. This invites discussions and end > users learn a lot more in the process. > > This diff survived multiple tens of kernel builds, a bsd.sp build, bsd.rd > build, a bsd.mp without these changes, userland/xenocara, a make regress a > few days ago all on 3 desktops on amd64. Ran under all possible scenarios > listed in previous sentence. No major invasive changes attempted, all tools > should work as is, if its broken, please let me know. This is faster than > current, but not sure by how much, placebo effect in play. > > I think there is a bug in resched_proc() which is fixed in mi_switch(), a > quick enhancement in cpu_switchto(), p_slptime, and precise round robin > interval for each proc unless preempted or it yields(). > > Tried to fiddle with different time slices other than hz/10, not sure if it > will work on other arches, but tried to stay within MI code, so it should > work. Other than counting no idea to verify a proc is actually switched away > after its rr interval is over. Just went by what is there in the existing > code. Tried giving higher slice like 200 ms, but didn't want to exceed the > rucheck() in kern_resource 1 sec limit. > > Tried to do rudimentary work on affinity without having a affinity field in > struct proc or struct schedstate_percpu (like Dragonfly/FreeBSD does). > Observed the unbalance in runqs. Affinity works most of the time under light > load. There's a problem when I try to comment out sched_steal_proc(), in > kern_sched, that is the problem with this iteration of the diff. > > Not sure if the reduction from 32 queues to a single TAILQ would be accepted, > but tried it anyway, it is definitely faster. This code tries to reduce the > complexity in deciding which queue to place the proc on. There is no current > support for a real-time queue or other types of scheduling classes, so IMHO > this is a simplification. > > Tried to give detailed explanation of thinking. Sent the complete diff, but > will split diff, if parts of it are found to be valid. > > In any case, a request to please accept a small change in top, to display > p_priority directly. > > Thanks > > Hi, I tried your diff. It makes game games/gzdoom unplayable because of too much stuttering. I did not feel any change apart for this case on my intel i7 8550-U.
Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority
On Sat, Jun 01, 2019 at 06:55:20PM -0300, Martin Pieuchot wrote: > Diff below exists mainly for documentation and test purposes. If > you're not interested about how to break the scheduler internals in > pieces, don't read further and go straight to testing! I'm running it since a few hours. - games/gzdoom feels smoother with this patch (stuttering was certainly related to audio) - mpd playback doesn't seem interrupted under heavy load as it occasionnaly did this may be coincidences or placebo effect.
Re: [PATCH] [www] faq/pf/pools.html - simplify loadbalancing section
On Mon, May 06, 2019 at 10:47:39PM +0200, Thomas Huber wrote: > Hi tech@, > > after struggeling a while to setup a load-balancer, I´ve finaly managed it. > At least not as I originally had in mind but it works. > > During this kind of learning process I read the faq quite often and over > again. > Now, after I dived into the rabit-hole of pf I think the /faq/pf/pools.html > site is little outdated and leads in the wrong directions when getting > started. > > My attached diff basically simplifies (from my point of view) the sections > for > loadbalancing outgoing traffic. I make havy use of interface modifiers - > which > are awesome btw - in the examples and removed some unnecessary rules in the > pf.conf example at the bottom. For me it gets more clear to read an example > with > this modifiers than an random IP adress or named macros. > Also I removed the special treatment of https connections. I´ld say that the > majority of http connections are https and the there are less "broken" > webapps > out there that utilize the IP for a login-session. Actually I didn´t came > across > this problems in the wild. But I put a hint how to handle it a the bottom > (stolen from the NAT section) but I would give this a priority anymore. > > And and I added the 'least-state' method to introduction. > > And it my first diff and my first contribution... hope its technicaly done > right > The diff is created wit git from the repo hosted on github.com: > > diff --git faq/pf/pools.html faq/pf/pools.html [...] > > -lan_net = "192.168.0.0/24" > -int_if = "dc0" > -ext_if1 = "fxp0" > -ext_if2 = "fxp1" > -ext_gw1 = "198.51.100.100" > -ext_gw2 = "203.0.113.200" > - > -# nat outgoing connections on each internet interface > -match out on $ext_if1 from $lan_net nat-to ($ext_if1) > -match out on $ext_if2 from $lan_net nat-to ($ext_if2) > +match out on pppoe0 from em0:network nat-to (pppoe0:0) > +match out on em2 from em0:network nat-to (em2:0) Hi I have no opinion about the technical changes, but you must keep the macros instead of adding your interface names and addresses everywhere in the examples instead of using the macros.
Re: tmux: cannot select pane after prefix-b q
On Tue, May 07, 2019 at 11:55:51AM +0100, Nicholas Marriott wrote:
> Hi
>
> You have the right idea general idea of the problem. display-panes
> blocks the queue until it is finished, so the key press isn't processed
> until then, which is too late.
>
> But your change defeats the purpose, the idea is that new key presses
> should be queued after the commands inserted by previous key presses,
> not before them.
>
> Identify mode (display-panes) can just be treated specially I think.
>
> Please try the diff below.
>
> Thanks!
>
>
> Index: server-client.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/server-client.c,v
> retrieving revision 1.279
> diff -u -p -r1.279 server-client.c
> --- server-client.c 3 May 2019 20:44:24 - 1.279
> +++ server-client.c 7 May 2019 10:50:07 -
> @@ -986,7 +986,7 @@ server_client_assume_paste(struct sessio
> * Handle data key input from client. This owns and can modify the key event
> it
> * is given and is responsible for freeing it.
> */
> -enum cmd_retval
> +static enum cmd_retval
> server_client_key_callback(struct cmdq_item *item, void *data)
> {
> struct client *c = item->client;
> @@ -1204,6 +1204,44 @@ forward_key:
> out:
> free(event);
> return (CMD_RETURN_NORMAL);
> +}
> +
> +/* Handle a key event. */
> +int
> +server_client_handle_key(struct client *c, struct key_event *event)
> +{
> + struct session *s = c->session;
> + struct window *w;
> + struct window_pane *wp = NULL;
> + struct cmdq_item*item;
> +
> + /* Check the client is good to accept input. */
> + if (s == NULL || (c->flags & (CLIENT_DEAD|CLIENT_SUSPENDED)) != 0)
> + return (0);
> + w = s->curw->window;
> +
> + /*
> + * Key presses in identify mode are a special case. The queue might be
> + * blocked so they need to processed immediately rather than queued.
> + */
> + if (c->flags & CLIENT_IDENTIFY) {
> + if (c->flags & CLIENT_READONLY)
> + return (0);
> + if (event->key >= '0' && event->key <= '9') {
> + window_unzoom(w);
> + wp = window_pane_at_index(w, event->key - '0');
> + }
> + server_client_clear_identify(c, wp);
> + return (0);
> + }
> +
> + /*
> + * Add the key to the queue so it happens after any commands queued by
> + * previous keys.
> + */
> + item = cmdq_get_callback(server_client_key_callback, event);
> + cmdq_append(c, item);
> + return (1);
> }
>
> /* Client functions that need to happen every loop. */
> Index: tmux.h
> ===
> RCS file: /cvs/src/usr.bin/tmux/tmux.h,v
> retrieving revision 1.888
> diff -u -p -r1.888 tmux.h
> --- tmux.h7 May 2019 10:25:15 - 1.888
> +++ tmux.h7 May 2019 10:50:09 -
> @@ -2012,7 +2012,7 @@ void server_client_set_identify(struct
> void server_client_set_key_table(struct client *, const char *);
> const char *server_client_get_key_table(struct client *);
> int server_client_check_nested(struct client *);
> -enum cmd_retval server_client_key_callback(struct cmdq_item *, void *);
> +int server_client_handle_key(struct client *, struct key_event *);
> struct client *server_client_create(int);
> int server_client_open(struct client *, char **);
> void server_client_unref(struct client *);
> Index: tty-keys.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/tty-keys.c,v
> retrieving revision 1.112
> diff -u -p -r1.112 tty-keys.c
> --- tty-keys.c3 May 2019 18:00:19 - 1.112
> +++ tty-keys.c7 May 2019 10:50:09 -
> @@ -573,7 +573,6 @@ tty_keys_next(struct tty *tty)
> cc_t bspace;
> int delay, expired = 0, n;
> key_code key;
> - struct cmdq_item*item;
> struct mouse_event m = { 0 };
> struct key_event*event;
>
> @@ -732,9 +731,8 @@ complete_key:
> event = xmalloc(sizeof *event);
> event->key = key;
> memcpy(>m, , sizeof event->m);
> -
> - item = cmdq_get_callback(server_client_key_callback, event);
> - cmdq_append(c, item);
> + if (!server_client_handle_key(c, event))
> + free(event);
> }
>
> return (1);
Works for me!
ok solene@
Re: httpd: avoid opening log files on "no log"
On Thu, May 02, 2019 at 10:36:29PM +0200, Klemens Nanni wrote:
> httpd(8) still creates/opens log files with `no log' in httpd.conf(5):
>
> [no] log [option]
> Set the specified logging options. Logging is enabled by default
> using the standard access and error log files, but can be changed
> per server or location. Use the no log directive to disable
> logging of any requests. Multiple options may be specified
> within curly braces. Valid options are:
>
> I want to quickly serve files with nothing but a config file:
>
> # cat /etc/httpd.conf
> chroot "/foo"
> server "default" {
> listen on "*" port www
> no log
> root "/"
> }
> # httpd -d
> doas (k...@eru.my.domain) password:
> startup
> failed to open /foo/logs/access.log: No such file or directory
> parent: failed to open log file
> logger exiting, pid 1150
> server exiting, pid 42968
> server exiting, pid 51707
>
> Diff below fixes this.
>
> Feedback? OK?
works for me on amd64
a big YES for this!!
it doesn't even require man page change.
Re: sync acme-client.conf.5 with the example about LE API url
On Thu, Jul 04, 2019 at 10:52:50PM +0200, Sebastian Benoit wrote: > Solene Rapenne(sol...@perso.pw) on 2019.07.04 06:56:44 +0200: > > The example uses acme-v02.api.letsencrypt.org while acme-client.conf(5) > > still uses v01. > > ups. > > ok benno@ > thanks! I reply in thread because I receive okays but it's committed :)
anoncvs.html: tell reader to use -d if updating first time from tgz
Hi in anoncvs.html, if the user choose to use tgz sources instead of a checkout, the update examples won't work because no cvs server will be set without passing -d parameter to the cvs command. Not sure about the wording, if a good english speaker can word it better, go on :) Index: build/mirrors/anoncvs.html.head === RCS file: /data/cvs/www/build/mirrors/anoncvs.html.head,v retrieving revision 1.77 diff -u -p -r1.77 anoncvs.html.head --- build/mirrors/anoncvs.html.head 27 May 2019 22:55:27 - 1.77 +++ build/mirrors/anoncvs.html.head 28 Jun 2019 11:16:24 - @@ -109,7 +109,8 @@ For more information on the flavors of O Choose the Anonymous CVS server you are going to use from the list of servers below, then you can start using cvs. If you begin with src.tar.gz and sys.tar.gz as mentioned -above, you can skip the initial checkout and proceed to updating. +above, you can skip the initial checkout and proceed to updating, if you do +so, the first time you update you must specify a cvs server as in the checkout example. Warning:
Re: anoncvs.html: tell reader to use -d if updating first time from tgz
On Fri, Jun 28, 2019 at 01:19:30PM +0200, Solene Rapenne wrote: > Hi > > in anoncvs.html, if the user choose to use tgz sources instead of a > checkout, the update examples won't work because no cvs server will be > set without passing -d parameter to the cvs command. > > Not sure about the wording, if a good english speaker can word it > better, go on :) > > Index: build/mirrors/anoncvs.html.head > === > RCS file: /data/cvs/www/build/mirrors/anoncvs.html.head,v > retrieving revision 1.77 > diff -u -p -r1.77 anoncvs.html.head > --- build/mirrors/anoncvs.html.head 27 May 2019 22:55:27 - 1.77 > +++ build/mirrors/anoncvs.html.head 28 Jun 2019 11:16:24 - > @@ -109,7 +109,8 @@ For more information on the flavors of O > Choose the Anonymous CVS server you are going to use from the > list of servers below, then you can start using cvs. > If you begin with src.tar.gz and sys.tar.gz as > mentioned > -above, you can skip the initial checkout and proceed to updating. > +above, you can skip the initial checkout and proceed to updating, > if you do > +so, the first time you update you must specify a cvs server as in the > checkout example. > > > Warning: > nand1 from irc told me it's already written later in the page. If you are updating a source tree that you initially fetched from a different server, or from a tar file, you must add the -d [cvsroot] option to cvs. not sure if this could be moved under "Updating an existin tree", this would make more sense to tell this before people need it
add caveats section in newfs about endianess
This diff had a section about endianess of newfs. This is not written anywhere that ffs is dependent of endianess. Related bug report https://marc.info/?l=openbsd-bugs=150242795204995=2 Index: newfs.8 === RCS file: /data/cvs/src/sbin/newfs/newfs.8,v retrieving revision 1.75 diff -u -p -r1.75 newfs.8 --- newfs.8 23 Apr 2019 18:13:11 - 1.75 +++ newfs.8 19 Aug 2019 15:49:15 - @@ -345,3 +345,8 @@ The .Nm command appeared in .Bx 4.2 . +.Sh CAVEATS +The created filesystem can only be mounted on systems running architectures +of the same endianess as the one on which +.Nm +has been used.
Re: add caveats section in newfs about endianess
> Or, you could explain this more as an attribute of the filesystem: > > FFS filesystems are byte-order dependent, and thus not portable to > systems with a different endianness. > > (two n in endianness) > > what about this text in mount_ffs(8) where it makes more sense? Index: mount_ffs.8 === RCS file: /data/cvs/src/sbin/mount_ffs/mount_ffs.8,v retrieving revision 1.18 diff -u -p -r1.18 mount_ffs.8 --- mount_ffs.8 6 Oct 2016 13:16:21 - 1.18 +++ mount_ffs.8 28 Aug 2019 17:19:48 - @@ -77,6 +77,10 @@ For example, /dev/sd0a and 3eb7f9da875cb .Sq a partition. .Pp +As FFS filesystems are byte-order dependent, +.Nm +will error on a system using a different endianness. +.Pp This command is normally executed per file system by .Xr rc 8 at boot time using the
Re: FAQ: aarch64 stable packages
On Sun, Aug 25, 2019 at 09:09:58PM +0200, Alessandro Gallo wrote: > Hi, > > Looks like stable packages for aarch64 are now available (?): > > https://ftp.openbsd.org/pub/OpenBSD/6.5/packages-stable/aarch64 > > The following diff updates the relevant section of the FAQ: > > Index: faq10.html > === > RCS file: /cvs/www/faq/faq10.html,v > retrieving revision 1.288 > diff -u -p -u -p -r1.288 faq10.html > --- faq10.html14 Aug 2019 13:07:46 - 1.288 > +++ faq10.html25 Aug 2019 19:06:52 - > @@ -90,8 +90,8 @@ there are two options: > new packages will include any security fixes. > Simply call href="https://man.openbsd.org/pkg_add;>pkg_add(1) with > the -u flag to get the new files. > -Note that updated -stable packages are only available for the amd64 and > -i386 architectures. > +Note that updated -stable packages are only available for the amd64, > +i386, and aarch64 architectures. >Use the -stable ports tree > > Fetch (or update) your ports tree, > > Thanks > Indeed, we also provide aarch64 packages now :) Thx for spotting this lack, it's committed.
/etc/examples/sysctl.conf wrong Xref + key lacking information
Hi I looked at /etc/examples/sysctl.conf on an amd64 system and found 2 things: - file refers to sysctl(3) and sysctl(8). sysctl(3) doesn't exists but sysctl(2) exists, I think we want a 2 Index: sysctl.conf === RCS file: /data/cvs/src/etc/examples/sysctl.conf,v retrieving revision 1.4 diff -u -p -r1.4 sysctl.conf --- sysctl.conf 3 Apr 2015 15:50:28 - 1.4 +++ sysctl.conf 10 Sep 2019 10:50:13 - @@ -1,7 +1,7 @@ # $OpenBSD: sysctl.conf,v 1.4 2015/04/03 15:50:28 millert Exp $ # # This file contains a list of sysctl options the user wants set at -# boot time. See sysctl(3) and sysctl(8) for more information on +# boot time. See sysctl(2) and sysctl(8) for more information on # the many available variables. # #net.inet.ip.forwarding=1 # 1=Permit forwarding (routing) of IPv4 packets - the default value 1 for key machdep.pwraction=1 is not documented, comment says # ACPI power button action: 0=none, 2=suspend this is defined in etc/etc.amd64/sysctl.conf, I guess the default is 1=shutdown Index: etc/etc.amd64/sysctl.conf === RCS file: /data/cvs/src/etc/etc.amd64/sysctl.conf,v retrieving revision 1.8 diff -u -p -r1.8 sysctl.conf --- etc/etc.amd64/sysctl.conf 19 Jan 2019 20:50:38 - 1.8 +++ etc/etc.amd64/sysctl.conf 10 Sep 2019 10:58:36 - @@ -1,4 +1,4 @@ #machdep.allowaperture=2 # See xf86(4) #machdep.kbdreset=1# permit console CTRL-ALT-DEL to do a nice halt #machdep.lidaction=0 # 1=suspend, 2=hibernate laptop upon lid closing -#machdep.pwraction=1 # ACPI power button action: 0=none, 2=suspend +#machdep.pwraction=1 # ACPI power button action: 0=none, 1=shutdown, 2=suspend
apmd C getopt flag unused?
I found case 'C' in getopt in amd which is not documented and seems to be an alias for -A. Ok for removing? Index: apmd.c === RCS file: /data/cvs/src/usr.sbin/apmd/apmd.c,v retrieving revision 1.84 diff -u -p -r1.84 apmd.c --- apmd.c 4 Dec 2018 18:00:57 - 1.84 +++ apmd.c 7 Aug 2019 10:30:49 - @@ -417,7 +417,6 @@ main(int argc, char *argv[]) statonly = 1; break; case 'A': - case 'C': if (doperf != PERF_NONE) usage(); doperf = PERF_AUTO;
Re: apmd C getopt flag unused?
On Wed, Aug 07, 2019 at 12:40:03PM +0200, Claudio Jeker wrote: > On Wed, Aug 07, 2019 at 12:33:58PM +0200, Solene Rapenne wrote: > > I found case 'C' in getopt in amd which is not documented and seems to > > be an alias for -A. > > > > Ok for removing? > > Please don't, I think many people still use the old apmd -C (at least I do > have it on a few systems). Also you should remove it from the getopt > string. OK For history, commit message removing -C flag and making it fallback on -A https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/apmd/apmd.c?rev=1.71=text/x-cvsweb-markup
Re: apmd C getopt flag unused?
On Wed, Aug 07, 2019 at 12:33:58PM +0200, Solene Rapenne wrote: > I found case 'C' in getopt in amd which is not documented and seems to > be an alias for -A. > > Ok for removing? > > Index: apmd.c > === > RCS file: /data/cvs/src/usr.sbin/apmd/apmd.c,v > retrieving revision 1.84 > diff -u -p -r1.84 apmd.c > --- apmd.c4 Dec 2018 18:00:57 - 1.84 > +++ apmd.c7 Aug 2019 10:30:49 - > @@ -417,7 +417,6 @@ main(int argc, char *argv[]) > statonly = 1; > break; > case 'A': > - case 'C': > if (doperf != PERF_NONE) > usage(); > doperf = PERF_AUTO; > I sent my mail to quick. C is "PERF_COOL" profile but it doesn't seem used anymore because case 'A' and 'C' have PERF_AUTO but there is still a few lines about PERF_COOL. If someone confirms me it's obsolete, I'll do a proper diff for cleaning this.
Re: taking kernel config into consideration when reorder
On Thu, Jul 18, 2019 at 07:15:50PM +0300, Gregory Edigarov wrote: > Hello, > > Just tired a of rebooting into UKC a bit. > > diff --git a/libexec/reorder_kernel/reorder_kernel.sh > b/libexec/reorder_kernel/reorder_kernel.sh > index ecd8d8fc563..7354350505a 100644 > --- a/libexec/reorder_kernel/reorder_kernel.sh > +++ b/libexec/reorder_kernel/reorder_kernel.sh > @@ -66,5 +66,9 @@ make newbsd > make newinstall > sync > > +if [[ -f /etc/kernel.conf ]]; then > + config -ef /bsd < /etc/kernel.conf > +fi > + > echo "\nKernel has been relinked and is active on next reboot.\n" > cat $SHA256 > What is that /etc/kernel.conf file? No man page mentions it.
systat is not flushing output
I wanted to use systat -b -d 10 iostat 1 | something to parse output in
real time but it was not possible, systat doesn't flush output.
otto@ suggested this change, I tried it and it works.
This flush output at the end of writing a page in raw mode (-B or -b
flags).
ok?
Index: engine.c
===
RCS file: /data/cvs/src/usr.bin/systat/engine.c,v
retrieving revision 1.23
diff -u -p -r1.23 engine.c
--- engine.c17 Jan 2019 05:56:29 - 1.23
+++ engine.c19 Jul 2019 15:03:28 -
@@ -245,6 +245,7 @@ end_page(void)
if (rawmode) {
linepos = 0;
clear_linebuf();
+fflush(stdout);
} else {
move(home_line, 0);
print_cmdline();
sync acme-client.conf.5 with the example about LE API url
The example uses acme-v02.api.letsencrypt.org while acme-client.conf(5)
still uses v01.
Index: acme-client.conf.5
===
RCS file: /data/cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.20
diff -u -p -r1.20 acme-client.conf.5
--- acme-client.conf.5 17 Jun 2019 12:42:52 - 1.20
+++ acme-client.conf.5 4 Jul 2019 04:51:15 -
@@ -63,7 +63,7 @@ Macros are not expanded inside quotes.
.Pp
For example:
.Bd -literal -offset indent
-api_url="https://acme-v01.api.letsencrypt.org/directory;
+api_url="https://acme-v02.api.letsencrypt.org/directory;
authority letsencrypt {
api url $api_url
account key "/etc/acme/letsencrypt-privkey.pem"
Re: _pbuild user to have priority=5
On Fri, Nov 01, 2019 at 10:06:48PM -, Christian Weisgerber wrote: > On 2019-10-31, Solene Rapenne wrote: > > > I suggest adding a priority=5 to _pbuild user. > > Is this the right place? Or should dpb do this? > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > using the _pbuild class it applies for package building using make and also when using dpb (which uses make). I don't understand why it should be handled by dpb.
Re: _pbuild user to have priority=5
On Sat, Nov 02, 2019 at 01:18:53PM +, Stuart Henderson wrote: > On 2019/11/01 19:16, Theo de Raadt wrote: > > Ted Unangst wrote: > > > > > Theo de Raadt wrote: > > > > What about all the other users who aren't in staff? > > > > > > > > I think the approach is right. Push non-interactive down. > > > > > > The same then for src build user? > > > > Well, that's different. Most of us building the src tree are waiting > > eagerly for it to finish aren't we? > > That's the same for ports building! > if you don't do anything else than compiling ports, that shouldn't be slower. If you are doing something else (GUI user, web server, community server with people connected doing IRC) , then you don't get angry due to unresponsive system. Lowering staff priority would only help the one user case.
mg(1) tell make-backup-files is on by default
Someone on reddit had issue with this config file, there was no backup
file, in file directory or in ~/.mg.d
make-backup-files
backup-to-home-directory
in fact, having "make-backup-files" disables backups.
I've looked at the mg logic for backup files and I could sort that the
default make-backup-files value is 0
/funmap.c: {makebkfile, "make-backup-files", 0},
but in file.c there is a statement with a default to TRUE
* Save the contents of the current buffer back into its associated
* file.
*/
static int makebackup = TRUE;
I don't really get the logic here, nor when the configuration file and
that TRUE variable get in touch.
What I propose is to update the manual that make-backup-files is true by
default, so toggling it disable backups.
Index: mg.1
===
RCS file: /data/cvs/src/usr.bin/mg/mg.1,v
retrieving revision 1.117
diff -u -p -r1.117 mg.1
--- mg.12 Jul 2019 16:25:39 - 1.117
+++ mg.18 Nov 2019 17:16:47 -
@@ -688,6 +688,7 @@ Bind a key mapping in the local (topmost
Unbind a key mapping in the local (topmost) mode.
.It make-backup-files
Toggle generation of backup files.
+Enabled by default.
.It make-directory
Prompt the user for a path or directory name which is then created.
.It mark-paragraph
upgrade66.html missing acme-client.conf staging api url change
The staging api changed too. I know people who did not update that url, it's not especially obvious because the old url doesn't contain v01. ok ? Index: upgrade66.html === RCS file: /data/cvs/www/faq/upgrade66.html,v retrieving revision 1.15 diff -u -p -r1.15 upgrade66.html --- upgrade66.html 30 Oct 2019 04:11:00 - 1.15 +++ upgrade66.html 8 Nov 2019 17:12:01 - @@ -147,6 +147,14 @@ any post-release fixes. https://acme-v02.api.letsencrypt.org/directory + The staging api url should also be changed from + + https://acme-staging.api.letsencrypt.org/directory + to + + https://acme-staging-v02.api.letsencrypt.org/directory The -A and -D flags have been removed from https://man.openbsd.org/OpenBSD-6.6/acme-client.1;>
_pbuild user to have priority=5
I suggest adding a priority=5 to _pbuild user. I tried on a macppc, a core 2 duo laptop and i7 laptop. It helped a lot the macppc and core2 to stay responsive on ssh or being barely usable while building. On the i7, the benefits are less. At best this allows firefox to stay responsive on bloated "webapps" and avoid a few audio stuttering. I only see benefits and no drawback. Index: etc.alpha/login.conf === RCS file: /data/cvs/src/etc/etc.alpha/login.conf,v retrieving revision 1.7 diff -u -p -r1.7 login.conf --- etc.alpha/login.conf2 Jun 2019 06:46:17 - 1.7 +++ etc.alpha/login.conf31 Oct 2019 22:34:15 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.amd64/login.conf === RCS file: /data/cvs/src/etc/etc.amd64/login.conf,v retrieving revision 1.12 diff -u -p -r1.12 login.conf --- etc.amd64/login.conf19 Aug 2019 20:59:14 - 1.12 +++ etc.amd64/login.conf31 Oct 2019 22:34:20 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=6144M:\ :maxproc-max=1024:\ :maxproc-cur=384:\ + :priority=5:\ :tc=default: # Index: etc.arm64/login.conf === RCS file: /data/cvs/src/etc/etc.arm64/login.conf,v retrieving revision 1.6 diff -u -p -r1.6 login.conf --- etc.arm64/login.conf7 Oct 2019 17:52:59 - 1.6 +++ etc.arm64/login.conf31 Oct 2019 22:34:24 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=6144M:\ :maxproc-max=1024:\ :maxproc-cur=384:\ + :priority=5:\ :tc=default: # Index: etc.armv7/login.conf === RCS file: /data/cvs/src/etc/etc.armv7/login.conf,v retrieving revision 1.7 diff -u -p -r1.7 login.conf --- etc.armv7/login.conf2 Jun 2019 06:46:17 - 1.7 +++ etc.armv7/login.conf31 Oct 2019 22:34:27 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.hppa/login.conf === RCS file: /data/cvs/src/etc/etc.hppa/login.conf,v retrieving revision 1.9 diff -u -p -r1.9 login.conf --- etc.hppa/login.conf 2 Jun 2019 06:46:17 - 1.9 +++ etc.hppa/login.conf 31 Oct 2019 22:34:31 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.i386/login.conf === RCS file: /data/cvs/src/etc/etc.i386/login.conf,v retrieving revision 1.8 diff -u -p -r1.8 login.conf --- etc.i386/login.conf 2 Jun 2019 06:46:18 - 1.8 +++ etc.i386/login.conf 31 Oct 2019 22:34:36 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=2048M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.landisk/login.conf === RCS file: /data/cvs/src/etc/etc.landisk/login.conf,v retrieving revision 1.7 diff -u -p -r1.7 login.conf --- etc.landisk/login.conf 2 Jun 2019 06:46:18 - 1.7 +++ etc.landisk/login.conf 31 Oct 2019 22:34:39 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.loongson/login.conf === RCS file: /data/cvs/src/etc/etc.loongson/login.conf,v retrieving revision 1.9 diff -u -p -r1.9 login.conf --- etc.loongson/login.conf 18 Oct 2019 03:40:22 - 1.9 +++ etc.loongson/login.conf 31 Oct 2019 22:34:42 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=4096M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.luna88k/login.conf === RCS file: /data/cvs/src/etc/etc.luna88k/login.conf,v retrieving revision 1.7 diff -u -p -r1.7 login.conf --- etc.luna88k/login.conf 2 Jun 2019 06:46:18 - 1.7 +++ etc.luna88k/login.conf 31 Oct 2019 22:34:45 - @@ -95,6 +95,7 @@ pbuild:\ :datasize-cur=1024M:\ :maxproc-max=1024:\ :maxproc-cur=256:\ + :priority=5:\ :tc=default: # Index: etc.macppc/login.conf === RCS file: /data/cvs/src/etc/etc.macppc/login.conf,v retrieving revision 1.8 diff -u -p -r1.8 login.conf --- etc.macppc/login.conf 2 Jun 2019 06:46:18 -
Re: sysupgrade: Allow to use another directory for the sets
On Wed, Nov 20, 2019 at 10:55:28AM +0100, Renaud Allard wrote: > Hi Solene, > > On 11/20/19 10:46 AM, Solene Rapenne wrote: > > wouldn't be easier for people using non standard locations to write a > > small wrapper script like this (not tested, written in the mail) > > > > #!/bin/sh > > > > MYDEST=/var/sysupgrade > > > > install -d -o root -g wheel $MYDEST > > rm -fr /home/_sysupgrade > > ln -s $MYDEST /home/_sysupgrade > > > > sysupgrade -n > > if [ $? -eq 0 ] > > then > > sed -i'' "s,/home/_sysupgrade,$MYDEST" /auto_upgrade.conf > > reboot > > fi > > > > It is indeed a solution, but that still means you have to download the sets > in /home and then move them. This can be problematic if space on /home is > constrained or in the case of slow flash disks for example. > no, this script makes /home/_sysupgrade a symbolic link to the real location where you want to store the sets. So /home doesn't require more space than the requirement for an additional symlink.
Re: sysupgrade: Allow to use another directory for the sets
On Tue, Nov 12, 2019 at 07:02:56PM +0100, Renaud Allard wrote:
>
>
> On 12/11/2019 08:29, Theo de Raadt wrote:
> >
> > Renaud, please test it for me like this:
> >
> > sysupgrade -d /
> >
> > This interface is dangerously incorrect.
> >
>
> What about this one?
> Index: sysupgrade.8
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
> retrieving revision 1.10
> diff -u -p -r1.10 sysupgrade.8
> --- sysupgrade.8 3 Oct 2019 12:43:58 - 1.10
> +++ sysupgrade.8 12 Nov 2019 18:01:04 -
> @@ -24,6 +24,7 @@
> .Nm
> .Op Fl fkn
> .Op Fl r | s
> +.Op Fl d Ar directory
> .Op Ar installurl
> .Sh DESCRIPTION
> .Nm
> @@ -48,6 +49,13 @@ triggering a one-shot upgrade using the
> .Pp
> The options are as follows:
> .Bl -tag -width Ds
> +.It Fl d Ar directory
> +Choose the prefix of the
> +.Ar directory
> +in which the sets will be downloaded.
> +_sysupgrade will be appended to that name.
> +Default is
> +.Pa /home .
> .It Fl f
> Force an already applied upgrade.
> The default is to upgrade to latest snapshot only if available.
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.32
> diff -u -p -r1.32 sysupgrade.sh
> --- sysupgrade.sh 11 Nov 2019 18:26:52 - 1.32
> +++ sysupgrade.sh 12 Nov 2019 18:01:04 -
> @@ -25,7 +25,6 @@ umask 0022
> export PATH=/usr/bin:/bin:/usr/sbin:/sbin
>
> ARCH=$(uname -m)
> -SETSDIR=/home/_sysupgrade
>
> ug_err()
> {
> @@ -34,7 +33,7 @@ ug_err()
>
> usage()
> {
> - ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
> + ug_err "usage: ${0##*/} [-fkn] [-r | -s] [-d directory] [installurl]"
> }
>
> unpriv()
> @@ -73,14 +72,16 @@ rmel() {
> echo -n "$_c"
> }
>
> +SETSDIR=/home/_sysupgrade
> RELEASE=false
> SNAP=false
> FORCE=false
> KEEP=false
> REBOOT=true
>
> -while getopts fknrs arg; do
> +while getopts d:fknrs arg; do
> case ${arg} in
> + d) SETSDIR=${OPTARG}/_sysupgrade;;
> f) FORCE=true;;
> k) KEEP=true;;
> n) REBOOT=false;;
> @@ -195,7 +196,7 @@ ${KEEP} && > keep
>
> cat <<__EOT >/auto_upgrade.conf
> Location of sets = disk
> -Pathname to the sets = /home/_sysupgrade/
> +Pathname to the sets = ${SETSDIR}
> Set name(s) = done
> Directory does not contain SHA256.sig. Continue without verification = yes
> __EOT
> @@ -203,7 +204,7 @@ __EOT
> if ! ${KEEP}; then
> CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
> cat <<__EOT > /etc/rc.firsttime
> -rm -f /home/_sysupgrade/{${CLEAN}}
> +rm -f ${SETSDIR}/{${CLEAN}}
> __EOT
> fi
>
I see no objection to this diff. Changes are minimal and it allows using
another destination safely (_sysupgrade gets appended to the chosen base
directory)
ok solene@
Re: sysupgrade: Allow to use another directory for the sets
On Wed, Nov 20, 2019 at 10:37:02AM +0100, Raimo Niskanen wrote: > On Tue, Nov 19, 2019 at 09:00:33AM +, Stuart Henderson wrote: > > On 2019/11/18 14:45, Raimo Niskanen wrote: > > > On Mon, Nov 18, 2019 at 01:23:27PM +0100, Renaud Allard wrote: > > > > > > > > > > > > On 11/18/19 10:08 AM, Raimo Niskanen wrote: > > > > > > > > > A configuration parameter could be accomplished through an optional > > > > > symlink > > > > > /etc/_sysupgrade that the sysadmin can create to point at the > > > > > installation's > > > > > sysupgrade directory. The sysupgrade script would test -s > > > > > /etc/_sysupgrade > > > > > and if there is a symlink readlink -f /etc/_sysupgrade to get SETSDIR. > > > > > > > > > > > > > As it was said earlier, this doesn't solve the removal issue. With your > > > > patch, please try "ln -s /home/_sysupgrade / ; sysupgrade". > > > > > > > > > > This is actually not yet in my patch. I just want to, as a first step > > > towards either of our solutions, patch to have the /home/_sysupgrade > > > literal > > > in only one place in the sysupgrade script, which would facilitate > > > patching > > > the sysupgrade script before calling it, as a poor man's solution. > > > Plus, the script gets cleaner. > > > > > > The symlink suggestion is a future patch. > > > > > > But I think your suggestion to instead specify the parent directory of the > > > _syspatch directory should be sufficient to remedy the removal issue both > > > for your command line suggestion, as for this future patch symlink > > > suggestion. > > > > > > It is a pity nobody else has responded to that prefix suggestion of yours! > > > > It does avoid the removal issue but it seems an awkward user interface to > > pass the parent directory. Perhaps better to enforce that the path matches > > */_sysupgrade, though this also doesn't feel quite right. Perhaps add > > /_sysupgrade if it wasn't already present... > > > > > I think the feature itself is more important than if it is implemented > > > with a command line argument or a symlink. > > > > > > Other than that. What do you or anyone else think about my argument that > > > the location of the system upgrade download directory is an installation > > > configuration that will not change between upgrades and hence it would be > > > nice to not have to remember the command line argument for every future > > > sysupgrade. > > > > Generally agree, but I'm not keen on a proliferation of tiny pseudo-config > > files, and this feels maybe part of something bigger. A similar argument > > could be made for the choice of release/stable vs snaps (-s / -r here, > > -Dsnap in pkg_add) which could be in some kind of "system config" alongside > > source URLs (base, packages, firmware), a list of sets, maybe some pkg_add > > related things (whether to install debug packages?), ... > > In that case, in the current state of the matter, since there is no such > common config file yet, and all other tols use command line arguments for > similar features, we should use a command line argument here too, like > Renaud Allard proposes. Until there is a suitable config file. > > Since the prefix solution is regarded as awkward, and we want go guard > against clumsy admins using / as sysupgrade directory which would remove > kernels from the updated installation, why not normalize the -d argument > with readlink -f and simply check that it is not / . There are of > course othere directories that are inappropriate to use, but the person > doing the upgrade has to be trusted to some degree... > > And I see no reason to not at least apply my minimalistic patch suggestion > that simply defines the upgrade directory in only one place in sysupgrade. > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > wouldn't be easier for people using non standard locations to write a small wrapper script like this (not tested, written in the mail) #!/bin/sh MYDEST=/var/sysupgrade install -d -o root -g wheel $MYDEST rm -fr /home/_sysupgrade ln -s $MYDEST /home/_sysupgrade sysupgrade -n if [ $? -eq 0 ] then sed -i'' "s,/home/_sysupgrade,$MYDEST" /auto_upgrade.conf reboot fi
Re: _pbuild user to have priority=5
On Wed, Nov 06, 2019 at 02:38:52PM +0100, Marc Espie wrote: > On Sat, Nov 02, 2019 at 02:35:28PM +0100, Solene Rapenne wrote: > > On Sat, Nov 02, 2019 at 01:18:53PM +, Stuart Henderson wrote: > > > On 2019/11/01 19:16, Theo de Raadt wrote: > > > > Ted Unangst wrote: > > > > > > > > > Theo de Raadt wrote: > > > > > > What about all the other users who aren't in staff? > > > > > > > > > > > > I think the approach is right. Push non-interactive down. > > > > > > > > > > The same then for src build user? > > > > > > > > Well, that's different. Most of us building the src tree are waiting > > > > eagerly for it to finish aren't we? > > > > > > That's the same for ports building! > > > > > > > if you don't do anything else than compiling ports, that shouldn't be > > slower. > > If you are doing something else (GUI user, web server, community server > > with people connected doing IRC) , then you don't get angry due to > > unresponsive system. > > > > Lowering staff priority would only help the one user case. > > I agree with solene on that one. > > This is actually useful even if you're just building ports, because > you get a more responsive text-editor and stuff like that which is useful > when you're fixing things that broke while dpb is still going. > > I see a noticeable difference in vim showing me syntax coloring correctly > while dpb is running. > > Source is somewhat different. make build/release is sequential by nature, > as you can't really fix a part while something else is still building. > any other people noticed a difference with the priority change?
bump smtpd version?
on https://opensmtpd.org/ the OpenBSD version file says 6.6.2 while we currently have 6.6.1 in CVS. Should we bump to 6.6.2? Index: smtpd.h === RCS file: /data/cvs/src/usr.sbin/smtpd/smtpd.h,v retrieving revision 1.650 diff -u -p -r1.650 smtpd.h --- smtpd.h 8 Jan 2020 01:41:11 - 1.650 +++ smtpd.h 30 Jan 2020 13:00:21 - @@ -51,7 +51,7 @@ #define SMTPD_QUEUE_EXPIRY (4 * 24 * 60 * 60) #define SMTPD_SOCKET"/var/run/smtpd.sock" #defineSMTPD_NAME "OpenSMTPD" -#defineSMTPD_VERSION"6.6.1" +#defineSMTPD_VERSION"6.6.2" #define SMTPD_SESSION_TIMEOUT 300 #define SMTPD_BACKLOG 5
Re: [PATCH] make cwm parse /etc/ssh/ssh_known_hosts (global known hosts) as well as user's known_hosts
On Wed, Feb 12, 2020 at 07:15:36PM +0100, Franz Bettag wrote: > Dear OpenBSD folks, > > appended you will find a patch allowing cwm to also parse the contents > of /etc/ssh/ssh_known_hosts and thus extend the ssh menu. > > the diff was taken against the latest source on the github xenocara repo. > > comments and/or feedback is much appreciated. > > thanks for considering this. :) > > best regards seems people agreed to remove this feature 3 weeks ago but it's still not committed. https://marc.info/?l=openbsd-tech=157972423522573=2
Re: [UPDATE] xterm 351
Le Mon, 23 Dec 2019 17:34:10 +0100, Matthieu Herrb a écrit : > Hi, > > the diff below (also available as https://xenocara.org/xterm-351.diff) > updates xterm to version 351 (from current version 344 in xenocara). > > For a detailed change log see > https://invisible-island.net/xterm/xterm.log.html > > Please test and report. Oks welcome too. > I did try a few ncurses programs on top of my usual workflow and no issue so far. ok solene@
Re: Audio over hdmi
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
> Hi,
>
> I decided to take a look at what was missing to make audio over hdmi
> working on OpenBSD.
>
> After enabling AZALIA_DEBUG in the kernel config I commented the code
> that disables HDMI codecs like the following :
>
>
> --- azalia.c.orig Thu Apr 23 11:44:52 2020
> +++ azalia.c Fri Apr 24 12:53:15 2020
> @@ -926,9 +926,11 @@
> c = -1;
> for (i = 0; i < az->ncodecs; i++) {
> codec = >codecs[i];
> +/*
> if ((codec->audiofunc < 0) ||
> (codec->codec_type == AZ_CODEC_TYPE_HDMI))
> continue;
> +*/
> if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
> if (c < 0)
> c = i;
>
>
> And after rebooting with the modified kernel audio over HDMI was
> working out of the box (see the following diff).
>
> I suspect that it is pure luck, what could I miss ?
> Could someone test it on Intel based computers ?
>
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
dmesg
OpenBSD 6.7-beta (GENERIC.MP) #0: Sat Apr 25 12:02:14 CEST 2020
solene@solene.perso.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8323534848 (7937MB)
avail mem = 8058654720 (7685MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaf07e000 (63 entries)
bios0: vendor LENOVO version "N24ET51W (1.26 )" date 08/30/2019
bios0: LENOVO 20L5CTO1WW
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT
SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM
DMAR ASF! FPDT UEFI BGRT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.82 MHz, 06-8e-0a
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,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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
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,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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
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,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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu3:
resolv.conf(5) says options inet6 does nothing
Is there a reason to keep this part in resolv.conf(5) about an option doing nothing? > options inet6 > Enables support for IPv6-only applications, by setting RES_USE_INET6 > in _res.options (see res_init(3)). On OpenBSD this option does > nothing. If we can remove it, here is the diff. Index: resolv.conf.5 === RCS file: /home/cvs/src/share/man/man5/resolv.conf.5,v retrieving revision 1.59 diff -u -p -r1.59 resolv.conf.5 --- resolv.conf.5 24 Jan 2020 06:16:47 - 1.59 +++ resolv.conf.5 23 Apr 2020 15:09:42 - @@ -258,13 +258,6 @@ particularly if there is a reduced MTU, as is often the case with .Xr pppoe 4 or with tunnels. -.It Cm inet6 -Enables support for IPv6-only applications, by setting RES_USE_INET6 in -_res.options (see -.Xr res_init 3 ) . -On -.Ox -this option does nothing. .It Cm insecure1 Do not require IP source address on the reply packet to be equal to the server's address.
Re: iwn/athn/wpi: fix CCMP replay check with HW crypto
Le Fri, 15 May 2020 11:02:46 +0200,
Stefan Sperling a écrit :
> On Fri, May 08, 2020 at 10:53:30AM +0200, Stefan Sperling wrote:
> > So the diff below contains just the reordering fix for drivers using
> > hardware acceleration for WPA.
>
> Is there anybody who wants to OK this?
>
> To recap:
>
> Currently, CCMP replay checking is skipped for aggregated 11n frames
> on drivers which use CCMP hardware acceleration: athn(4) and iwn(4).
>
> This diff makes reply checking in that case possible without false
> positives, by updating the last-seen packet number after the
> aggregated subframes, which may be received out of order, have been
> put back into their intended order by ieee80211_input_ba(). The old
> code only works in the single-frame case for 11a/b/g modes where no
> such legitimate re-transmissions can occur.
>
> > diff refs/heads/master refs/heads/pn
> > blob - 9193ae3c7b5101a86b85b1b3ba48489d75f5150c
> > blob + 8bc189dc146562f7ab0af2f1690fa02676aecfcd
> > --- sys/dev/ic/ar5008.c
> > +++ sys/dev/ic/ar5008.c
> > @@ -794,9 +794,8 @@ ar5008_ccmp_decap(struct athn_softc *sc, struct
> > mbuf * struct ieee80211_frame *wh;
> > struct ieee80211_rx_ba *ba;
> > uint64_t pn, *prsc;
> > - u_int8_t *ivp, *mmie;
> > + u_int8_t *ivp;
> > uint8_t tid;
> > - uint16_t kid;
> > int hdrlen, hasqos;
> > uintptr_t entry;
> >
> > @@ -805,35 +804,8 @@ ar5008_ccmp_decap(struct athn_softc *sc,
> > struct mbuf * ivp = mtod(m, u_int8_t *) + hdrlen;
> >
> > /* find key for decryption */
> > - if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) {
> > - k = >ni_pairwise_key;
> > - } else if ((wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK) !=
> > - IEEE80211_FC0_TYPE_MGT) {
> > - /* retrieve group data key id from IV field */
> > - /* check that IV field is present */
> > - if (m->m_len < hdrlen + 4)
> > - return 1;
> > - kid = ivp[3] >> 6;
> > - k = >ic_nw_keys[kid];
> > - } else {
> > - /* retrieve integrity group key id from MMIE */
> > - if (m->m_len < sizeof(*wh) + IEEE80211_MMIE_LEN) {
> > - return 1;
> > - }
> > - /* it is assumed management frames are contiguous
> > */
> > - mmie = (u_int8_t *)wh + m->m_len -
> > IEEE80211_MMIE_LEN;
> > - /* check that MMIE is valid */
> > - if (mmie[0] != IEEE80211_ELEMID_MMIE || mmie[1] !=
> > 16) {
> > - return 1;
> > - }
> > - kid = LE_READ_2([2]);
> > - if (kid != 4 && kid != 5) {
> > - return 1;
> > - }
> > - k = >ic_nw_keys[kid];
> > - }
> > -
> > - if (k->k_cipher != IEEE80211_CIPHER_CCMP)
> > + k = ieee80211_get_rxkey(ic, m, ni);
> > + if (k == NULL || k->k_cipher != IEEE80211_CIPHER_CCMP)
> > return 1;
> >
> > /* Sanity checks to ensure this is really a key we
> > installed. */ @@ -853,7 +825,7 @@ ar5008_ccmp_decap(struct
> > athn_softc *sc, struct mbuf * hasqos = ieee80211_has_qos(wh);
> > tid = hasqos ? ieee80211_get_qos(wh) & IEEE80211_QOS_TID :
> > 0; ba = hasqos ? >ni_rx_ba[tid] : NULL;
> > - prsc = >k_rsc[0];
> > + prsc = >k_rsc[tid];
> >
> > /* Extract the 48-bit PN from the CCMP header. */
> > pn = (uint64_t)ivp[0] |
> > @@ -863,30 +835,12 @@ ar5008_ccmp_decap(struct athn_softc *sc,
> > struct mbuf * (uint64_t)ivp[6] << 32 |
> > (uint64_t)ivp[7] << 40;
> > if (pn <= *prsc) {
> > - if (hasqos && ba->ba_state == IEEE80211_BA_AGREED)
> > {
> > - /*
> > -* This is an A-MPDU subframe.
> > -* Such frames may be received out of
> > order due to
> > -* legitimate retransmissions of failed
> > subframes
> > -* in previous A-MPDUs. Duplicates will be
> > handled
> > -* in ieee80211_inputm() as part of A-MPDU
> > reordering.
> > -*
> > -* XXX TODO We can probably do better than
> > this! Store
> > -* re-ordered PN in BA agreement state and
> > check it?
> > -*/
> > - } else {
> > - ic->ic_stats.is_ccmp_replays++;
> > - return 1;
> > - }
> > + ic->ic_stats.is_ccmp_replays++;
> > + return 1;
> > }
> > - /* Update last seen packet number. */
> > - *prsc = pn;
> > + /* Last seen packet number is updated in
> > ieee80211_inputm(). */
> > - /* Clear Protected bit and strip IV. */
> > - wh->i_fc[1] &= ~IEEE80211_FC1_PROTECTED;
> > - memmove(mtod(m, caddr_t) + IEEE80211_CCMP_HDRLEN, wh,
> > hdrlen);
> > - m_adj(m, IEEE80211_CCMP_HDRLEN);
> > - /* Strip MIC. */
> > + /* Strip MIC. IV will be stripped by ieee80211_inputm(). */
> > m_adj(m, -IEEE80211_CCMP_MICLEN);
> > return 0;
> > }
> > blob - 6b6331d167a881a526b9d0a30f7f452882fee19a
Re: userland clock_gettime proof of concept
Le Wed, 13 May 2020 17:03:01 +0300, Paul Irofti a écrit : > Hi, > > By far one of the most popular and frequently used system calls is > clock_gettime(2). As a result the cost of kernel-userland transitions > out weight the actual work, thus I am proposing we make the data > available directly from userland without passing through a system > call. > > This has been a subject of discussion multiple times across the years > and last I heard from it was at the p2k19 hackthon that I hosted in > Bucharest where espie@ sent me a diff from one of his students(?). > Being busy with organization I have not had the time to look at it and > I am thus getting back to it just now due to robert@ prodding me again > on the subject. The proposed diff is mine, not the student's. > > > The technical bits. > > Please keep in mind that this is only proof of concept. I am looking > for ways to improve the current diff. As it is, it requires a flag day > because it makes use of ELF aux vectors to export the data from the > kernel. > > I have also played with exposing the data via separate ELF sections > and with kbind-mmap alternatives. The frist also involves a flag day > and is more intrusive in my opinion, and the second I could not get > to work. I think that would be the less intrusive way of doing it, > possibly without a flag day, so if anyone knows how, please let me > know. > > The supported clocks are just those that do not require process > specific data. Those can also be handled later if this diff is > decided to be a good thing. > > Clock update inside the kernel is done at the end of tc_windup(). > There might be better places to do it. Let me know where. > > The update currently does the work of clock_gettime(), but it can > probably be changed to only update the timehands and move the logic > elsewhere. Note that if we expose only the timehands to userland, most > of the bintime functionality has to also be made available there. Or > so I think. > > In userland, I wrapped the clock_gettime(2) syscall in libc. There, I > search for the auxiliary vector and fetch the timespec data from it. > As you can see in the diff, parts from the elf_exec header will have > to be exposed to userland if we do it this way. > > > Results. > > To test this diff you need to do a full release(8). I have tested this > with multiple programs. Test programs, base programs and packages. > None the less, this diff touches many important areas of our tree and > is very fragile. I also probably missed changing some parts that > required change due to libc or elf changes. > > If you see regressions, which you probably will, please let me know. With the patch, system crashes reliably at boot when prompting for login I followed release(8) instructions, did I miss something? cd /sys/arch/$(machine)/compile/GENERIC.MP make obj make config make && make install reboot cd /usrc/src make obj make build sysmerge cd /dev && ./MAKEDEV all cd /usr/xenocara make bootstrap make obj make build reboot I got a first panic like « panic init died (signal 0, exit 11) when I typed reboot. Now, if I start the system with the new kernel (old kernel.sp still work), I get either a panic init died or I have ddb but can't type in it. This happens after full boot sequence when I'm prompted for login: I tried to disable all pkg_services and xdm and it still crash at this step, I can't login. 2 screenshots of crashes errors https://perso.pw/IMG_20200514_110104.jpg https://perso.pw/IMG_20200514_110451.jpg dmesg output (from bsd.sp kernel which still boots) OpenBSD 6.7 (GENERIC) #179: Thu May 7 11:02:37 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 8033624064 (7661MB) avail mem = 611776 (7417MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec070 (76 entries) bios0: vendor American Megatrends Inc. version "FB" date 06/25/2014 bios0: Gigabyte Technology Co., Ltd. H81M-D2V acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SSDT SSDT MCFG HPET SSDT SSDT acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(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) i3-4160 CPU @ 3.60GHz, 3592.14 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,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: smt 0, core 0,
Re: RFC: kern.video.record
On Sun, 13 Sep 2020 09:23:36 +0100 Laurence Tratt : > Since I recently opened my big fat mouth and suggested that > "kern.video.record" (analogous to kern.audio.record) might be a good idea, I > decided to put together a quick prototype (heavily based on the > kern.audio.record code). This at least roughly works for me but raises some > questions such as: I vote for keeping both so we can enable audio only or video only and be sure about what is enabled and able to record our environment
sysupgrade change to allow installing from url
Hi,
I don't know if this will be accepted but I propose to add a -u [url]
parameter to use older snapshots from an archive server for example.
I wanted to add an optional parameter to -s at first but in case of
sysupgrade -s [installurl] the install url would have been mistaken by
this.
If you specify a -u url and installurl at the same time, -u url
superseed installurl.
This would allow easier bisecting using older snapshots.
Index: sysupgrade.8
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
retrieving revision 1.10
diff -u -p -r1.10 sysupgrade.8
--- sysupgrade.83 Oct 2019 12:43:58 - 1.10
+++ sysupgrade.825 May 2020 13:23:06 -
@@ -24,6 +24,7 @@
.Nm
.Op Fl fkn
.Op Fl r | s
+.Op Fl u Pa url
.Op Ar installurl
.Sh DESCRIPTION
.Nm
@@ -66,6 +67,13 @@ This is the default if the system is cur
.It Fl s
Upgrade to a snapshot.
This is the default if the system is currently running a snapshot.
+.It Fl u Pa url
+Fetch and verify the files downloaded from
+.Pa url .
+This is superseeding
+.Op Pa installurl ,
+its usage is intended for installing older snapshots available under url not
following
+the usual installurl format.
.El
.Sh FILES
.Bl -tag -width "/auto_upgrade.conf" -compact
Index: sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.37
diff -u -p -r1.37 sysupgrade.sh
--- sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
+++ sysupgrade.sh 25 May 2020 13:23:06 -
@@ -34,7 +34,7 @@ ug_err()
usage()
{
- ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
+ ug_err "usage: ${0##*/} [-fkn] [-r | -s] [-u url] [installurl]"
}
unpriv()
@@ -79,13 +79,14 @@ FORCE=false
KEEP=false
REBOOT=true
-while getopts fknrs arg; do
+while getopts fknrsu: arg; do
case ${arg} in
f) FORCE=true;;
k) KEEP=true;;
n) REBOOT=false;;
r) RELEASE=true;;
s) SNAP=true;;
+ u) SNAPURL=${OPTARG};;
*) usage;;
esac
done
@@ -121,7 +122,11 @@ else
fi
if $SNAP; then
- URL=${MIRROR}/snapshots/${ARCH}/
+ if [[ -n "$SNAPURL" ]]; then
+ URL=$SNAPURL
+ else
+ URL=${MIRROR}/snapshots/${ARCH}/
+ fi
else
URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
fi
Re: Avoid offline cpu in automatic frequency scheduling
On Thu, 28 May 2020 16:29:19 +0200 Solene Rapenne : > so, this diff skip offline cpus in the loop (robert@ gave me the big > clue to use cpu_is_online in the loop) apologies, it was claudio@ but robert@ helped too.
Re: Avoid offline cpu in automatic frequency scheduling
On Thu, 28 May 2020 11:43:07 -0400 Bryan Steele : > On Thu, May 28, 2020 at 04:29:19PM +0200, Solene Rapenne wrote: > > the macro CPU_INFO_FOREACH loop over every CPU but the frequency > > algorithm will raise frequency if one cpu usage goes over a > > threshold but also if the sum of cpu usage goes over another > > threshold. > > > > In the current case, if you have offline cpu (because of hw.smt=0), > > the total will still sum all the idle cpu and it's unlikely that > > the total threshold is ever reached before the per cpu one. > > > > so, this diff skip offline cpus in the loop (robert@ gave me the big > > clue to use cpu_is_online in the loop) > > Thanks for finding this solene! Nice work. > > I've been aware of some issues on AMD with the automatic frequency > scaling and haven't been able to narrow them down. This may not solve > all of them, but does appear to improve things on Ryzen CPUs which > have many cores/threads and no BIOS knob to disable SMT. > > Assuming others agree with the approach.. > > ok brynet@ I think this should help CPU with a lot of cores. If I got the algorithm right this is doing this: if 1 cpu has idle < 25% then scale up OR if sum cpu idle < 33% then scale up when it scales up, it will bump a ticker to 5 and set perf to 100% and check again in the next 100ms. Everytime the loop doesn't need to scale up (but is still at 100% freq) it decrement the ticket. Once the ticket is 0 or less, then the frequency goes to minimum. with the current state, if you have offline cpu, you can never go under 50% of the total idle. So the only way to scale up is to have 1 CPU with less than 25% idle. It's a lot of magic numbers without explanation here. I'm curious if this could be improved. I guess that changing them would tip the balance between responsiveness and battery saving.
Avoid offline cpu in automatic frequency scheduling
the macro CPU_INFO_FOREACH loop over every CPU but the frequency
algorithm will raise frequency if one cpu usage goes over a threshold
but also if the sum of cpu usage goes over another threshold.
In the current case, if you have offline cpu (because of hw.smt=0), the
total will still sum all the idle cpu and it's unlikely that the total
threshold is ever reached before the per cpu one.
so, this diff skip offline cpus in the loop (robert@ gave me the big
clue to use cpu_is_online in the loop)
Index: sched_bsd.c
===
RCS file: /cvs/src/sys/kern/sched_bsd.c,v
retrieving revision 1.62
diff -u -p -r1.62 sched_bsd.c
--- sched_bsd.c 30 Jan 2020 08:51:27 - 1.62
+++ sched_bsd.c 28 May 2020 14:21:25 -
@@ -576,6 +576,8 @@ setperf_auto(void *v)
j = 0;
speedup = 0;
CPU_INFO_FOREACH(cii, ci) {
+ if (!cpu_is_online(ci))
+ continue;
total = 0;
for (i = 0; i < CPUSTATES; i++) {
total += ci->ci_schedstate.spc_cp_time[i];
Re: patch: httpd(8) use LOG_FTP for transfers, like $DEITY intended
On Mon, 26 Oct 2020 17:32:41 +0100
:
> #?patch
> #
> # This patch corrects the logging of transfers, of OpenBSD's httpd(8),
> # to xferlog, where it belongs.
> #
> # A simple patch to a waaay overcomplicated bit of software (with insane
> # defaults to boot; security anyone?).
> #
> # --zeurkous, Sat Oct 24 17:51:55 UTC 2020.
> #
> --- src/usr.sbin/httpd/..v/OPENBSD_6_6/server.c Fri Jun 28 13:32:47 2019
> +++ src/usr.sbin/httpd/server.c Sat Oct 24 17:45:43 2020
> @@ -1241,7 +1241,7 @@
> if (srv_conf->flags & SRVFLAG_SYSLOG) {
> va_start(ap, emsg);
> if (cmd == IMSG_LOG_ACCESS)
> - vlog(LOG_INFO, emsg, ap);
> + vlog(LOG_FTP, emsg, ap);
> else
> vlog(LOG_DEBUG, emsg, ap);
> va_end(ap);
>
if this makes it into the tree, syslog(3) must be
updated to explain LOG_FTP is also logging httpd
add a section exit status in syspatch.8
this diff adds an EXIT STATUS section to syspatch man page. syspatch exit with 1 on errors and 2 if syspatch updates itself. If syspatch does nothing (because no syspatch) or install syspatches successfully, the exit status is 0 in both case. Should we emphase on this? I guess « Did syspatch install something? » is a common question and the exit status can't help. Index: syspatch.8 === RCS file: /cvs/src/usr.sbin/syspatch/syspatch.8,v retrieving revision 1.20 diff -u -p -r1.20 syspatch.8 --- syspatch.8 15 Jun 2019 16:54:19 - 1.20 +++ syspatch.8 19 Jul 2020 22:07:40 - @@ -62,6 +62,8 @@ Directories containing the rollback tarb .Xr diff 1 of installed patches. .El +.Sh EXIT STATUS +.Ex -std syspatch .Sh SEE ALSO .Xr signify 1 , .Xr installurl 5 ,
Re: [PATCH]: Add a check for upgrade feature to sysupgrade(8)
On Mon, 3 Aug 2020 13:28:38 +0200 Emil Engler : > ## Abstract > This patch adds an argument to sysupgrade(8) which makes it possible > to check if an upgrade is available, similar to "syspatch -c". > This works both, for snapshots and releases. > > ## Usage > Add "-c" to sysupgrade. > If the script exits with a zero, an upgrade is available. If it fails > you are already on the newest version or an upgrade cannot be pulled > for whatever reason. > > ## Motivation > I want a cronjob on my desktop (which is on -current) that checks > regularly if a new snapshot is available and notifies me if this is > the case. syspatch(8) already has such a feature, so why not add > one to sysupgrade? Also it could be useful on -stable and -release > systems. it seems to me you could use this in your crontab sysupgrade -n | grep "Already on last snapshot" || sh send_mail_new_snasphot.sh
current.html: i586 requirement for i386 architecture
Now that i386 platform requires i586 CPU, I guess we should mention it in current.html (the page i386.html should be updated accordingly at 6.8 release) Index: current.html === RCS file: /home/reposync/www/faq/current.html,v retrieving revision 1.1048 diff -u -p -r1.1048 current.html --- current.html11 Jul 2020 16:53:47 - 1.1048 +++ current.html7 Aug 2020 13:43:25 - @@ -57,6 +57,16 @@ use a snapshot to recover. Most of these changes will have to be performed as root. +2020/08/03 - i386 requirements raised to i586 + +Due to llvm upgrade to version 10 in base system, the minimal +CPU instruction sets requirements for i386 architecture has been +raised from i386 to i586. + +In concrete terms for Intel and AMD CPUs, Intel Pentium and AMD K5 +are now the minimal requirements for i386 architecture. + + 2020/05/29 - [ports] net/isc-bind example files dropped Outdated example configuration (including some "standard" zone files and
Re: UPgrading pkg to 6.7 missed a package
On Mon, 13 Jul 2020 15:39:39 -0400 sven falempin : > Readers, > > pkg_add -u > failed to upgrade > > p5-DBD-MariaDB-1.2 > to > p5-DBD-MariaDB-1.21p0 > > p5-DBD-MariaDB-1.2 is previous released so maybe it is too old and my fault > , but it is > odd that pkg_add -u p5-DBD-MariaDB does nothing when p5-DBD-MariaDB-1.2 is > in the package list > > and p5-DBD-MariaDB-1.21p0.tgz available in the package depot. > > Best. > Could you share the error from pkg_add and a dmesg?
Re: ssh-keygen(1): -a is missing in SYNOPSIS and small wording change
On Thu, 25 Jun 2020 18:02:23 +0100
Jason McIntyre :
> On Thu, Jun 25, 2020 at 06:40:36PM +0200, Solene Rapenne wrote:
> > I found that ssh-keygen(1) missed mention of -a flag in SYNOPSIS.
> >
>
> i think this got accidently removed in -r1.184:
>
> remove single letter flags for moduli operations
>
> > The following patch adds mention to [-a rounds] with default (no
> > flag), -p, -c, -K and -A
> >
>
> i'm definitely not the right person to ok that
>
> > All the functions triggered by these flags use the rounds variable
> > defined with -a parameter (default 0)
> >
> >
> > I also propose a small wording change, in the sentence:
> > "After a key is generated, instructions below detail [...]"
> >
> > I thought below refered to the list of options after that sentence,
> > but it may be a mistake of mine here.
> >
>
> i wanted to ask about this text too. it's unclear to me. after a key is
> generated, ssh-keygen asks where to save it. i wonder why we use the
> wording "should be placed to be activated"? it seems odd, but maybe
> there's a reason.
>
> jmc
I don't really understand the whole sentence but I thought it was
due to my english understanding.
New patch adding [-a rounds] in ssh-keygen usage(). I'm not sure
if the first line of usage() output is ok or too long now.
Index: ssh-keygen.1
===
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.1,v
retrieving revision 1.203
diff -u -p -r1.203 ssh-keygen.1
--- ssh-keygen.13 Apr 2020 02:26:56 - 1.203
+++ ssh-keygen.113 Jul 2020 20:34:14 -
@@ -44,6 +44,7 @@
.Sh SYNOPSIS
.Nm ssh-keygen
.Op Fl q
+.Op Fl a Ar rounds
.Op Fl b Ar bits
.Op Fl C Ar comment
.Op Fl f Ar output_keyfile
@@ -54,6 +55,7 @@
.Op Fl w Ar provider
.Nm ssh-keygen
.Fl p
+.Op Fl a Ar rounds
.Op Fl f Ar keyfile
.Op Fl m Ar format
.Op Fl N Ar new_passphrase
@@ -71,6 +73,7 @@
.Op Fl f Ar input_keyfile
.Nm ssh-keygen
.Fl c
+.Op Fl a Ar rounds
.Op Fl C Ar comment
.Op Fl f Ar keyfile
.Op Fl P Ar passphrase
@@ -93,6 +96,7 @@
.Op Fl f Ar known_hosts_file
.Nm ssh-keygen
.Fl K
+.Op Fl a Ar rounds
.Op Fl w Ar provider
.Nm ssh-keygen
.Fl R Ar hostname
@@ -125,6 +129,7 @@
.Op Fl f Ar input_keyfile
.Nm ssh-keygen
.Fl A
+.Op Fl a Ar rounds
.Op Fl f Ar prefix_path
.Nm ssh-keygen
.Fl k
@@ -248,7 +253,9 @@ keys may be converted using this option
.Fl p
(change passphrase) flag.
.Pp
-After a key is generated, instructions below detail where the keys
+After a key is generated,
+.Nm
+will ask where the keys
should be placed to be activated.
.Pp
The options are as follows:
Index: ssh-keygen.c
===
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v
retrieving revision 1.413
diff -u -p -r1.413 ssh-keygen.c
--- ssh-keygen.c26 Jun 2020 05:02:03 - 1.413
+++ ssh-keygen.c13 Jul 2020 20:34:15 -
@@ -3013,15 +3013,15 @@ static void
usage(void)
{
fprintf(stderr,
- "usage: ssh-keygen [-q] [-b bits] [-C comment] [-f output_keyfile]
[-m format]\n"
+ "usage: ssh-keygen [-q] [-a rounds] [-b bits] [-C comment] [-f
output_keyfile] [-m format]\n"
" [-t dsa | ecdsa | ecdsa-sk | ed25519 |
ed25519-sk | rsa]\n"
" [-N new_passphrase] [-O option] [-w provider]\n"
- " ssh-keygen -p [-f keyfile] [-m format] [-N
new_passphrase]\n"
+ " ssh-keygen -p [-a rounds] [-f keyfile] [-m format] [-N
new_passphrase]\n"
" [-P old_passphrase]\n"
" ssh-keygen -i [-f input_keyfile] [-m key_format]\n"
" ssh-keygen -e [-f input_keyfile] [-m key_format]\n"
" ssh-keygen -y [-f input_keyfile]\n"
- " ssh-keygen -c [-C comment] [-f keyfile] [-P passphrase]\n"
+ " ssh-keygen -c [-a rounds] [-C comment] [-f keyfile] [-P
passphrase]\n"
" ssh-keygen -l [-v] [-E fingerprint_hash] [-f
input_keyfile]\n"
" ssh-keygen -B [-f input_keyfile]\n");
#ifdef ENABLE_PKCS11
@@ -3031,7 +3031,7 @@ usage(void)
fprintf(stderr,
" ssh-keygen -F hostname [-lv] [-f known_hosts_file]\n"
" ssh-keygen -H [-f known_hosts_file]\n"
- " ssh-keygen -K [-w provider]\n"
+ " ssh-keygen -K [-a rounds] [-w provider]\n"
" ssh-keygen -R hostname [-f known_hosts_file]\n"
" ssh-keygen -r hostname [-g] [-f input_keyfile]\n"
#ifdef WITH_OPENSS
Re: fsck_ffs: faster with lots of cylinder groups
On Sun, 12 Jul 2020 09:13:47 +0200 Otto Moerbeek : > On Mon, Jun 29, 2020 at 02:30:41PM +0200, Otto Moerbeek wrote: > > > On Sun, Jun 21, 2020 at 03:35:21PM +0200, Otto Moerbeek wrote: > > > > > Hi, > > > > > > both phase 1 and phase 5 need cylinder group metadata. This diff > > > keeps the cg data read in phase 1 in memory to be used by phase 5 if > > > possible. From FreeBSD. > > > > > > -Otto > > > > > > On an empty 30T fileystem: > > > > > > $ time obj/fsck_ffs -f /dev/sd3a > > > 2m44.10s real 0m13.21s user 0m07.38s system > > > > > > $ time doas obj/fsck_ffs -f /dev/sd3a > > > 1m32.81s real 0m12.86s user 0m05.25s system > > > > > > The difference will be less if a fileystem is filled up, but still nice. > > > > Any takers? > > No feedback. I'm getting discouraged in doing more filesystem work... > > What to do? > > 1) Abondon the diff > 2) Commit without ok > > I did quite extensive testing, but both options are unsatisfactory. > > -Otto I'm not sure how to test your diff. Would running fsck on a sane filesystem enough? Are you using Vms that you halt to force a fsck on them? Would this be a good test too?
improve pkg_add bandwidth usage with some mirrors
I propose a small diff for pkg_add when using http/https mirrors.
Don't wait 30 seconds for the ftp process to stop when closing
file handler, send SIGHUP immediately after closing the file handler.
Running pkg_add -u neovim (already installed and up to date) I got
those results of bandwidth usage
using mirror https://mirror.one.com/pub/OpenBSD/
62513 kB without diff
9050 kB with diff
using mirror https://ftp.fr.openbsd.org/pub/OpenBSD
6530 kB without diff
6373 kB with diff
The 2500 kB difference between the two mirrors with the diff is
explained by the html directory listing which is different
between servers. mirror.one.com list is 3800 kB while
ftp.fr.openbsd.org only 1387 kB.
I can't explain why but when using mirror.one.com the ftp command will
continuously fetch packages until completion or stop if ftp is killed
after 30 seconds. This extra downloaded data is useless.
I came with the following diff, but maybe the real issue is ftp(1)
not stopping immediately if output is closed?
Index: OpenBSD/PackageRepository.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm,v
retrieving revision 1.171
diff -u -p -r1.171 PackageRepository.pm
--- OpenBSD/PackageRepository.pm8 Nov 2019 14:50:58 - 1.171
+++ OpenBSD/PackageRepository.pm17 Jun 2020 09:21:41 -
@@ -206,12 +206,8 @@ sub close
my ($self, $object, $hint) = @_;
close($object->{fh}) if defined $object->{fh};
if (defined $object->{pid2}) {
- local $SIG{ALRM} = sub {
- kill HUP => $object->{pid2};
- };
- alarm(30);
+ kill HUP => $object->{pid2};
waitpid($object->{pid2}, 0);
- alarm(0);
}
$self->parse_problems($object->{errors}, $hint, $object)
if defined $object->{errors};
Re: Destructive Install Process (fdisk)
On Thu, 25 Jun 2020 19:27:22 -0400 David Blevins : > OpenBSD Community, > > I've been experimenting with the OpenBSD 6.7 install process (though > this "issue" is likely present in earlier version) and have noticed > that the fdisk program in the installation program will destructively > edit the hard drive upon selecting either MBR or GPT partitioning. > I have repeatedly wiped a test hard drive's partitioning scheme as a > consequence of this, in spite of only desiring to examine the > partitioning scheme. > This is explained in the INSTALL.amd64 file (I guess you use amd64) https://ftp.fr.openbsd.org/pub/OpenBSD/6.7/amd64/INSTALL.amd64 The installation program will ask you if you want to use the whole disk for OpenBSD. If you don't need to or don't intend to share the disk with other operating systems, answer "w" here to use "MBR" partitioning or "g" to use "GPT" partitioning. The installation program will then create a single partition spanning the whole disk, dedicated to OpenBSD. > Additionally, I have noticed that (per warnings in the installation > program) GPT partitioning does not work on my system. Does anyone > have insight into this issue, and if so is there any interest in > a fix for GPT partitioning? > > -David Blevins You shoud provide information about your system. I never had issue with GPT.
ssh-keygen(1): -a is missing in SYNOPSIS and small wording change
I found that ssh-keygen(1) missed mention of -a flag in SYNOPSIS. The following patch adds mention to [-a rounds] with default (no flag), -p, -c, -K and -A All the functions triggered by these flags use the rounds variable defined with -a parameter (default 0) I also propose a small wording change, in the sentence: "After a key is generated, instructions below detail [...]" I thought below refered to the list of options after that sentence, but it may be a mistake of mine here. Index: ssh-keygen.1 === RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.1,v retrieving revision 1.203 diff -u -p -r1.203 ssh-keygen.1 --- ssh-keygen.13 Apr 2020 02:26:56 - 1.203 +++ ssh-keygen.125 Jun 2020 16:28:54 - @@ -44,6 +44,7 @@ .Sh SYNOPSIS .Nm ssh-keygen .Op Fl q +.Op Fl a Ar rounds .Op Fl b Ar bits .Op Fl C Ar comment .Op Fl f Ar output_keyfile @@ -54,6 +55,7 @@ .Op Fl w Ar provider .Nm ssh-keygen .Fl p +.Op Fl a Ar rounds .Op Fl f Ar keyfile .Op Fl m Ar format .Op Fl N Ar new_passphrase @@ -71,6 +73,7 @@ .Op Fl f Ar input_keyfile .Nm ssh-keygen .Fl c +.Op Fl a Ar rounds .Op Fl C Ar comment .Op Fl f Ar keyfile .Op Fl P Ar passphrase @@ -93,6 +96,7 @@ .Op Fl f Ar known_hosts_file .Nm ssh-keygen .Fl K +.Op Fl a Ar rounds .Op Fl w Ar provider .Nm ssh-keygen .Fl R Ar hostname @@ -125,6 +129,7 @@ .Op Fl f Ar input_keyfile .Nm ssh-keygen .Fl A +.Op Fl a Ar rounds .Op Fl f Ar prefix_path .Nm ssh-keygen .Fl k @@ -248,7 +253,9 @@ keys may be converted using this option .Fl p (change passphrase) flag. .Pp -After a key is generated, instructions below detail where the keys +After a key is generated, +.Nm +will ask where the keys should be placed to be activated. .Pp The options are as follows:
Re: improve pkg_add bandwidth usage with some mirrors
On Fri, 19 Jun 2020 14:42:54 +0200 Theo Buehler : > On Fri, Jun 19, 2020 at 11:42:44AM -, Christian Weisgerber wrote: > [...] > [...] > [...] > > Yes, jsing wanted to take a closer look. I will commit the diff > tonight UTC unless I hear an objection (I have an ok beck). > I confirm that with this patch pkg_add doesn't download extra bytes.
Re: syspatch exit state
On Mon, 7 Dec 2020 13:39:30 +0100
Antoine Jacoutot :
> Index: syspatch.8
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.8,v
> retrieving revision 1.21
> diff -u -p -r1.21 syspatch.8
> --- syspatch.825 Jul 2020 15:45:44 - 1.21
> +++ syspatch.87 Dec 2020 12:39:07 -
> @@ -64,6 +64,8 @@ of installed patches.
> .El
> .Sh EXIT STATUS
> .Ex -std syspatch
> +In particular, 2 indicates that applying patches was requested but no
> +additional patch was installed.
> .Sh SEE ALSO
> .Xr signify 1 ,
> .Xr installurl 5 ,
> Index: syspatch.sh
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
> retrieving revision 1.166
> diff -u -p -r1.166 syspatch.sh
> --- syspatch.sh 27 Oct 2020 17:42:05 - 1.166
> +++ syspatch.sh 7 Dec 2020 12:39:07 -
> @@ -320,6 +320,7 @@ if ((OPTIND == 1)); then
> [[ -f ${_D}/rollback.tgz ]] || rm -r ${_D}
> done
> _PATCHES=$(ls_missing) # can't use errexit in a for loop
> + [[ -n ${_PATCHES} ]] || exit 2
> for _PATCH in ${_PATCHES}; do
> apply_patch ${_OSrev}-${_PATCH}
> _PATCH_APPLIED=true
>
>
In my opinion, if committed it deserves an entry in
https://www.openbsd.org/faq/current.html
Re: clean /dev from /etc/daily ?
On Mon, 23 Nov 2020 14:46:29 + Stuart Henderson : > On 2020/11/23 09:31, Bryan Steele wrote: > > On Mon, Nov 23, 2020 at 03:25:34PM +0100, Otto Moerbeek wrote: > > > tOn Mon, Nov 23, 2020 at 01:53:01PM +0100, Solene Rapenne wrote: > > > > > > > A common mistake when using dd is to create a file in /dev which > > > > fills up the space of / and may stay silent until / gets filled up > > > > by something else that will fail. > > > > > > > > Would it be OK to add this in /etc/daily? > > > > > > > > find /dev -type f ! -name MAKEDEV -delete > > > > > > > > AFAIK /dev should have only MAKEDEV as a regular file. > > > > hier(7) says /dev only have block and character devices > > > > with the exception of MAKEDEV. > > > > > > > > > > reporting is good, but deleting not. > > > > > > -Otto > > > > ^^ > > > > I like this option a lot more, as users will get an opportunity to > > learn. > > I don't object to reporting (I do object to automatically deleting), > but realistically for many people who would make this mistake, the > daily mails are just going to build up unread in /var/mail/$USER... > That's exactly why I thought removing them was better than reporting. The disk usage is already reported daily. With the script being run during night, this would also only be useful for workstation that stay online at the time the script is run. In conclusion, it was a bad idea.
clean /dev from /etc/daily ?
A common mistake when using dd is to create a file in /dev which fills up the space of / and may stay silent until / gets filled up by something else that will fail. Would it be OK to add this in /etc/daily? find /dev -type f ! -name MAKEDEV -delete AFAIK /dev should have only MAKEDEV as a regular file. hier(7) says /dev only have block and character devices with the exception of MAKEDEV.
acme-client(1) make -F flag use more obvious
This is a small change to acme-client(1) because I find the explanation of -F flag not being obvious that you need it when you add/remove an alternative name in your domain config. Maybe wording could be better, if a native English speaker could give it a look. ok? Index: acme-client.1 === RCS file: /home/reposync/src/usr.sbin/acme-client/acme-client.1,v retrieving revision 1.36 diff -u -p -r1.36 acme-client.1 --- acme-client.1 4 Nov 2020 10:34:18 - 1.36 +++ acme-client.1 15 Dec 2020 09:14:07 - @@ -68,6 +68,9 @@ The options are as follows: .Bl -tag -width Ds .It Fl F Force certificate renewal, even if it's too soon. +This is required if the domain alternatives names changed +in +.Xr acme-client.conf 5 . .It Fl f Ar configfile Specify an alternative configuration file. .It Fl n
Re: acme-client(1) make -F flag use more obvious
On Tue, 15 Dec 2020 10:18:41 +0100 Solene Rapenne : > This is a small change to acme-client(1) because I find > the explanation of -F flag not being obvious that you > need it when you add/remove an alternative name in your > domain config. > > Maybe wording could be better, if a native English > speaker could give it a look. > > ok? > I added 's to domain and specified -F only works for new domains. While there, I propose to change the proposed crontab to once a day instead of every hour. The certificates can be renewed 1 full month before expiracy, I think trying to renew every hour is too much. Index: acme-client.1 === RCS file: /home/reposync/src/usr.sbin/acme-client/acme-client.1,v retrieving revision 1.36 diff -u -p -r1.36 acme-client.1 --- acme-client.1 4 Nov 2020 10:34:18 - 1.36 +++ acme-client.1 16 Dec 2020 08:42:36 - @@ -68,6 +68,9 @@ The options are as follows: .Bl -tag -width Ds .It Fl F Force certificate renewal, even if it's too soon. +This is required if new domain's alternatives names +were added to +.Xr acme-client.conf 5 . .It Fl f Ar configfile Specify an alternative configuration file. .It Fl n @@ -123,7 +126,7 @@ On renewal, .Xr httpd 8 is reloaded: .Bd -literal -offset indent -~ * * * * acme-client example.com && \e +~ ~ * * * acme-client example.com && \e rcctl reload httpd .Ed .Sh SEE ALSO
Re: Wireguard - VPN up after reboot
On Tue, 22 Dec 2020 09:50:04 + "Salvatore Cuzzilla" : > Hi Everyone, > > I'm happily using 'Wireguard' to setup few VPNs. > I store the required configuration within /etc/hostname.wg0 & I startup the > tunnel with 'doas sh > /etc/netstart wg0'. > > Everything is working like expected. > However, upon system reload the connectivity is lost. > The wg0 interface comes up but the tunnel stays in a sort of 'waiting' > state. > > The only way I figure out to bring it up is either re-launching 'doas sh > /etc/netstart wg0' or > pinging the tunnel default gateway. > > Is there any decent/clean way to avoid manual intervention? > > --- > :wq, > Salvatore. > I had the same issue, you must avoid using hostname for the remote address of the wireguard peer, because at this stage you can't resolve hostnames.
Re: AUDIORECDEVICE environment variable in sndio lib
On Tue, 17 Nov 2020 17:13:49 +0100 "Peter J. Philipp" : > Hi, > > I have a mic on snd/1 and speakers on snd/0. I had tried a lot of different > settings with audacity port but couldn't get this to work, so I chose the > method of last resort. Below is a patch to allow an AUDIORECDEVICE > environment > variable specifying the wanted microphone. > > -peter I have no opinion about the diff itself, but this would require a man page update that I propose myself to write if the diff is OK. It works fine for me, I've been able to use my DAC and my usb microphone in audacity. It was something that I wanted to be able to do since long time and I'm very happy to see it possible.
Re: AUDIORECDEVICE environment variable in sndio lib
On Tue, 17 Nov 2020 18:23:55 +0100 "Peter J. Philipp" : > This is a good suggestion! Thanks! I have updated the patch. I also > appreciate Solene's offer for manpage addition, thanks! > > New diff follows... let me know if it can be done better, I won't be able > to update it until tomorrow. > > -peter I suggest this change. I added the new variable after MIDIDEVICE in the ENVIRONMENT section to keep order of appearance in the document. Index: sndio.7 === RCS file: /home/reposync/src/lib/libsndio/sndio.7,v retrieving revision 1.24 diff -u -p -r1.24 sndio.7 --- sndio.7 18 Jul 2020 05:01:14 - 1.24 +++ sndio.7 17 Nov 2020 18:32:34 - @@ -157,6 +157,10 @@ If it is not set, the program first trie .Li snd/0 . If that fails, it then tries to use .Li rsnd/0 . +The +.Ev AUDIORECDEVICE +environment variable +defines a device to use prior to the audio device when recording. .Pp Similarly, if no MIDI descriptor is provided to a program or when the reserved word @@ -196,6 +200,9 @@ Audio device descriptor to use when no descriptor is explicitly specified to a program. .It Ev MIDIDEVICE MIDI port descriptor to use +when no descriptor is explicitly specified to a program. +.It Ev AUDIORECDEVICE +Audio recording device descriptor to use when no descriptor is explicitly specified to a program. .El .Pp
accton(8) requires a reboot after being enabled
reading accton(8) it's not clear that if you enable it you need to restart the system for accounting to be effective. Here is a change to add the explanation, but I'm not sure if the wording is correct. Index: accton.8 === RCS file: /home/reposync/src/usr.sbin/accton/accton.8,v retrieving revision 1.11 diff -u -p -r1.11 accton.8 --- accton.810 Nov 2019 20:51:53 - 1.11 +++ accton.830 Oct 2020 15:22:14 - @@ -43,6 +43,10 @@ causes system accounting information for to be placed at the end of the file. If no argument is given, accounting is turned off. .Pp +Accounting is done if it was enabled when system booted. +If you activate accounting, a reboot is required for it to become +effective. +.Pp To have .Nm enabled at boot time, use
Re: accton(8) requires a reboot after being enabled
Following diff changes accton(8) behavior.
If the file given as parameter doesn't exists, accton will create it.
Then it will check the ownership and will make it root:wheel if
it's different.
I added a check to be sure it's run as root because it's has no use if
not run as root.
I don't often write C, if the logic is good but the C implementation
wrong I'm open to critic.
The -f test and touch in /etc/rc won't be needed anymore with this
change.
Index: accton.8
===
RCS file: /home/reposync/src/usr.sbin/accton/accton.8,v
retrieving revision 1.11
diff -u -p -r1.11 accton.8
--- accton.810 Nov 2019 20:51:53 - 1.11
+++ accton.830 Oct 2020 17:27:36 -
@@ -36,7 +36,7 @@
.Nm accton
.Op Ar file
.Sh DESCRIPTION
-With an argument naming an existing
+With an argument naming a
.Ar file ,
.Nm
causes system accounting information for every process executed
Index: accton.c
===
RCS file: /home/reposync/src/usr.sbin/accton/accton.c,v
retrieving revision 1.8
diff -u -p -r1.8 accton.c
--- accton.c27 Oct 2009 23:59:50 - 1.8
+++ accton.c30 Oct 2020 17:26:31 -
@@ -27,6 +27,7 @@
* SUCH DAMAGE.
*/
+#include
#include
#include
#include
@@ -47,6 +48,10 @@ int
main(int argc, char *argv[])
{
int ch;
+ struct stat info_file;
+
+ if(getuid() != 0)
+ err(1, "need root privileges");
while ((ch = getopt(argc, argv, "")) != -1)
switch(ch) {
@@ -63,6 +68,15 @@ main(int argc, char *argv[])
err(1, NULL);
break;
case 1:
+ if(stat(*argv,_file) != 0)
+ if(fopen(*argv,"w"))
+ if(stat(*argv,_file))
+ err(1, "file %s couldn't be created",
*argv);
+
+ if (info_file.st_uid != 0 || info_file.st_gid != 0)
+ if(chown(*argv, 0, 0) != 0)
+ err(1, "Impossible to fix %s ownership", *argv);
+
if (acct(*argv))
err(1, "%s", *argv);
break;
Re: veb(4) support for vmd(8)?
On Fri, 26 Feb 2021 22:50:29 +0100 Klemens Nanni : > On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wrote: > > i think this is enough to let vmd wire guests up to veb interfaces. > But please update vm.conf(5) to mention veb(4) and vport(4) in as well > SWITCH CONFIGURATION. > > OK kn > The virtualization FAQ could be updated too when 6.9 is released if bridge should be replaced with veb.
add reference to veb(4) in ifconfig.8
For the create command in ifconfig, many pseudo devices are listed but the recent veb(4) is not present in the list. ok? Index: ifconfig.8 === RCS file: /home/reposync/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.373 diff -u -p -r1.373 ifconfig.8 --- ifconfig.8 17 Apr 2021 06:01:49 - 1.373 +++ ifconfig.8 16 Aug 2021 16:37:45 - @@ -206,6 +206,7 @@ At least the following devices can be cr .Xr tpmr 4 , .Xr trunk 4 , .Xr tun 4 , +.Xr veb 4 , .Xr vether 4 , .Xr vlan 4 , .Xr vxlan 4 ,
pf.conf(5) about queueing may be wrong
pf.conf says this in QUEUEING https://man.openbsd.org/pf.conf#QUEUEING > If the referenced queue does not exist on the outgoing interface, > the default queue for that interface is used. however, with this simple config queue std on re0 bandwidth 100M queue lan parent std bandwidth 100M queue internet parent std bandwidth 900K flows 512 default match proto udp from em0:network to any port 53 queue dns when reloading the file with pfctl, I get the following error: /etc/pf.conf:27: queue dns is not defined From the man page, I understand that if the queue used in match doesn't exist, the default queue is used, as if "queue dns" wasn't written in the rule. Either the man page is wrong or not easy to understand, or the parser is wrong.
RFC: performance oriented CPU frequency scaling
hello,
this is not actually a proposal for a commit but I'm playing with the
frequency scaling code (that's the only part of the kernel I touched once
and it's relatively simple and fun to work on).
I found in some cases that using the automatic scaling mode would produce
poor results because the software required is at the threshold triggering
the speed up and would give poor performance.
The following change changes the automatic mode with a more performance
oriented strategy.
I made two changes:
- instead of keeping the speed up for 5 cycles of 100ms, keep it
10 times which is 1 second instead of 500ms. This makes programs
such as libreoffice more responsive for me.
- instead of waiting to use 50% of all cores without triggering the
other condition that is 70% use of a single core, speed up when the
sum of used CPU time reach 1 CPU across n CPU. This condition
triggers the speed up a lot more often than the current condition.
I initially thought about reducing the checks to 200 or 300ms, but
a given workload doesn't mean it will stay long, we need to check
often to reduce the load when needed. I also gave a thought about
involved the system load into this but I couldn't figure a simple
case of it being meaningful. If the load rises, we certainly need
high frequency, but then we would be stuck with it for too long
time.
I share this and will continue playing with the code, but if some
people try it and find it to be useful, maybe we could think about
different automatic modes like there are on other OSs? I'm thinking
about powersave / performance modes. When using my laptop on
battery, I will certainly prefer running the current code, but when
connected to power, an automatic mode that provides more performance
would make sense instead of switching to full performance and wasting
electricity.
I use a simple way to visualize the CPU frequency over time with
ttyplot to draw a chart in a terminal.
{ while :; do sysctl -n hw.setperf ; sleep 1 ; done } | awk '{ print $1 ;
fflush }' | ttyplot -t "CPU frequency in %"
Index: sched_bsd.c
===
RCS file: /home/reposync/src/sys/kern/sched_bsd.c,v
retrieving revision 1.69
diff -u -p -r1.69 sched_bsd.c
--- sched_bsd.c 9 Sep 2021 18:41:39 - 1.69
+++ sched_bsd.c 11 Sep 2021 12:55:42 -
@@ -582,6 +582,7 @@ setperf_auto(void *v)
}
total -= totalticks[j];
idle = ci->ci_schedstate.spc_cp_time[CP_IDLE] - idleticks[j];
+ // speedup if at least one core idle time < 33%
if (idle < total / 3)
speedup = 1;
alltotal += total;
@@ -590,10 +591,13 @@ setperf_auto(void *v)
totalticks[j] += total;
j++;
}
- if (allidle < alltotal / 2)
+ // speedup if at least N-1 CPU is used in the result of the sum of the
usage
+ // when one CPU this condition will never be met but it's OK
+ if (allidle < alltotal * (j-1) / j)
speedup = 1;
+ // keep the speed up 10 for at least 10 checks
if (speedup)
- downbeats = 5;
+ downbeats = 10;
if (speedup && perflevel != 100) {
perflevel = 100;
@@ -603,6 +607,7 @@ setperf_auto(void *v)
cpu_setperf(perflevel);
}
+ // one check occurs every 100ms
timeout_add_msec(_to, 100);
}
Alternate cpu policy on battery
Last time I proposed a CPU frequency scheduling change to make it
more performance oriented, however this would hurt badly the battery
life for nomad users.
As we don't like tweaks and complicated settings, I create a new
CPU frequency policy that is oriented for nomad users, it reduces
performance a bit but from my (short) experiments it would give a
way better battery life while keeping the system responsive which
is not allowing apm -L
The current auto mode is kept as it is now and I added a new
powersaving mode that will be triggered automatically by apmd when
the system is on battery AND automatic mode is activated.
So, on A/C you have the usual automatic policy and on battery it
would switch on the new powersaving policy.
I hope this could be useful for nomad people and later we could
tune the automatic mode (to be used on A/C) to be giving more
performance, without affecting people on battery.
The code change is relatively simple, I'm pretty sure this can be
improved but I wanted to share it as this for now so people can
comment and/or try it out.
I created a new policy which is basically a copy/paste of the current
one with a different name and differents thresholds, declared it
in apmd. There is another change in apmd to check on event if we
are using the policy auto and if on battery or not, this takes care
of changing the policy automatically. I'm not sure it's at the right
place. As for the code in the kernel, I'm quite sure it could be
merged into one and use different thresholds depending on the policy
name currently in use.
Kernel + usr.sbin/apmd + usr.sbin/apm recompilation required
Index: sys/kern//sched_bsd.c
===
RCS file: /home/reposync/src/sys/kern/sched_bsd.c,v
retrieving revision 1.69
diff -u -p -r1.69 sched_bsd.c
--- sys/kern//sched_bsd.c 9 Sep 2021 18:41:39 - 1.69
+++ sys/kern//sched_bsd.c 25 Sep 2021 18:09:40 -
@@ -531,6 +531,7 @@ void (*cpu_setperf)(int);
#define PERFPOL_MANUAL 0
#define PERFPOL_AUTO 1
#define PERFPOL_HIGH 2
+#define PERFPOL_POWERSAVING 4
int perflevel = 100;
int perfpolicy = PERFPOL_MANUAL;
@@ -541,7 +542,9 @@ int perfpolicy = PERFPOL_MANUAL;
#include
void setperf_auto(void *);
+void setperf_powersaving(void *);
struct timeout setperf_to = TIMEOUT_INITIALIZER(setperf_auto, NULL);
+struct timeout setperf_to_powersaving =
TIMEOUT_INITIALIZER(setperf_powersaving, NULL);
void
setperf_auto(void *v)
@@ -606,6 +609,73 @@ setperf_auto(void *v)
timeout_add_msec(_to, 100);
}
+void
+setperf_powersaving(void *v)
+{
+ static uint64_t *idleticks, *totalticks;
+ static int downbeats;
+
+ int i, j;
+ int speedup;
+ CPU_INFO_ITERATOR cii;
+ struct cpu_info *ci;
+ uint64_t idle, total, allidle, alltotal;
+
+ if (perfpolicy != PERFPOL_POWERSAVING)
+ return;
+
+ if (!idleticks)
+ if (!(idleticks = mallocarray(ncpusfound, sizeof(*idleticks),
+ M_DEVBUF, M_NOWAIT | M_ZERO)))
+ return;
+ if (!totalticks)
+ if (!(totalticks = mallocarray(ncpusfound, sizeof(*totalticks),
+ M_DEVBUF, M_NOWAIT | M_ZERO))) {
+ free(idleticks, M_DEVBUF,
+ sizeof(*idleticks) * ncpusfound);
+ return;
+ }
+
+ alltotal = allidle = 0;
+ j = 0;
+ speedup = 0;
+ CPU_INFO_FOREACH(cii, ci) {
+ if (!cpu_is_online(ci))
+ continue;
+ total = 0;
+ for (i = 0; i < CPUSTATES; i++) {
+ total += ci->ci_schedstate.spc_cp_time[i];
+ }
+ total -= totalticks[j];
+ idle = ci->ci_schedstate.spc_cp_time[CP_IDLE] - idleticks[j];
+ // speedup if at least one core idle time < 33%
+ if (idle < total / 3)
+ speedup = 1;
+ alltotal += total;
+ allidle += idle;
+ idleticks[j] += idle;
+ totalticks[j] += total;
+ j++;
+ }
+ if (allidle < alltotal / 3)
+ speedup = 1;
+ if (speedup)
+ /* twice as long here because we check every 200ms */
+ downbeats = 1;
+
+ if (speedup && perflevel != 100) {
+ perflevel = 100;
+ cpu_setperf(perflevel);
+ } else if (!speedup && perflevel != 0 && --downbeats <= 0) {
+ perflevel = 0;
+ cpu_setperf(perflevel);
+ }
+
+/* every 200ms to have a better resolution of the load */
+ timeout_add_msec(_to_powersaving, 200);
+}
+
+
int
sysctl_hwsetperf(void *oldp, size_t *oldlenp, void *newp, size_t newlen)
{
@@ -644,6 +714,9 @@ sysctl_hwperfpolicy(void *oldp, size_t *
case PERFPOL_AUTO:
strlcpy(policy, "auto",
Remove deprecated variables in sysctl(2)
Variables HW_PHYSMEM and HW_USERMEM were deprecated 13 years ago, maybe we can remove them from sysctl(2)? It was originally in sysctl(3) if someone want to do some history research https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/Attic/sysctl.3#rev1.178 Index: sysctl.2 === RCS file: /home/reposync/src/lib/libc/sys/sysctl.2,v retrieving revision 1.44 diff -u -p -r1.44 sysctl.2 --- sysctl.218 May 2021 05:26:26 - 1.44 +++ sysctl.25 Oct 2021 16:03:28 - @@ -289,13 +289,11 @@ privileges may change the value. .It Dv HW_NCPUONLINE Ta "integer" Ta "no" .It Dv HW_PAGESIZE Ta "integer" Ta "no" .It Dv HW_PERFPOLICY Ta "string" Ta "yes" -.It Dv HW_PHYSMEM Ta "integer" Ta "no" .It Dv HW_PHYSMEM64 Ta "int64_t" Ta "no" .It Dv HW_PRODUCT Ta "string" Ta "no" .It Dv HW_SENSORS Ta "node" Ta "not applicable" .It Dv HW_SETPERF Ta "integer" Ta "yes" .It Dv HW_SMT Ta "integer" Ta "yes" -.It Dv HW_USERMEM Ta "integer" Ta "no" .It Dv HW_USERMEM64 Ta "int64_t" Ta "no" .It Dv HW_UUID Ta "string" Ta "no" .It Dv HW_VENDOR Ta "string" Ta "no" @@ -343,11 +341,6 @@ Can be one of .Dq auto , or .Dq high . -.It Dv HW_PHYSMEM -The total physical memory, in bytes. -This variable is deprecated; use -.Dv HW_PHYSMEM64 -instead. .It Dv HW_PHYSMEM64 Pq Va hw.physmem The total physical memory, in bytes. .It Dv HW_PRODUCT Pq Va hw.product @@ -393,11 +386,6 @@ is set to If set to 1, enable simultaneous multithreading (SMT) on CPUs that support it. Disabled by default. -.It Dv HW_USERMEM -The amount of available non-kernel memory in bytes. -This variable is deprecated; use -.Dv HW_USERMEM64 -instead. .It Dv HW_USERMEM64 Pq Va hw.usermem The amount of available non-kernel memory in bytes. .It Dv HW_UUID Pq Va hw.uuid
Re: demystify vport(4) in vport(4) and ifconfig(8)
On Wed, 27 Oct 2021 14:32:31 +0100 Jason McIntyre : > On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote: > > On 2021/10/27 17:44, David Gwynne wrote: > > > > > > > benno@ suggested I look at vether(4) to adapt the text related to > > > > bridge(4) but I'm not sure how to rewrite it properly for veb(4). > > > > > > i get that, but for a different reason. im too close to veb/vport, so i > > > think it's all very obvious. > > > > > > maybe we could split the first paragraph into separate ones for veb > > > and vport, and flesh them out a bit. what is it about vport that > > > needs to be said? > > > > I'm not so close to veb/vport (and haven't run into a situation to use > > it yet, though maybe I'll give it a try converting an etherip/ipsec > > bridge that I have). I think it's pretty obvious too, though I think > > people aren't grasping what "the network stack can be connected" means, > > would the diff below help? it feels a bit more like spelling things out > > than is usual for a manual page but maybe that's needed here. > > > > for ifconfig I would be in favour of _not_ listing all the possible > > cloneable interface types that can be used with create, it's just another > > thing to get out of sync - maybe just a few of the common ones and tell > > the reader about ifconfig -C at that point.. "ifconfig create" barely > > seems necessary except possibly for tun/tap - for most interface types > > you are going to run another ifconfig command (like "ifconfig veb0 add > > em0") which creates the interface automatically anyway. > > > > hi. > > i agree with staurt about "create": this list was once short and made > sense. now it just keeps going out of date, without providing any help > to the reader. i don;t want to stack diff on diff, but maybe once the > veb stuff is sorted i will zap the create list. > > that strategy does rely on individual driver docs saying upfront that > they can be created though, even if using create is not common. i wonder if > ifconfig already knows what it can create, and could maybe be more > helpful if "create" without an ifname gave a hint. > > anyway, to that end i'm ok with solene's diff. > I agree about ifconfig(8), if it's incomplete this is more misleading than helping, and hints in the devices man pages about using ifconfig/hostname.if are a very helpful and won't rot.
demystify vport(4) in vport(4) and ifconfigt(8)
I tried to figure out how to use veb interfaces but the man page wasn't obvious in regards to the "vport" thing. It turns out it's a kind of interface that can be created with ifconfig. I think we should make this clearer. Because ifconfig(8) mentions many type of interfaces I've searched for "vport" without success while "most" types are referenced in the man page. Like I added veb(4) recently, the diff adds vport(4) and missing mpip(4) so a search would give a clue it's related to ifconfig. in veb(4), I think we should add vport in the synposis because the man page is shared for veb and vport interfaces but at first look it seems only veb is a type of interface. And finally, I added a mention that vport can be created with ifconfig(8) so it's really obvious. Maybe it's too much and can be removed. comments? ok? Index: share/man/man4//veb.4 === RCS file: /home/reposync/src/share/man/man4/veb.4,v retrieving revision 1.2 diff -u -p -r1.2 veb.4 --- share/man/man4//veb.4 23 Feb 2021 11:43:41 - 1.2 +++ share/man/man4//veb.4 26 Oct 2021 19:10:17 - @@ -23,6 +23,7 @@ .Nd Virtual Ethernet Bridge network device .Sh SYNOPSIS .Cd "pseudo-device veb" +.Cd "pseudo-device vport" .Sh DESCRIPTION The .Nm veb @@ -37,7 +38,9 @@ by .Nm veb by creating a .Nm vport -interface and attaching it as a port to the bridge. +interface using +.Xr ifconfig 8 +and attaching it as a port to the bridge. From the perspective of the host network stack, a .Nm vport interface acts as a normal interface connected to an Ethernet Index: sbin/ifconfig//ifconfig.8 === RCS file: /home/reposync/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.375 diff -u -p -r1.375 ifconfig.8 --- sbin/ifconfig//ifconfig.8 18 Aug 2021 18:10:33 - 1.375 +++ sbin/ifconfig//ifconfig.8 26 Oct 2021 19:13:27 - @@ -192,6 +192,7 @@ At least the following devices can be cr .Xr lo 4 , .Xr mgre 4 , .Xr mpe 4 , +.Xr mpip 4 , .Xr mpw 4 , .Xr nvgre 4 , .Xr pair 4 , @@ -209,6 +210,7 @@ At least the following devices can be cr .Xr veb 4 , .Xr vether 4 , .Xr vlan 4 , +.Xr vport 4 , .Xr vxlan 4 , .Xr wg 4 .It Cm debug
Re: demystify vport(4) in vport(4) and ifconfig(8)
On Wed, 27 Oct 2021 07:28:32 +1000 David Gwynne : > On Tue, Oct 26, 2021 at 09:18:30PM +0200, Solene Rapenne wrote: > > I tried to figure out how to use veb interfaces but the man page > > wasn't obvious in regards to the "vport" thing. It turns out it's > > a kind of interface that can be created with ifconfig. > > > > I think we should make this clearer. > > agreed. the man page for veb/vport is definitely not... rigorous. > > > Because ifconfig(8) mentions many type of interfaces I've searched > > for "vport" without success while "most" types are referenced in > > the man page. Like I added veb(4) recently, the diff adds vport(4) > > and missing mpip(4) so a search would give a clue it's related to > > ifconfig. > > I'm ok with the ifconfig chunk. > > > in veb(4), I think we should add vport in the synposis because the > > man page is shared for veb and vport interfaces but at first look > > it seems only veb is a type of interface. > > The synopsis shows what you put into a kernel config file (eg > src/sys/conf/GENERIC) to enable the driver, but "pseudo-device > vport" is not valid kernel config. You enable the veb driver and that > one driver provides both veb and vport interfaces. Another example of > this is the gre driver which provides gre, egre, mgre, nvgre, and eoip > interfaces. > > > And finally, I added a mention that vport can be created with > > ifconfig(8) so it's really obvious. Maybe it's too much and can be > > removed. > > It should definitely be said. The other man pages for clonable > interfaces generally have a paragraph like this: > > .Nm gre , > .Nm mgre , > .Nm egre , > and > .Nm nvgre > interfaces can be created at runtime using the > .Ic ifconfig iface Ns Ar N Ic create > command or by setting up a > .Xr hostname.if 5 > configuration file for > .Xr netstart 8 . > > I just noticed vether.4 is also missing a paragraph like that too :( > > > comments? ok? > > Apart from it not being obvious where vport interfaces come from, is > there anything else not obvious about veb? > veb is fine to me, here is a diff that adds the ifconfig paragraph to veb(4) and vether(4), I removed my first change from veb. benno@ suggested I look at vether(4) to adapt the text related to bridge(4) but I'm not sure how to rewrite it properly for veb(4). Index: share/man/man4//veb.4 === RCS file: /home/reposync/src/share/man/man4/veb.4,v retrieving revision 1.2 diff -u -p -r1.2 veb.4 --- share/man/man4//veb.4 23 Feb 2021 11:43:41 - 1.2 +++ share/man/man4//veb.4 27 Oct 2021 06:28:45 - @@ -43,6 +43,17 @@ From the perspective of the host network interface acts as a normal interface connected to an Ethernet network. .Pp +A +.Nm veb +or +.Nm vport +interface can be created at runtime using the +.Ic ifconfig iface Ns Ar N Ic create +command or by setting up a +.Xr hostname.if 5 +configuration file for +.Xr netstart 8 . +.Pp .Nm veb is a learning bridge that maintains a table of Ethernet addresses and the port that each address is reachable with. Index: share/man/man4//vether.4 === RCS file: /home/reposync/src/share/man/man4/vether.4,v retrieving revision 1.5 diff -u -p -r1.5 vether.4 --- share/man/man4//vether.417 Oct 2017 22:47:58 - 1.5 +++ share/man/man4//vether.427 Oct 2021 06:29:54 - @@ -30,6 +30,15 @@ standard network frames with an Ethernet for use as a member in a .Xr bridge 4 . .Pp +A +.Nm +interface can be created at runtime using the +.Ic ifconfig vether Ns Ar N Ic create +command or by setting up a +.Xr hostname.if 5 +configuration file for +.Xr netstart 8 . +.Pp To use .Nm the administrator needs to configure an address onto the interface
issue with login.conf(5) rtable and su -l user
Hi, I'm playing with the new rtable feature in login.conf(5) but it seems one use case doesn't trigger the rtable change. I have an user called alice, if I ssh locally from my user to alice with ssh alice@localhost, alice has the correct routing table, if I use as root "su -l alice", then alice seems using rtable 0. I have two rules in pf.conf to forbid alice to reach the internet, so when I want to try if it works, I simply run "dig openbsd.org @9.9.9.9", if it works, I'm using rtable 1 (openvpn), if not, it's using rtable 0. block return on rdomain 0 proto tcp user alice block return on rdomain 0 proto udp user alice I think my configuration is fine. file /etc/master.passwd: alice:*:1007:1007:alice:0:0:,,,:/home/alice:/bin/ksh file /etc/login.conf: alice:\ :rtable=1:
Re: add -k / --keep for gzip(1)
On Sat, 05 Mar 2022 19:15:02 -0700
"Todd C. Miller" :
> On Sun, 06 Mar 2022 02:58:30 +0100, Jeremie Courreges-Anglas wrote:
>
> > I'm not sure what you mean here. Solene's diff added -k to both
> > compress(1) and gzip(1) (and their uncompressor counterparts).
> > Adding -k to gzip/gunzip only would indeed make the usage() slightly
> > more complicated.
> >
> > So do we want to add -k to compress(1) or not? (No strong opinion.)
> >
> > I like the general idea and the diff seems to work as intended.
>
> I don't really care whether or not we add -k to compress(1). However,
> since other versions of compress do not have a -k option it is
> probably best to avoiding adding it.
>
> - todd
here is a new version that doesn't add -k to compress and uncompress
gzip -k and gunzip -k works as expected
compress -k and uncompress -k will display unknown option -- k and
show the usage that doesn't show k flag
Index: gzip.1
===
RCS file: /home/reposync/src/usr.bin/compress/gzip.1,v
retrieving revision 1.14
diff -u -p -r1.14 gzip.1
--- gzip.1 7 Oct 2014 21:06:30 - 1.14
+++ gzip.1 3 Mar 2022 12:08:21 -
@@ -43,13 +43,13 @@
.Nd compress and expand data (deflate mode)
.Sh SYNOPSIS
.Nm gzip
-.Op Fl 123456789cdfhLlNnOqrtVv
+.Op Fl 123456789cdfhkLlNnOqrtVv
.Op Fl b Ar bits
.Op Fl o Ar filename
.Op Fl S Ar suffix
.Op Ar
.Nm gunzip
-.Op Fl cfhLlNnqrtVv
+.Op Fl cfhkLlNnqrtVv
.Op Fl o Ar filename
.Op Ar
.Nm gzcat
@@ -183,6 +183,8 @@ behave as
.Xr cat 1 .
.It Fl h
Print a short help message.
+.It Fl k
+Keep input files after compression or decompression.
.It Fl L
A no-op which exists for compatibility only.
On GNU gzip, it displays the program's license.
Index: main.c
===
RCS file: /home/reposync/src/usr.bin/compress/main.c,v
retrieving revision 1.98
diff -u -p -r1.98 main.c
--- main.c 18 Jan 2021 00:46:58 - 1.98
+++ main.c 12 Mar 2022 14:43:18 -
@@ -75,8 +75,8 @@ const struct compressor {
"deflate",
".gz",
"\037\213",
- "123456789ab:cdfhLlNnOo:qrS:tVv",
- "cfhLlNno:qrtVv",
+ "123456789ab:cdfhkLlNnOo:qrS:tVv",
+ "cfhkLlNno:qrtVv",
"fhqr",
gz_ropen,
gz_read,
@@ -93,7 +93,7 @@ const struct compressor {
".Z",
"\037\235",
"123456789ab:cdfghlNnOo:qrS:tv",
- "cfhlNno:qrtv",
+ "cfhklNno:qrtv",
"fghqr",
z_ropen,
zread,
@@ -110,8 +110,8 @@ const struct compressor null_method = {
"null",
".nul",
"XX",
- "123456789ab:cdfghlNnOo:qrS:tv",
- "cfhlNno:qrtv",
+ "123456789ab:cdfghklNnOo:qrS:tv",
+ "cfhklNno:qrtv",
"fghqr",
null_ropen,
null_read,
@@ -141,6 +141,7 @@ const struct option longopts[] = {
{ "uncompress", no_argument,0, 'd' },
{ "force", no_argument,0, 'f' },
{ "help", no_argument,0, 'h' },
+ { "keep", no_argument,0, 'k' },
{ "list", no_argument,0, 'l' },
{ "license",no_argument,0, 'L' },
{ "no-name",no_argument,0, 'n' },
@@ -166,12 +167,12 @@ main(int argc, char *argv[])
const char *optstr, *s;
char *p, *infile;
char outfile[PATH_MAX], _infile[PATH_MAX], suffix[16];
- int bits, ch, error, rc, cflag, oflag;
+ int bits, ch, error, rc, cflag, oflag, kflag;
if (pledge("stdio rpath wpath cpath fattr chown", NULL) == -1)
err(1, "pledge");
- bits = cflag = oflag = 0;
+ bits = cflag = oflag = kflag = 0;
storename = -1;
p = __progname;
if (p[0] == 'g') {
@@ -276,6 +277,9 @@ main(int argc, char *argv[])
strlcpy(suffix, method->suffix, sizeof(suffix));
bits = 6;
break;
+ case 'k':
+ kflag = 1;
+ break;
case 'l':
list++;
testmode = 1;
@@ -459,7 +463,7 @@ main(int argc, char *argv[])
switch (error) {
case SUCCESS:
if (!cat && !testmode) {
- if (!pipin && unlink(infile) && verbose >= 0)
+ if (!pipin && !kflag && unlink(infile) &&
verbose >= 0)
warn("input: %s", infile);
}
break;
