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

Re: Opportunistic DoT for unwind(8)

2019-10-24 Thread Otto Moerbeek
On Thu, Oct 24, 2019 at 11:27:24AM +0100, Kevin Chadwick wrote: > > > The purpose of unwind is to provide secure DNS services even when > > the available nameservers are broken or filtered like in many hotels. > > To do that, it prefers DNSSEC whenever possible and changes to do > > resolving by

Re: Opportunistic DoT for unwind(8)

2019-10-23 Thread Otto Moerbeek
On Wed, Oct 23, 2019 at 02:40:53PM +0200, Otto Moerbeek wrote: > Hi, > > The patch below add opportunistic DoT to unwind. Some background > info: > > The purpose of unwind is to provide secure DNS services even when > the available nameservers are broken or filtere

Re: Opportunistic DoT for unwind(8)

2019-10-23 Thread Otto Moerbeek
On Wed, Oct 23, 2019 at 02:40:53PM +0200, Otto Moerbeek wrote: > [1] https://doh.powerdns.org/doh/privacy.html Should be https://powerdns.org/doh/privacy.html

Opportunistic DoT for unwind(8)

2019-10-23 Thread Otto Moerbeek
Hi, The patch below add opportunistic DoT to unwind. Some background info: The purpose of unwind is to provide secure DNS services even when the available nameservers are broken or filtered like in many hotels. To do that, it prefers DNSSEC whenever possible and changes to do resolving by

Re: [PATCH] Avoid leftover temporary mount points when using -P (mfs)

2019-09-14 Thread Otto Moerbeek
On Sun, Sep 08, 2019 at 10:10:06PM -0300, Rafael Neves wrote: > Updated patch: It includes Otto's requests and remove unnecessary > unmount(dst, 0) from copy(), because the caller unmount tmpnode. > While there, I adjusted the return value of gettmpmnt() to return 0 > on success, and changed the

Re: [PATCH] Avoid leftover temporary mount points when using -P (mfs)

2019-09-01 Thread Otto Moerbeek
On Sun, Sep 01, 2019 at 05:01:55PM -0300, Rafael Neves wrote: > On Wed, Aug 28, 2019 at 03:39:17PM +0200, Otto Moerbeek wrote: > > On Sat, Aug 17, 2019 at 12:13:50PM -0300, Rafael Neves wrote: > > > > > Hi, > > > > > > Submitting to tech@ to broader a

Re: [PATCH] Avoid leftover temporary mount points when using -P (mfs)

2019-08-28 Thread Otto Moerbeek
On Sat, Aug 17, 2019 at 12:13:50PM -0300, Rafael Neves wrote: > Hi, > > Submitting to tech@ to broader audience. > > When using -P option in mfs with a directory or a block device that > doen't exist, for example when the device roams, newfs(2) leaves > leftovers of temporary mount points. >

Re: flex {c,m}alloc() checks

2019-08-28 Thread Otto Moerbeek
On Wed, Aug 28, 2019 at 10:07:32AM +0800, Michael Mikonos wrote: > On Sun, Aug 25, 2019 at 02:58:47PM +0200, Otto Moerbeek wrote: > > On Sun, Aug 25, 2019 at 08:32:04PM +0800, Michael Mikonos wrote: > > > > > Hello, > > > > > > I noticed that flex is to

Re: flex {c,m}alloc() checks

2019-08-25 Thread Otto Moerbeek
On Sun, Aug 25, 2019 at 08:32:04PM +0800, Michael Mikonos wrote: > Hello, > > I noticed that flex is too trusting and assumes > calloc/malloc will always succeed. Hopefully I > caught all of them. > I tried to follow the existing idiom of > calling flexerror() and passing strings via > the _()

acpi GPE storm on X1 Carbon 6th

2019-08-23 Thread Otto Moerbeek
Hi, My X1 still endures an ACPI storm if I use an external displayport display. Previously I posted a workaround that just made acpi_gpe() a no-op for GPE 111. That solved it for me, but is not the right way of course. I was looking at acpi_ev_gpe_dispatch() in Linux and noticed it does a

Re: /bin/cp: Incorrect checking the return value

2019-08-16 Thread Otto Moerbeek
On Fri, Aug 16, 2019 at 05:44:35PM +0900, Masato Asou wrote: > Incorrect checking the return value of malloc and system calls in > /bin/cp. > > ok? Altough I indeed prefer to check against NULL these are not incorrect, just bad idiom. -Otto > > Index: utils.c >

