daily CVS update output

Updating src tree: P src/crypto/external/bsd/heimdal/dist/lib/base/error.c P src/distrib/sets/lists/base/md.amd64 P src/distrib/sets/lists/comp/ad.aarch64 P src/distrib/sets/lists/debug/md.amd64 P src/distrib/sets/lists/man/mi P src/distrib/sets/lists/modules/mi P src/doc/CHANGES P src/doc/HACKS

Re: heads-up: planned changes in nvmm

And on top of this if one wants a member of nvmm group to be able to run nvmmctl, then /dev/nvmm must be 660 ... On Mon, 28 Oct 2019 at 23:13, Chavdar Ivanov wrote: > > And then one has to change the permissions of the tap device and the > disk in use, e,g, > ... > chown root:nvmm /dev/tap3 >

Re: heads-up: planned changes in nvmm

And then one has to change the permissions of the tap device and the disk in use, e,g, ... chown root:nvmm /dev/tap3 chmod 660 /dev/tap3 chown root:nvmm /dev/zvol/rdsk/pail/openbsd chmod 660 /dev/zvol/rdsk/pail/openbsd ... On Mon, 28 Oct 2019 at 22:54, Chavdar Ivanov wrote: > > Thanks! Sorted. >

Re: heads-up: planned changes in nvmm

Thanks! Sorted. On Mon, 28 Oct 2019 at 21:04, J. Lewis Muir wrote: > > On 10/28, Chavdar Ivanov wrote: > > After the above message I rebuilt the system and got eventually > > nvmmctl, which worked. I couldn't start any VM, though, so I proceeded > > to rebuild wip/qemu-nvmm, although there were

Re: heads-up: planned changes in nvmm

On 10/28, Chavdar Ivanov wrote: > After the above message I rebuilt the system and got eventually > nvmmctl, which worked. I couldn't start any VM, though, so I proceeded > to rebuild wip/qemu-nvmm, although there were no changes since my > previous build. This time it worked; I also recreated

Re: heads-up: planned changes in nvmm

After the above message I rebuilt the system and got eventually nvmmctl, which worked. I couldn't start any VM, though, so I proceeded to rebuild wip/qemu-nvmm, although there were no changes since my previous build. This time it worked; I also recreated /dev/nvmm (the protection changed from 600

nvmmctl debug file

With the new nvmmctl utility, when building a release with MKDEBUG=yes I get an unexpected file in $DESTDIR/amd64/usr/libdata/debug/usr/sbin/nvmmctl.debug Do you maybe need to add something to $SRC/distrib/sets/lists/debug/*

Re: heads-up: planned changes in nvmm

Le 22/10/2019 à 22:34, Maxime Villard a écrit : [I am not subscribed to this list, so if you want to answer, make sure to CC me.] I will soon commit a set of changes in NVMM, which will require a full rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API, the libnvmm ATF tests,

Re: File sharing over virtio-9p

On Mon, Oct 28, 2019 at 12:29:40 +0900, Ryota Ozaki wrote: > On Fri, Oct 25, 2019 at 11:19 PM Mouse wrote: > > > > > [W]hich of the following is more readable to the user: > > > > > $ ls foo > > > ls: foo: No such file or directory > > > > > or > > > > > $ ls foo > > > ls: stat(foo): No such

Automated report: NetBSD-current/i386 build success

The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2019.10.28.06.26.19 mlelstv src/sys/dev/sdmmc/sdmmc_ioreg.h,v 1.5 2019.10.28.06.31.39 mlelstv src/sys/dev/sdmmc/ld_sdmmc.c,v 1.37

Automated report: NetBSD-current/i386 build failure

This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2019.10.28.06.20.01. An extract from the build.sh output follows: --- kern-LEGACY --- --- auich.o --- #

Re: File sharing over virtio-9p

On Fri, Oct 25, 2019 at 11:19 PM Mouse wrote: > > > [W]hich of the following is more readable to the user: > > > $ ls foo > > ls: foo: No such file or directory > > > or > > > $ ls foo > > ls: stat(foo): No such file or directory > > It depends entirely on the user. > > As I recently wrote on a