On Sun, Feb 16, 2020 at 12:23:40AM +0100, Klemens Nanni wrote:
> On Sat, Feb 15, 2020 at 10:30:52PM +, Jason McIntyre wrote:
> > from a practical point of view, is there a reason to say when expansion
> > happens? by this i mean, what (if any) difference does it have for the
> > user - they
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
In order to fix a speculative execution issue on various ARM CPUs, the
OpenBSD/arm64 system call ABI has been changed. System calls now skip
the two instructions immediately following the system call
instruction. This allows us to insert a barrier that blocks the CPU
from speculating further
The closing of a file can be a complex operation, and hence it would be
good to hold as few locks as possible when calling closef(). In
particular, the code behind close(2) already releases the file
descriptor table lock before closef(). This might not be strictly
necessary when the type of the
On Fri, Feb 14, 2020 at 08:56:25PM +0100, Klemens Nanni wrote:
> I'm experiencing some issues with iked(8) and the first one took
> me much longer than appreciated: order of commands matters.
iked/iked.conf is not special, ipsecctl/ipsec.conf obviously has it, too.
So while the problem of
On Sun, Feb 16, 2020 at 06:35:10AM +0100, Theo Buehler wrote:
> I don't think this patch is correct.
>
> The vmctl part contradicts the "LOCAL INTERFACES" section, which
> explains how the addresses are calculated and also states:
>
> Multiple -L options can be provided to the 'vmctl start'
Reading it for the first time, I thought `mynetworks' is special and
that's why it has these line continuations, but it's not and the example
looks much nicer without.
The `bogons' block directly following doesn't use it, either.
Feedback? OK?
Index: etc/examples/bgpd.conf
On Sun, Feb 16, 2020 at 09:25:51PM +0100, Klemens Nanni wrote:
> Going through the example with bgpd.conf(5) side by side, jumping to the
> "group" tag shows
>
> group descr Neighbors in this group will be matched.
> AS as-number
>Neighbors with this AS will be
On Sun, Feb 16, 2020 at 09:47:43PM +0100, Ingo Schwarze wrote:
> Sure. I'm not convinced you even need OKs for such simple tagging
> corrections.
>
> By the way, just
>
> .Tg
> .Ic neighbor
>
> .Tg
> .Ic group
>
> is sufficient, the .Tg macro defaults to the first argument of the
Going through the example with bgpd.conf(5) side by side, jumping to the
"group" tag shows
group descr Neighbors in this group will be matched.
AS as-number
Neighbors with this AS will be matched.
...
which is somewhere in the manual that assumes
Hi Klemens,
Klemens Nanni wrote on Sun, Feb 16, 2020 at 09:32:52PM +0100:
> On Sun, Feb 16, 2020 at 09:25:51PM +0100, Klemens Nanni wrote:
>> Going through the example with bgpd.conf(5) side by side, jumping to the
>> "group" tag shows
>>
>> group descr Neighbors in this group will be
jan@ found some issues with this diff during u2k20.
Here's an updated diff. Changes since previous diff are:
- If we don't know the protocol yet, we can't assume a port is
specified.
- If we can create a ip6? socket don't wait to connect until we're out
of the loop.
It passes everything I've
On Sat, Feb 15, 2020 at 09:42:53PM +0100, Martin Pieuchot wrote:
> On 15/02/20(Sat) 16:56, Visa Hankala wrote:
> > When I added the knote_acquire() call in kqueue_register(), I overlooked
> > the fact that the knote could be modified by a (soft) interrupt.
> > Interrupts have to be blocked when
On 14.2.2020. 18:28, Martin Pieuchot wrote:
> I'm running this on:
>
> em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi
> em0 at pci0 dev 20 function 0 "Intel I354 SGMII" rev 0x03: msi
>
> More tests are always welcome ;)
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev
On 2/17/20 8:12 AM, Martijn van Duren wrote:
> jan@ found some issues with this diff during u2k20.
> Here's an updated diff. Changes since previous diff are:
> - If we don't know the protocol yet, we can't assume a port is
> specified.
> - If we can create a ip6? socket don't wait to connect
On Sat, Feb 15, 2020 at 11:37:12AM +0100, Denis Fondras wrote:
> 3 changes in rde_lsdb.c
> - lsa_find_lsid() has redondant parameters
> - call to lsa_self() can be simplified (== ospfd)
> - update debug messages to be more suitable
>
ok remi@
> Index: rde.c
>
16 matches
Mail list logo