nmea 4.1

2019-08-15 Thread Otto Moerbeek
Hi, NMEA 4.1 appends an extra field to the RMC message. We're not interested in it's value, but we do want to accept the new format. Tested to work on a nav module enabled for Galileo info (which requires NMEA 4.1). OK? -Otto Index: tty_nmea.c

Re: Grammar and style edits to installation guide

2019-07-08 Thread Otto Moerbeek
On Mon, Jul 08, 2019 at 10:26:57AM -0700, Evan Silberman wrote: I don't know our stance on Unix vs Un*x. I'll leave this to some native speaker, like jmc@ who knows all about commas (and much more) :-) -Otto I'll leave this to jmc or some other native speaker. S > Otto Moerbeek wr

Re: Grammar and style edits to installation guide

2019-07-07 Thread Otto Moerbeek
On Sun, Jul 07, 2019 at 10:44:42PM -0700, Evan Silberman wrote: > I noticed one thing that bothered me and decided to look for other > things that bothered me. Changes were made without reference to the code > of the installation program and without checking that the installer > behaves as

Re: Softraid bootloader size allowance

2019-07-03 Thread Otto Moerbeek
On Wed, Jul 03, 2019 at 02:05:24PM -0400, Chris Ross wrote: > On Wed, Jul 03, 2019 at 04:20:59PM +0200, Christian Weisgerber wrote: > > Chris Ross: > > > > > Is there a hard reason SR_BOOT_LOADER_SIZE cannot be raised to sometime > > > larger, perhaps 1024 (instead of the current 320) ? > > > >

ntpd auto time setting

2019-06-20 Thread Otto Moerbeek
Hi, I have been working on a nice feature that improves startup behaviour of ntpd. Summary: make sure you have at least one constraint source configured and use no options. ntpd will set the clock if needed, even if you machines has no battery backed up clock and is running a DNSSEC validating

request for testing: bootstrapping time

2019-06-02 Thread Otto Moerbeek
Hi, Bootstrapping time is a bit of a hard problem. The hardest scenario is: resolver running in DNSSEC mode on the local machine, on a machine that does not have real time clock with battery backup. It's time will be wrong, especially on a cold boot. 1. Wrong time, so dnssec validation fails ->

Re: makeinfo dumps core

2019-05-26 Thread Otto Moerbeek
On Sat, May 25, 2019 at 09:53:26PM +0200, Otto Moerbeek wrote: > On Sat, May 25, 2019 at 10:45:48AM -0500, athom...@athompso.net wrote: > > > >Synopsis: makeinfo dumps core on amdref.info when outputting docbook > > >Category: user > > >Environment: > >

Re: update sysupgrade manpage

2019-05-26 Thread Otto Moerbeek
On Mon, May 27, 2019 at 04:16:01AM +0200, giovani...@tuta.io wrote: > Hello, > > I tried to make sysupgrade man page more readable and fixed a small mistake. > The man page stated: > > > .It Fl s > > Upgrade to a snapshot. > > The default is to find out if the system is running a release or a

Re: wsdisplay(4) factual manual patch

2019-05-25 Thread Otto Moerbeek
On Sat, May 25, 2019 at 12:41:39PM +0200, zeurk...@volny.cz wrote: > [not subscribed, please Cc, thanks] > > This error is still in 6.5. Anyone willing to commit this? > > --zeur. > > (this was patch 3 from the wscons 'many ttys' set) > > Index: src/share/man/man4/wsdisplay.4 >

Re: New implementation and interface for strlcpy and strlcat

2019-05-23 Thread Otto Moerbeek
On Thu, May 23, 2019 at 05:21:19PM +0700, Oleg Chumanov wrote: > Hi, there > > First of all, > I do not understand why the interface (the return value of these functions) > is so different. They both do almost the same thing. > > I do not understand, why the return value is the length of

Re: caesar(6) to accept negative argument

2019-05-15 Thread Otto Moerbeek
On Wed, May 15, 2019 at 02:33:45PM -0400, Ted Unangst wrote: > Otto Moerbeek wrote: > > We're computing modulo 26 here. Negative numbers have a positive > > equivalent. So you diff adds code for no benefit. > > I think the amount of code added is an acceptable cost for impro

