tree.h: returning void, legal but weird

2020-10-10 Thread Otto Moerbeek
OK? -Otto Index: tree.h === RCS file: /cvs/src/sys/sys/tree.h,v retrieving revision 1.29 diff -u -p -r1.29 tree.h --- tree.h 30 Jul 2017 19:27:20 - 1.29 +++ tree.h 10 Oct 2020 16:36:15 - @@ -910,25

Re: random canary bytes for malloc

2020-10-04 Thread Otto Moerbeek
On Tue, Sep 29, 2020 at 08:17:54AM +0200, Otto Moerbeek wrote: > Hi, > > until now, canary bytes (used by the C olption) were the same as the > bytes used to junk (0xfd). This means that certain overwrites are not > detected, like setting the high bit. > > This make

dump: better handling of large filesystems

2020-09-29 Thread Otto Moerbeek
Hi, this fixes an overwrite of spcl.c_addr. Taken form FreeBSD. See https://marc.info/?l=openbsd-misc=160018252418088=2 -Otto Index: tape.c === RCS file: /cvs/src/sbin/dump/tape.c,v retrieving revision 1.45 diff -u -p

random canary bytes for malloc

2020-09-29 Thread Otto Moerbeek
Hi, until now, canary bytes (used by the C olption) were the same as the bytes used to junk (0xfd). This means that certain overwrites are not detected, like setting the high bit. This makes the byte value used to write canaries random. I do not want to complicate the code to handle all

Re: btrace: add boolean AND and OR operators

2020-09-14 Thread Otto Moerbeek
On Mon, Sep 14, 2020 at 03:28:17PM +0200, Jasper Lievisse Adriaanse wrote: > Hi, > > This diff adds support for the '&' and '|' operators, along with > a new testcase. > > OK? The precedence looks funny I'd guess you want %left '|' %left '&' %left '+' '-' %left '/' '*' To avoid suprises.

Re: asn1/a_bitstring.c: zeroing after recallocarray

