Re: Would O_APPEND for /dev/null be possible?

i wrote: |Bryan Drewery wrote: ||On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote: ||> I can open a file with "a+", which, for this software, means ||> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and ||> OpenBSD, but FreeBSD complains, i think because

Re: Would O_APPEND for /dev/null be possible?

and i wrote: ... |The POSIX standard says that the error condition shall be set if |a read or write error occurs only, but this should not be the case |here, no? So looking at [master]:lib/libc/stdio/fseek.c:_fseeko() |(note my machine is not strong enough to compile any compiler (but

Re: r322076 breaks vtnet connectivity

On 08/10/2017 21:27, Ian FREISLICH wrote: > I have a host on Digital Ocean (qemu) and the change in r322076 breaks > my vtnet0 interface. The interface still comes up but does not pass > traffic any more. It's not obvious to my why the changes from r322075 > to r322076 affect the vtnet

[322369] buildkernel failure: error: use of undeclared identifier 'mp_ncpus'

r322369 fails to build a kernel due to: --- mptable.o --- /usr/src/sys/x86/x86/mptable.c:480:39: error: use of undeclared identifier 'mp_ncpus' proc->apic_id < MAX_LAPIC_ID && mp_ncpus < MAXCPU) { ^

Re: [322369] buildkernel failure: error: use of undeclared identifier 'mp_ncpus'

On Thu, Aug 10, 2017 at 9:51 AM, O. Hartmann wrote: > r322369 fails to build a kernel due to: > > > --- mptable.o --- > /usr/src/sys/x86/x86/mptable.c:480:39: error: use of undeclared identifier > 'mp_ncpus' > proc->apic_id < MAX_LAPIC_ID && mp_ncpus <

Re: [autofs] problems with "dirty" UFS2 partitions

On 0808T0717, O. Hartmann wrote: > Hello, > > we're running a NanoBSD based appliance which resides on a small SoC and > utilises a mSATA SSD for logging, database storage and mail folder. The > operating system is recent CURRENT as it is still under development. > > The problem ist, that from

Re: r322076 breaks vtnet connectivity

> Hi > > I have a host on Digital Ocean (qemu) and the change in r322076 breaks > my vtnet0 interface. The interface still comes up but does not pass > traffic any more. It's not obvious to my why the changes from r322075 > to r322076 affect the vtnet interface. > > Ian > Not sure if you have

r322076 breaks vtnet connectivity

Hi I have a host on Digital Ocean (qemu) and the change in r322076 breaks my vtnet0 interface. The interface still comes up but does not pass traffic any more. It's not obvious to my why the changes from r322075 to r322076 affect the vtnet interface. Ian -- Ian Freislich -- Cape

Re: I have submitted bugzilla 221107 for a (e.g.) -r321706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol

[A top post about the failing R_PPC_PLTREL24 since the material does not flow well as a sequential read from prior material. I found that the .kld does not match the contributing .o for GLOBAL status for routines and the LOCAL in the .kld is rejected by ld in ppc_elf_check_relocs.] There is

Re: I have submitted bugzilla 221107 for a (e.g.) -r321706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol

[clang 5 generates R_PPC_PLTREL24 in the .o files for global symbols in places gcc 4.2.1 generates R_PPC_ADDR16_HA / R_PPC_ADDR16_LO pairs.] On 2017-Aug-10, at 7:22 PM, Mark Millard wrote: > [A top post about the failing R_PPC_PLTREL24 since > the material does not flow well as a sequential >