Re: caesar(6) to accept negative argument

2019-05-15 Thread Otto Moerbeek
On Wed, May 15, 2019 at 03:36:57PM +0100, tleguern wrote: > Hi, > > This little patch makes caesar(6) useful at both encrypting and > decrypting texts by allowing a negative rotation. > > Example: > > $ echo Ceci est un test | caesar 10 > Moms ocd ex docd > $ echo Ceci est un test | caesar 10

Re: remove regress maxtime

2019-05-14 Thread Otto Moerbeek
On Tue, May 14, 2019 at 02:16:19AM -0400, Alexander Bluhm wrote: > Hi, > > Does anyone use the REGRESS_MAXTIME feature? I would like to remove it. > > - The timeout based on CPU seconds is pretty useless. > Most hanging tests sleep and do not spin. > - A timeout cannot be distinguished from

Re: fix tcpdump localtime caching

2019-05-11 Thread Otto Moerbeek
On Fri, May 10, 2019 at 03:25:17PM +0200, Holger Mikolon wrote: > The comment above priv_localtime() says, the obtained localtime (from the > privileged process) is cached for about one minute. However, since the > according if statement compares the wrong variable, the caching doesn't >

Re: ld.so speedup (part 2)

2019-04-28 Thread Otto Moerbeek
On Sun, Apr 28, 2019 at 01:57:46AM +, Ian McWilliam wrote: > > > On 28/4/19, 12:56 am, "owner-t...@openbsd.org on behalf of Otto Moerbeek" > wrote: > > >On Sat, Apr 27, 2019 at 04:43:14PM +0200, Otto Moerbeek wrote: > > > >> On Sat, Apr 27, 20

Re: ld.so speedup (part 2)

2019-04-27 Thread Otto Moerbeek
On Sat, Apr 27, 2019 at 04:43:14PM +0200, Otto Moerbeek wrote: > On Sat, Apr 27, 2019 at 04:37:23PM +0200, Antoine Jacoutot wrote: > > > On Sat, Apr 27, 2019 at 09:55:33PM +0800, Nathanael Rensen wrote: > > > The diff below speeds up ld.so library intialisation where the

Re: ld.so speedup (part 2)

2019-04-27 Thread Otto Moerbeek
On Sat, Apr 27, 2019 at 04:37:23PM +0200, Antoine Jacoutot wrote: > On Sat, Apr 27, 2019 at 09:55:33PM +0800, Nathanael Rensen wrote: > > The diff below speeds up ld.so library intialisation where the dependency > > tree is broad and deep, such as samba's smbd which links over 100 libraries. > >

Re: libevent: Protect integer multiplications (min_heap)

2019-04-17 Thread Otto Moerbeek
On Wed, Apr 17, 2019 at 11:34:36AM -0400, Ted Unangst wrote: > Theo de Raadt wrote: > > So the diff presented falls short of what should be done here; > > insufficient lines deleted. > > we're not getting to the fun part yet, but this unfold some complex operations > to assist human readers. >

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-30 Thread Otto Moerbeek
On Tue, Mar 26, 2019 at 03:52:47PM +0100, Michał Koc wrote: > W dniu 25.03.2019 o 15:08, Otto Moerbeek pisze: > > On Sat, Mar 23, 2019 at 06:07:02PM +0100, Michał Koc wrote: > > > > > ... [snip] > > This is almost good. You might fold host_ip() into net_set_sa().

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-25 Thread Otto Moerbeek
On Sat, Mar 23, 2019 at 06:07:02PM +0100, Michał Koc wrote: > ... [snip] This is almost good. You might fold host_ip() into net_set_sa(). the double malloc and copy isn't really needed. -Otto

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-23 Thread Otto Moerbeek
On Sat, Mar 23, 2019 at 06:07:02PM +0100, Michał Koc wrote: > W dniu 23.03.2019 o 10:09, Otto Moerbeek pisze: > > On Fri, Mar 22, 2019 at 09:57:29PM +0100, Michał Koc wrote: > > > > > W dniu 22.03.2019 o 11:19, Michał Koc pisze: > > > > W dniu 21.

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-23 Thread Otto Moerbeek
On Fri, Mar 22, 2019 at 09:57:29PM +0100, Michał Koc wrote: > W dniu 22.03.2019 o 11:19, Michał Koc pisze: > > W dniu 21.03.2019 o 11:52, Otto Moerbeek pisze: > > > On Thu, Mar 21, 2019 at 09:28:28AM +0100, Michał Koc wrote: > > > > > > > W dniu

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-21 Thread Otto Moerbeek
On Thu, Mar 21, 2019 at 09:28:28AM +0100, Michał Koc wrote: > W dniu 21.03.2019 o 07:21, Otto Moerbeek pisze: > > On Thu, Mar 21, 2019 at 12:51:11AM +0100, Klemens Nanni wrote: > > > On Tue, Mar 12, 2019 at 03:19:56PM +0100, Otto Moerbeek wrote: > > > > > I

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-21 Thread Otto Moerbeek
On Thu, Mar 21, 2019 at 12:51:11AM +0100, Klemens Nanni wrote: > > On Tue, Mar 12, 2019 at 03:19:56PM +0100, Otto Moerbeek wrote: > > > I also fixed a case of parsing IPv6 addresses. > > > > > > Anyone willing to ok? > See comments inline. > > > An

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-15 Thread Otto Moerbeek
On Fri, Mar 15, 2019 at 12:46:32PM +0100, Michał Koc wrote: > W dniu 12.03.2019 o 15:19, Otto Moerbeek pisze: > > On Tue, Mar 12, 2019 at 02:02:15PM +0100, Otto Moerbeek wrote: > > > > > On Mon, Mar 11, 2019 at 05:11:56PM +0100, Otto Moerbeek wrote: > > > >