2020-09-02 Thread Otto Moerbeek
On Thu, Sep 03, 2020 at 07:03:14AM +0200, Theo Buehler wrote: > The memset is not needed as recallocarray(3) does the zeroing already. > (I also think the a->data == NULL check in the if clause is redundant, > but I'm just suggesting to remove a bit that confused me) ok, -Otto > >

Re: shrinking and growing reallocs: a theoretical? bad case for performance

2020-09-02 Thread Otto Moerbeek
On Tue, Sep 01, 2020 at 11:56:36AM +0100, Stuart Henderson wrote: > On 2020/08/31 08:39, Otto Moerbeek wrote: > > A question from Theo made me think about realloc and come up with a > > particular bad case for performance. I do not know if it happens in > > practice, but

Re: shrinking and growing reallocs: a theoretical? bad case for performance

2020-08-31 Thread Otto Moerbeek
On Mon, Aug 31, 2020 at 11:25:51AM -0600, Theo de Raadt wrote: > > Taking advantage of the sparse address space is smart and as 64-bit > > is now the norm, that space is even sparser. > > Fundamentally this is moving various forms of pressure to the kernel, > which does not do the best job yet.

Re: shrinking and growing reallocs: a theoretical? bad case for performance

2020-08-31 Thread Otto Moerbeek
On Mon, Aug 31, 2020 at 08:28:25AM -0400, David Higgs wrote: > On Mon, Aug 31, 2020 at 2:41 AM Otto Moerbeek wrote: > > > Hi, > > > > A question from Theo made me think about realloc and come up with a > > particular bad case for performance. I do not know

shrinking and growing reallocs: a theoretical? bad case for performance

2020-08-31 Thread Otto Moerbeek
Hi, A question from Theo made me think about realloc and come up with a particular bad case for performance. I do not know if it happens in practice, but it was easy to create a test program to hit the case. We're talking allocation >= a page here. Smaller allocation follow different rules. If

Re: ntpd: go into unsynced mode

2020-08-30 Thread Otto Moerbeek
On Sat, Aug 22, 2020 at 03:51:48PM +0200, Otto Moerbeek wrote: > Hi, > > At the moment ntpd never goes into unsynced mode if network > connectivity is lost. The code to do that is only triggered when a > pakcet is received, which does not happen. > > This diff fixes that b

Re: ntpd: go into unsynced mode

2020-08-25 Thread Otto Moerbeek
On Tue, Aug 25, 2020 at 07:05:31PM +0200, Matthias Schmidt wrote: > Hi Otto, > > * Otto Moerbeek wrote: > > Hi, > > > > At the moment ntpd never goes into unsynced mode if network > > connectivity is lost. The code to do that is only triggered when a &

ntpd: go into unsynced mode

2020-08-22 Thread Otto Moerbeek
Hi, At the moment ntpd never goes into unsynced mode if network connectivity is lost. The code to do that is only triggered when a pakcet is received, which does not happen. This diff fixes that by going into unsynced mode if no time data was processed for a while. An earlier version of this

Re: adjtime(2): distribute skew along arbitrary runtime period

2020-07-16 Thread Otto Moerbeek
On Wed, Jul 15, 2020 at 09:08:29AM -0500, Scott Cheloha wrote: > Hi, > > adjtime(2) skews the clock at up to 5000ppm per second. The way this > actually happens is pretty straightforward: at the start of every UTC > second we call ntp_update_second() from tc_windup() and reset > th_adjustment.

Re: fsck_ffs: faster with lots of cylinder groups

2020-07-12 Thread Otto Moerbeek
On Sun, Jul 12, 2020 at 11:07:05AM +0200, Solene Rapenne wrote: > 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 Moerb

Re: fsck_ffs: faster with lots of cylinder groups

2020-07-12 Thread 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 i

Re: Undefined Behavior at jsmn.c

2020-07-12 Thread Otto Moerbeek
On Sun, Jul 12, 2020 at 09:57:02AM +0430, Ali Farzanrad wrote: > Hi @tech, > > I was comparing jsmn.c in acme-client with jsmn.c in FreeBSD [1]. > I found a switch without a default case which is an undefined behavior: > > @@ -69,6 +69,8 @@ > case '\t' : case '\r' : case

Re: adjfreq(2): limit adjustment to prevent overflow during tc_windup()

2020-07-03 Thread Otto Moerbeek
On Thu, Jul 02, 2020 at 08:27:58PM -0500, Scott Cheloha wrote: > Hi, > > When we recompute the scaling factor during tc_windup() there is an > opportunity for arithmetic overflow/underflow when we add the NTP > adjustment into the scale: > >649 scale = (u_int64_t)1 << 63; >650

Re: fsck_ffs: faster with lots of cylinder groups

2020-06-29 Thread Otto Moerbeek
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 > >

Re: obsd 6.7 - ntpd error msg

2020-06-22 Thread Otto Moerbeek
On Thu, Jun 18, 2020 at 11:41:17AM +0200, Otto Moerbeek wrote: > On Thu, Jun 18, 2020 at 09:57:34AM +0200, Salvatore Cuzzilla wrote: > > > Perfect, tnx! > > > > On 18.06.2020 07:58, Otto Moerbeek wrote: > > > On Wed, Jun 17, 2020 at 10:53:54PM +0200, Salvatore

fsck_ffs: faster with lots of cylinder groups

2020-06-21 Thread Otto Moerbeek
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

Re: obsd 6.7 - ntpd error msg

2020-06-18 Thread Otto Moerbeek
On Thu, Jun 18, 2020 at 09:57:34AM +0200, Salvatore Cuzzilla wrote: > Perfect, tnx! > > On 18.06.2020 07:58, Otto Moerbeek wrote: > > On Wed, Jun 17, 2020 at 10:53:54PM +0200, Salvatore Cuzzilla wrote: > > > > > Hi Otto here the logs (multitail

Re: obsd 6.7 - ntpd error msg

2020-06-17 Thread Otto Moerbeek
9:23 -ksh ToTo@obsd ~ $ OK, now we're getting somewhere. It always helps to provide lots of information form the start. The message is generated by ntpd being stopped. It is harmless, though it is actually wrong, it's a pip read error. So nothing to worry about. I'll see if the log level should be

Re: obsd 6.7 - ntpd error msg

2020-06-17 Thread Otto Moerbeek
- And show the log lines, all of them -Otto > > On 17.06.2020 20:51, Otto Moerbeek wrote: > > On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote: > > > > > Hi Folks, > > > > > > when I restart

Re: obsd 6.7 - ntpd error msg

2020-06-17 Thread Otto Moerbeek
On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote: > Hi Folks, > > when I restart ntpd I see this msg in /var/log/daemon: > > Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No suchfile > or directory > > however, time seems to be in sync: > >

sparc64: bootblocks vs ofwboot load address

2020-06-05 Thread Otto Moerbeek
Hi, Miod remarked the overwriting of the bootblocks actually is a regression I introduced. So teintroduce the lost comment and load ofwboot at 0x6000. OK? -Otto Index: bootblk.fth === RCS file:

Re: filesystem code integer and many inodes

2020-06-02 Thread Otto Moerbeek
On Fri, May 29, 2020 at 09:30:04AM +0200, Otto Moerbeek wrote: > On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote: > > > On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote: > > > > > Here's the separate diff for the prefcg loops. From F

Re: sparc64 boot issue on qemu

2020-05-31 Thread Otto Moerbeek
On Sun, May 31, 2020 at 09:49:34AM +0100, Mark Cave-Ayland wrote: > On 30/05/2020 10:54, Otto Moerbeek wrote: > > > https://cdn.openbsd.org/pub/OpenBSD/snapshots/sparc64/ > > contains the unpatched miniroot. > > > > https://www.drijf.net/openbsd/disk.qcow2 &g

Re: sparc64 boot issue on qemu

2020-05-30 Thread Otto Moerbeek
On Sat, May 30, 2020 at 10:11:08AM +0100, Mark Cave-Ayland wrote: > On 30/05/2020 10:03, Otto Moerbeek wrote: > > > Hi, > > > > thanks for the hints, but an unpatched 6.7 miniroot still fails to > > boot for me > > > > qemu-system-sparc64 -machine sun4

Re: sparc64 boot issue on qemu

2020-05-30 Thread Otto Moerbeek
On Sat, May 30, 2020 at 09:29:36AM +0100, Mark Cave-Ayland wrote: > On 29/05/2020 23:56, Jason A. Donenfeld wrote: > > > Oh that's a nice observation about `boot disk -V`. Doing so actually > > got me booting up entirely: > > > > $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 > > $

sparc64 boot issue on qemu

2020-05-29 Thread Otto Moerbeek
On Thu, May 28, 2020 at 10:11:28AM +0200, Otto Moerbeek wrote: > On Thu, May 28, 2020 at 01:21:21AM -0600, Jason A. Donenfeld wrote: > > > On Thu, May 28, 2020 at 1:19 AM Otto Moerbeek wrote: > > > Of course.., I was running it from a !wxallowed mount. BTW, qemu is in &g

Re: filesystem code integer and many inodes

2020-05-29 Thread Otto Moerbeek
On Fri, May 29, 2020 at 09:30:04AM +0200, Otto Moerbeek wrote: > On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote: > > > On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote: > > > > > Here's the separate diff for the prefcg loops. From F

Re: filesystem code integer and many inodes

2020-05-29 Thread Otto Moerbeek
On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote: > On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote: > > > Here's the separate diff for the prefcg loops. From FreeBSD. > > OK millert@ > > - todd > And here's the updated diff against -current.

Re: filesystem code integer and many inodes

2020-05-28 Thread Otto Moerbeek
On Tue, May 26, 2020 at 04:11:50PM +0200, Otto Moerbeek wrote: > On Tue, May 26, 2020 at 03:54:15PM +0200, Otto Moerbeek wrote: > > > On Tue, May 26, 2020 at 07:51:28AM -0600, Todd C. Miller wrote: > > > > > On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-28 Thread Otto Moerbeek
On Thu, May 28, 2020 at 01:21:21AM -0600, Jason A. Donenfeld wrote: > On Thu, May 28, 2020 at 1:19 AM Otto Moerbeek wrote: > > Of course.., I was running it from a !wxallowed mount. BTW, qemu is in > > packages, no need to build it yourself. > > Sure, but now I've been

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-28 Thread Otto Moerbeek
On Thu, May 28, 2020 at 01:05:59AM -0600, Jason A. Donenfeld wrote: > On Thu, May 28, 2020 at 12:15 AM Otto Moerbeek wrote: > > > > On Wed, May 27, 2020 at 11:28:09PM -0600, Jason A. Donenfeld wrote: > > > > > Hi Otto, > > > > > > On W

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-28 Thread Otto Moerbeek
On Wed, May 27, 2020 at 11:28:09PM -0600, Jason A. Donenfeld wrote: > Hi Otto, > > On Wed, May 27, 2020 at 4:07 AM Otto Moerbeek wrote: > > Although I'm not terribly interested in bugs that are only seen (s0 > > far) using emulation, please send me the details on ho

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Otto Moerbeek
On Wed, May 27, 2020 at 03:14:29AM -0600, Jason A. Donenfeld wrote: > One interesting quirk in doing this on qemu is that the 6.7 and > -current kernel both crash: > > Loading FCode image... > Loaded 6882 bytes > entry point is 0x4000 > Evaluating FCode... > OpenBSD IEEE 1275 Bootblock 2.0 >

Re: filesystem code integer and many inodes

2020-05-26 Thread Otto Moerbeek
On Tue, May 26, 2020 at 03:54:15PM +0200, Otto Moerbeek wrote: > On Tue, May 26, 2020 at 07:51:28AM -0600, Todd C. Miller wrote: > > > On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote: > > > > > Apart from the noting the strange Subject: I also like to mention

Re: filesystem code integer and many inodes

2020-05-26 Thread Otto Moerbeek
On Tue, May 26, 2020 at 07:51:28AM -0600, Todd C. Miller wrote: > On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote: > > > Apart from the noting the strange Subject: I also like to mention one > > change in the way cylinder groups are scanned. The current code

Re: filesystem code integer and many inodes

2020-05-26 Thread Otto Moerbeek
On Tue, May 26, 2020 at 11:58:39AM +0200, Otto Moerbeek wrote: > Hi, > > In theory ffs code support a maximum of UINT_MAX inodes, but in > practice, due to integer overflows in the current code, the limit is > INT_MAX inodes. > > This fixes that, and allows me to creat

filesystem code integer and many inodes

2020-05-26 Thread Otto Moerbeek
Hi, In theory ffs code support a maximum of UINT_MAX inodes, but in practice, due to integer overflows in the current code, the limit is INT_MAX inodes. This fixes that, and allows me to create and use filesystems with more than INT_MAX inodes. This is partly from FreeBSD code. Main change is

Re: Increase default number of devices created for LDOMs on sparc64

2020-05-18 Thread Otto Moerbeek
On Mon, May 18, 2020 at 06:27:04PM -, Miod Vallat wrote: > > > Learning how LDOMs work on this T4-1 and we only create 8 devices > > (each /dev/ldom* and /dev/ttyV*) by default. The now-commonly-available > > T4-1 machines can do far more than that pretty easily, so bump up the > > number

Re: luna88k: option FFS2 in RAMDISK

2020-05-18 Thread Otto Moerbeek
On Mon, May 18, 2020 at 08:29:57AM +0200, Otto Moerbeek wrote: > Hi, > > while luna88k cannot boot from ffs2, it should be able to use ffs2 > for non-root filesystems. So enable the RAMDISK to support ffs2, > > Cannot test, no hardware :-( > > ok? > > -Ott

luna88k: option FFS2 in RAMDISK

2020-05-18 Thread Otto Moerbeek
Hi, while luna88k cannot boot from ffs2, it should be able to use ffs2 for non-root filesystems. So enable the RAMDISK to support ffs2, Cannot test, no hardware :-( ok? -Otto

Re: scan_ffs prints negative size

2020-05-16 Thread Otto Moerbeek
On Sat, May 16, 2020 at 02:25:43PM +0200, Denis Fondras wrote: > Small diff to fix size printing. > > Before : > $ doas scan_ffs -v sd0 > block 55167 id 758d4818,f2894c98 size -859043093 > > After: > $ doas ./obj/scan_ffs -v sd0 > block 55167 id 758d4818,f2894c98 size 3435924203 I do not think

Re: [PATCH] sysupgrade

2020-04-30 Thread Otto Moerbeek
On Wed, Apr 29, 2020 at 10:28:12PM -0500, James Jerkins wrote: > Hello, > > This patch adds two new options to sysupgrade. The first option is for small > box systems like an APU system that only has the base and manual sets > installed. The second option is for headless systems without X11

Re: Install: Invalid group _sndiop in #163 amd64

2020-04-29 Thread Otto Moerbeek
he things that can go wrong. -Otto > > -- Originalnachricht -- > Von: "Alexandre Ratchov" > An: "Otto Moerbeek" > Cc: "Oliver Marugg" ; tech@openbsd.org > Gesendet: 29.04.2020 13:53:46 > Betreff: Re: Install: Invalid group _sndio

Re: Install: Invalid group _sndiop in #163 amd64

2020-04-29 Thread Otto Moerbeek
On Wed, Apr 29, 2020 at 01:02:29PM +0200, Otto Moerbeek wrote: > On Wed, Apr 29, 2020 at 10:28:37AM +, Oliver Marugg wrote: > > > Possible typo group _sniop shoud be _sndiod: > > Nope. _sniop is the correct name. The real issue is that that group isn't in > the /etc/g

Re: Install: Invalid group _sndiop in #163 amd64

2020-04-29 Thread Otto Moerbeek
On Wed, Apr 29, 2020 at 10:28:37AM +, Oliver Marugg wrote: > Possible typo group _sniop shoud be _sndiod: Nope. _sniop is the correct name. The real issue is that that group isn't in the /etc/group file used during install. How that can happen I do not know yet. -Otto > > During

Re: suggest to run rpki-client hourly

2020-04-17 Thread Otto Moerbeek
On Thu, Apr 16, 2020 at 05:18:15PM -0600, Theo de Raadt wrote: > Job Snijders wrote: > > > In cases where rpki-client for some reason ends up taking longer than an > > hour, the next execution attempt of the command will be skipped. Better > > to just try again an hour later, this helps avoid

Re: switch powerpc to MI mplock

2020-04-12 Thread Otto Moerbeek
On Fri, Apr 10, 2020 at 09:31:24AM +0200, Martin Pieuchot wrote: > In order to reduce the differences with other architecture and to be able > to use WITNESS on powerpc I'm proposing the diff below that makes use of > the MI mp (ticket) lock implementation for powerpc. > > This has been tested

Re: ntpd: prevent duplicate definitions of `conf` and `ibus_dns`

2020-04-11 Thread Otto Moerbeek
On Sat, Apr 04, 2020 at 04:00:50PM -0700, Michael Forney wrote: > This prevents a linking error with gcc 10, which enables -fno-common > by default. > > ISO C requires exactly one definition of objects with external > linkage throughout the entire program. > > `conf` is already defined in

Re: Include /var/www/tmp into base install

2020-04-08 Thread Otto Moerbeek
On Wed, Apr 08, 2020 at 11:08:41AM +0100, Kevin Chadwick wrote: > On 2020-04-07 17:12, Andrew Grillet wrote: > > For me, the "/var is full" problem can be adequately mitigated by mounting > > a separate partition as /var/tmp. > > Does FFS2 have the same disklabel limit on partitions? I guess

Re: Regarding the understanding of the malloc(3) code

2020-03-27 Thread Otto Moerbeek
On Fri, Mar 27, 2020 at 02:21:44PM +0530, Neeraj Pal wrote: > On Wed, Mar 25, 2020 at 2:06 AM Otto Moerbeek wrote: > > > pp points to a page of chunks > > bp point to the associated meta info: a bitmap that says which chunks > > in the page are free. The bitmap is an ar

Re: Regarding the understanding of the malloc(3) code

2020-03-24 Thread Otto Moerbeek
On Wed, Mar 25, 2020 at 01:54:51AM +0530, Neeraj Pal wrote: > Hi Otto, > > I am having two small issues or confusions: > > First Query: > > 885 /* > 886 * Allocate a page of chunks > 887 */ > 888 static struct chunk_info * > 889 omalloc_make_chunks(struct dir_info *d, int bits, int

bootblocks ffs2 support for sparc64

2020-03-24 Thread Otto Moerbeek
Hi, As some of you know I have been working on the ability to boot from an ffs2 root partition on as many platforms as possible. Many platforms are done, but sparc64, landisk, octeon and luna88k remain. sparc64 uses bootblock written in Forth that interpret the filesystem on the boot disk.

Re: Regarding the understanding of the malloc(3) code

2020-03-18 Thread Otto Moerbeek
On Wed, Mar 18, 2020 at 03:35:45PM +0530, Neeraj Pal wrote: > On Wed, 18 Mar, 2020, 12:46 pm Otto Moerbeek, wrote: > > > There are several types of canaries. They try to detect corruption of > > various meta data structures. There are alo canaries for user allocated > >

Re: Regarding the understanding of the malloc(3) code

2020-03-18 Thread Otto Moerbeek
On Wed, Mar 18, 2020 at 07:29:51AM +0530, Neeraj Pal wrote: > On Fri, Mar 13, 2020, at 11:45 AM Otto Moerbeek wrote: > > > > Please indent your code snippets. > yeah, my apologies. I shall indent the code snippets. > > > > > di_info is special. Having a gua

Re: Regarding the understanding of the malloc(3) code

2020-03-13 Thread Otto Moerbeek
On Fri, Mar 13, 2020 at 03:43:21AM +0530, Neeraj Pal wrote: > On Tue, Mar 10, 2020 at 4:03 PM Otto Moerbeek wrote: > > There's an off by one in your question :-) > Yeah, sorry about that, actually in flow of writing the mail forgot to notice. > > > Fo single threaded pro

Re: Regarding the understanding of the malloc(3) code

2020-03-10 Thread Otto Moerbeek
On Tue, Mar 10, 2020 at 03:04:00AM +0530, Neeraj Pal wrote: > Hi there, > > I am reading and learning the internals of malloc(3). > So, after compiling the debug version of libc and using it for one > basic sample code for malloc(3). > > Not able to understand some parts of the following code

heads up: amd64 snap

2020-03-07 Thread Otto Moerbeek
It looks like some BIOS do not like the recent biosboot changes. Symptoms are a hang in the bios I reverted them, the next amd64 snap should be ok again. 0Otto

Re: top(1) CPU field width diff

2020-02-27 Thread Otto Moerbeek
On Thu, Feb 27, 2020 at 08:09:49PM +0100, Piotr Durlej wrote: > Hello, > > the following top(1) patch allows for printing CPU percentages >=100% > without overflowing the CPU column width. > > https://www.durlej.net/diff/top.diff > > Regards, > Piotr Durlej > Please post diffs inline. Also,

Re: amd64: use ffs2 for filesystems created by install

2020-02-21 Thread Otto Moerbeek
On Thu, Feb 20, 2020 at 09:02:32PM +0100, Otto Moerbeek wrote: > On Thu, Feb 20, 2020 at 08:20:13PM +0100, Otto Moerbeek wrote: > > > On Thu, Feb 20, 2020 at 07:48:25PM +0100, Otto Moerbeek wrote: > > > > > On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wr

Re: amd64: use ffs2 for filesystems created by install

2020-02-20 Thread Otto Moerbeek
On Thu, Feb 20, 2020 at 08:20:13PM +0100, Otto Moerbeek wrote: > On Thu, Feb 20, 2020 at 07:48:25PM +0100, Otto Moerbeek wrote: > > > On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wrote: > > > > > Hi Otto, > > > >

Re: amd64: use ffs2 for filesystems created by install

2020-02-20 Thread Otto Moerbeek
On Thu, Feb 20, 2020 at 07:48:25PM +0100, Otto Moerbeek wrote: > On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wrote: > > > Hi Otto, > > > > * Otto Moerbeek wrote: > > > Hi, > > > > > > This is amd64 only, it contai

Re: amd64: use ffs2 for filesystems created by install

2020-02-20 Thread Otto Moerbeek
On Thu, Feb 20, 2020 at 07:27:55PM +0100, Matthias Schmidt wrote: > Hi Otto, > > * Otto Moerbeek wrote: > > Hi, > > > > This is amd64 only, it contains some i386 pieces, but those are > > incomplete. > > > > With the diff, install uses ffs2 for th

amd64: use ffs2 for filesystems created by install

2020-02-20 Thread Otto Moerbeek
Hi, This is amd64 only, it contains some i386 pieces, but those are incomplete. With the diff, install uses ffs2 for the filesystems created during install. All boot loaders (except the floppy one) contain support for loading a kernel from ffs2. To test, create a snapshot (see release(8)) with

Re: ffs1 and the future

2020-02-19 Thread Otto Moerbeek
On Wed, Feb 19, 2020 at 07:23:13PM -0600, Scott Cheloha wrote: > On Wed, Feb 19, 2020 at 05:26:40PM +0100, Otto Moerbeek wrote: > > On Wed, Feb 19, 2020 at 05:10:11PM +0100, Otto Moerbeek wrote: > > > > > On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote: &g

Re: ffs1 and the future

2020-02-19 Thread Otto Moerbeek
On Wed, Feb 19, 2020 at 05:10:11PM +0100, Otto Moerbeek wrote: > On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote: > > > On Wed, Feb 19, 2020 at 04:00:34PM +0100, Otto Moerbeek wrote: > > > > > > [...] > > > > > > FFS1, the default f

Re: ffs1 and the future

2020-02-19 Thread Otto Moerbeek
On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote: > On Wed, Feb 19, 2020 at 04:00:34PM +0100, Otto Moerbeek wrote: > > > > [...] > > > > FFS1, the default filesystem, uses 32-bit signed timestamps on disk. > > That means that in 2038, there's

Re: ffs1 and the future

2020-02-19 Thread Otto Moerbeek
On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote: > On Wed, Feb 19, 2020 at 04:00:34PM +0100, Otto Moerbeek wrote: > > > > [...] > > > > FFS1, the default filesystem, uses 32-bit signed timestamps on disk. > > That means that in 2038, there's

mbr booting from ffs2

2020-02-19 Thread Otto Moerbeek
Hi, booting from an ffs2 filesystem is a puzzle containing many pieces. For amd64 and i386 mbr booting, the pieces below are needed. Lifted from an old bitrig tree. Note that this is *not* enough to get thing going since boot(8) and its variants do not support ffs2 yet, but for this diff I'm

ffs1 and the future

2020-02-19 Thread Otto Moerbeek
Hoi, FFS1, the default filesystem, uses 32-bit signed timestamps on disk. That means that in 2038, there's going to be a problem, timestamps will the be interperet as coming from the start of the 1900's. FFS2 does not have this limitation, but at the moment, we cannot boot from it. I'm working

dumpfs: don't pick alternate superblock

2020-02-16 Thread Otto Moerbeek
Hi, If the block size is 64k, the first alternate ffs1 superblock ends up in a location first looked at by dumpfs. fsck_ffs(8) (see setup.c) and ffs_mountfs() in sys/ufs/ffs/ffs_vfsops.c have protection against that case, since we really want the primary superblock, that's the one that is

Re: ntpd and 2036

2020-01-30 Thread Otto Moerbeek
On Mon, Jan 20, 2020 at 07:08:26AM +0100, Otto Moerbeek wrote: > On Fri, Jan 10, 2020 at 03:14:42PM +0100, Otto Moerbeek wrote: > > > Hi, > > > > THe ntp protocol uses 32-bit unsigned timestamps counting seconds > > since 1900. That means that in 2036

Re: Update disklabel(8) man page

2020-01-28 Thread Otto Moerbeek
On Tue, Jan 28, 2020 at 06:43:38PM +0100, Martin wrote: > Hi > > Attached a diff to bring the disklabel man page up to date. Information > taken directly from editor.c line 95. Committed, thanks, -Otto > > Best, > > Martin > > Index: disklabel.8 >

Re: snmpd(8) timer.c garbage collect

2020-01-22 Thread Otto Moerbeek
On Wed, Jan 22, 2020 at 10:51:45AM +0100, Martijn van Duren wrote: > Trying to wrap my head around some of the snmpd code I found this pearl > that appears to do nothing more than warm up the room. Do you really want to get rid of the init of snmpd_env->sc_cpustates ? -Otto > > OK? >

Re: ntpd and 2036

2020-01-19 Thread Otto Moerbeek
On Fri, Jan 10, 2020 at 03:14:42PM +0100, Otto Moerbeek wrote: > Hi, > > THe ntp protocol uses 32-bit unsigned timestamps counting seconds > since 1900. That means that in 2036 the timestamp field will wrap. > This difff makes sure ntpd handles that correctly by assuming we are &g

ntpd and 2036

2020-01-10 Thread Otto Moerbeek
Hi, THe ntp protocol uses 32-bit unsigned timestamps counting seconds since 1900. That means that in 2036 the timestamp field will wrap. This difff makes sure ntpd handles that correctly by assuming we are in era 0 unless we see "small" timestamps. tested in the future (incuding wrapping form

Re: backgrounded ssh, strange terminal behaviour

2019-12-10 Thread Otto Moerbeek
On Tue, Dec 10, 2019 at 01:56:29PM +, Stuart Henderson wrote: > Not new (it happens in at least 6.6) but I just noticed this. > > If I run some program via ssh command-line ("ssh localhost sleep 60" > is good enough), then put it in the background (^Z bg), the terminal > misses about a third

Re: [PATCH] correcting in-sane ntpd.conf

2019-12-08 Thread Otto Moerbeek
On Sun, Dec 08, 2019 at 11:15:55AM +0100, List wrote: > Please excuse that I wasted your time. You're absolutely right. > > The only thing that comes to my mind is that one could add something > like a small notice that tells the new user to maybe alter his ntpd > constraints to a "TLS-Provider"

Re: un-boolean_t i386's pmap

2019-12-05 Thread Otto Moerbeek
On Thu, Dec 05, 2019 at 04:12:01PM +0100, Martin Pieuchot wrote: > On 05/12/19(Thu) 11:57, Otto Moerbeek wrote: > > On Thu, Dec 05, 2019 at 12:38:34PM +0100, Martin Pieuchot wrote: > > > > > ok? > > > > I'm no kernel hacker but I really do not see the point.

Re: un-boolean_t i386's pmap

2019-12-05 Thread Otto Moerbeek
On Thu, Dec 05, 2019 at 12:38:34PM +0100, Martin Pieuchot wrote: > ok? I'm no kernel hacker but I really do not see the point. boolean_t helps to see if a functions is supposed to return a boolean instead of an error code. I hate reading a function and having to guess if 0 is supposed to mean

Re: unwind and split-horizon DNS

2019-12-01 Thread Otto Moerbeek
On Sat, Nov 30, 2019 at 08:39:36AM +0100, Otto Moerbeek wrote: > On Fri, Nov 29, 2019 at 11:37:40PM +0100, Björn Ketelaars wrote: > > > On Fri 29/11/2019 21:35, Otto Moerbeek wrote: > > > On Fri, Nov 29, 2019 at 10:27:57AM +0100, Florian Obser wrote: > > > > &g

Re: unwind and split-horizon DNS

2019-11-29 Thread Otto Moerbeek
On Fri, Nov 29, 2019 at 11:37:40PM +0100, Björn Ketelaars wrote: > On Fri 29/11/2019 21:35, Otto Moerbeek wrote: > > On Fri, Nov 29, 2019 at 10:27:57AM +0100, Florian Obser wrote: > > > > > On Fri, Nov 29, 2019 at 07:28:20AM +0100, Otto Moerbeek wrote: > > > >

Re: unwind and split-horizon DNS

2019-11-29 Thread Otto Moerbeek
On Fri, Nov 29, 2019 at 10:27:57AM +0100, Florian Obser wrote: > On Fri, Nov 29, 2019 at 07:28:20AM +0100, Otto Moerbeek wrote: > > On Fri, Nov 29, 2019 at 07:02:27AM +0100, Björn Ketelaars wrote: > > > I experienced no regression while using the free wifi service of the &g

Re: unwind and split-horizon DNS

2019-11-28 Thread Otto Moerbeek
On Fri, Nov 29, 2019 at 07:02:27AM +0100, Björn Ketelaars wrote: > On Thu 28/11/2019 16:16, Otto Moerbeek wrote: > > On Thu, Nov 28, 2019 at 03:26:34PM +0100, Otto Moerbeek wrote: > > > > > Hi, > > > > > > In many offices, split h

Re: unwind and split-horizon DNS

2019-11-28 Thread Otto Moerbeek
On Thu, Nov 28, 2019 at 03:26:34PM +0100, Otto Moerbeek wrote: > Hi, > > In many offices, split horizon DNS is used. This means that if you are > in the office you are supposed to use a specific resolver that will > hand out different results than when asking for the same nam

unwind and split-horizon DNS

2019-11-28 Thread Otto Moerbeek
Hi, In many offices, split horizon DNS is used. This means that if you are in the office you are supposed to use a specific resolver that will hand out different results than when asking for the same name on the rest of the internet. Until now unwind could not really handle that, e.g. in

Re: unwind: log missing config file

2019-11-19 Thread Otto Moerbeek
On Tue, Nov 19, 2019 at 03:53:16AM +0100, Florian Obser wrote: > On Tue, Nov 19, 2019 at 12:15:34AM +0100, Klemens Nanni wrote: > > On Mon, Nov 18, 2019 at 10:19:47PM +0100, Klemens Nanni wrote: > > > With that, my initial case is no longer misleading; alternatively, I > > > can implement the

Re: [PATCH] [src] bin/ed/README - fix quote/comma

2019-11-17 Thread Otto Moerbeek
On Sun, Nov 17, 2019 at 08:31:00AM +, Raf Czlonka wrote: > Hi all, > > Pretty straightforward - comma snuck in inside the quoted book title. This is how I learned it. Myabe a bit old-fashinoed, but not wrong. -Otto > > Regards, > > Raf > > Index: bin/ed/README >

Re: unwind(8): refactor & simplify refcounting

2019-11-13 Thread Otto Moerbeek
On Tue, Nov 12, 2019 at 05:45:38PM +0100, Florian Obser wrote: > Did I get this right? I'd appreciate it if someone could give this a > once over. > > Since resolve() switched to a callback mechanism all uw_resolver objects > pass through resolve() and either asr_resolve_done() or >

Re: HEADS UP: ntpd changing

2019-11-11 Thread Otto Moerbeek
On Sun, Nov 10, 2019 at 05:03:02PM -0700, Theo de Raadt wrote: > The ntpd options -s and -S are going to be removed soon and at startup > with print: > > -s option no longer works and will be removed soon. > Please reconfigure to use constraints or trusted servers. > > Probably after

Re: Opportunistic DoT for unwind(8)

2019-11-02 Thread Otto Moerbeek
> > On Thu, Oct 31, 2019 at 08:14:04PM +0100, Otto Moerbeek wrote: > > > > > Hi, > > > > > > > > > > So here's a new diff that incorporates the bug fix mentioned plus > > > > > debug printf line changes suggested by Stuar

Re: Opportunistic DoT for unwind(8)

2019-10-31 Thread Otto Moerbeek
Hi, So here's a new diff that incorporates the bug fix mentioned plus debug printf line changes suggested by Stuart. Please note that this is a diff on top of very recent current, i.e. florian's work he committed today. That means that you need to be up-to-date (including a recent libc update

Re: Opportunistic DoT for unwind(8)

2019-10-31 Thread Otto Moerbeek
On Wed, Oct 30, 2019 at 08:51:00PM +, Stuart Henderson wrote: > On 2019/10/30 15:57, Otto Moerbeek wrote: > > Hi, > > > > I got *very* little feedback on this request for testing. > > > > If not enough enough testing is done, I'll either abandon the diff or

Re: Opportunistic DoT for unwind(8)

2019-10-31 Thread Otto Moerbeek
On Wed, Oct 30, 2019 at 11:46:36PM +0100, Remi Locherer wrote: > Hi Otto, > > On Wed, Oct 30, 2019 at 03:57:15PM +0100, Otto Moerbeek wrote: > > Hi, > > > > I got *very* little feedback on this request for testing. > > > > If not enough enough testin

Re: Opportunistic DoT for unwind(8)

2019-10-30 Thread Otto Moerbeek
Hi, I got *very* little feedback on this request for testing. If not enough enough testing is done, I'll either abandon the diff or commit it as-is, introducing bugs that could have been prevented. Both are not good. So get going! -Otto

Re: Opportunistic DoT for unwind(8)

2019-10-24 Thread Otto Moerbeek
On Thu, Oct 24, 2019 at 12:24:22PM +0200, Otto Moerbeek wrote: > On Thu, Oct 24, 2019 at 11:27:24AM +0100, Kevin Chadwick wrote: > > > > > > The purpose of unwind is to provide secure DNS services even when > > > the available nameservers are broken or filtered li

  1   2   3   4   5   6   7   8   >