Re: ipv6 via ipsec tunnel

2019-03-15 Thread Otto Moerbeek
On Fri, Mar 15, 2019 at 07:48:55AM +0100, Otto Moerbeek wrote: > On Fri, Mar 15, 2019 at 04:44:52PM +1000, David Gwynne wrote: > > > > > > > > On 15 Mar 2019, at 16:37, Otto Moerbeek wrote: > > > > > > On Fri, Mar 15,

Re: ipv6 via ipsec tunnel

2019-03-15 Thread Otto Moerbeek
On Fri, Mar 15, 2019 at 04:44:52PM +1000, David Gwynne wrote: > > > > On 15 Mar 2019, at 16:37, Otto Moerbeek wrote: > > > > On Fri, Mar 15, 2019 at 04:15:55PM +1000, David Gwynne wrote: > > > >> > >> > >>> On 14 Mar 2019, at 19:

Re: ipv6 via ipsec tunnel

2019-03-15 Thread Otto Moerbeek
On Fri, Mar 15, 2019 at 04:15:55PM +1000, David Gwynne wrote: > > > > On 14 Mar 2019, at 19:36, Otto Moerbeek wrote: > > > > Hi, > > > > So i have a little IPv6 problem. > > > > I have a machine in colocation that has IPv6. I have my ho

Re: ipv6 via ipsec tunnel

2019-03-14 Thread Otto Moerbeek
On Thu, Mar 14, 2019 at 10:43:03AM +0100, Claudio Jeker wrote: > On Thu, Mar 14, 2019 at 10:36:58AM +0100, Otto Moerbeek wrote: > > Hi, > > > > So i have a little IPv6 problem. > > > > I have a machine in colocation that has IPv6. I have my home cable > &

ipv6 via ipsec tunnel

2019-03-14 Thread Otto Moerbeek
Hi, So i have a little IPv6 problem. I have a machine in colocation that has IPv6. I have my home cable modem connection that does not have it. So I thought: I make my own tunnel. First I tried gif(4), that worked, but only after some fighting with mtu settings on all hosts on my home net via

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-12 Thread Otto Moerbeek
On Tue, Mar 12, 2019 at 02:02:15PM +0100, Otto Moerbeek wrote: > On Mon, Mar 11, 2019 at 05:11:56PM +0100, Otto Moerbeek wrote: > > > > > I was going to test your diff but it does not apply. Your mailer seems > > to convert spaces and or tabs to funny char sequenc

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-12 Thread Otto Moerbeek
On Mon, Mar 11, 2019 at 05:11:56PM +0100, Otto Moerbeek wrote: > > I was going to test your diff but it does not apply. Your mailer seems > to convert spaces and or tabs to funny char sequences. Please fix > (test by mailing to yourself and applying with patch(1)) and resend, >

<    1   2   3   4   5   6   7   8   9   >