On Sun, May 17, 2020 at 02:20:08PM +1000, Jonathan Gray wrote:
> On Sat, May 16, 2020 at 12:13:37PM -0700, jo...@armadilloaerospace.com wrote:
> > (Not sure if this belongs in tech@ or misc@)
>
> I think tech@ is fine for discussion of code.
>
> >
> > What is the thinking around non-functional
On Sun, May 17, 2020 at 04:32:33PM +0200, Denis Fondras wrote:
> On Fri, May 15, 2020 at 11:34:58AM +0100, Richard Chivers wrote:
> > Hi,
> >
> > I have now resolved the spacing/tabbing issues I think correctly
> > following style(9), along with a couple of other indent issues.
> >
> > Would
> For instance, in the wsdisplay_emulops structure, there are:
>
> int (*alloc_attr)(void *c, int fg, int bg, int flags, long *attrp);
> void (*unpack_attr)(void *c, long attr, int *fg, int *bg, int *ul);
>
> And at the end of the structure is this comment, showing that at
> least someone
On Mon, May 18, 2020 at 09:04:06AM +0200, Claudio Jeker wrote:
> There is a file missing in the diff.
>
> One thing I have seen in the original diff from Richard was that the
> copyright in the new file should be copied from ospfctl.c since this is
> mostly a copy paste action and not new work.
>
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
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?
>
> -Otto
>
And now with diff
Index:
On Sun, May 17, 2020 at 09:49:54AM -0700, Andrew Hewus Fresh wrote:
> I think this patch is now cleaned up enough to look for OKs.
OK bluhm@
> The patch to numeric.c works around an issue with clang and
> -Wdeclaration-after-statement that was fixed more correctly upstream,
> but pulling in the
On Sat, May 16, 2020 at 07:23:37PM -0400, sven falempin wrote:
> This was looked at before.
> Did not get through.
The posted diff was not my final solution. But yes, the issue was
forgotten. So I would suggest this.
When DNS lookup of an UDP loghost failed, syslogd(8) did close the
UDP
On Mon, May 18, 2020 at 09:49:24AM +0200, Denis Fondras wrote:
> On Mon, May 18, 2020 at 09:04:06AM +0200, Claudio Jeker wrote:
> > There is a file missing in the diff.
> >
> > One thing I have seen in the original diff from Richard was that the
> > copyright in the new file should be copied from
On Sat, May 16, 2020 at 02:24:45PM +0200, Christian Weisgerber wrote:
> Tobias Heider:
>
> > currently iked(8) supports AES-GCM only for ESP.
> > The diff below adds the ENCR_AES_GCM_16 and ENCR_AES_GCM_12 variants for
> > IKE.
> > (for more information see [1] and [2]).
> > Both variants
Anyone feeling like trimming a little fat?
On Fri, 2020-05-08 at 11:41 +0200, Martijn van Duren wrote:
> Diff below removes fields from struct oid used by snmpd but not useful
> for snmp(1). Minus 503LoC and -200kb on installed binary.
> No functional change intended.
>
> OK?
>
> martijn@
>
>
Diff below changes the internal of *poll(2) and *select(2) to use the
*_kqfilter() handlers instead of *_poll() ones. Events are stored on a
private per-thread kqueue then converted to the corresponding "fd_set"
or "pollfd". The design is similar to DragonFly's solution.
The main argument for
Ok, that works -- I could not tell what that parsing code did in
wsconsctl, and I thought the scaling code in wscons only got applied to
touchpads.
In that case, how about just allowing wsconsctl to accept mouse.speed as
a special floating point parameter that sets both the DX and DY scales
Hi John,
you can slow down mice via wsconsctl, but this possibility is "hidden"
in a debug and testing interface.
You have seen the WSMOUSECFG_D*_SCALE parameters, two parameters in
*.12 fixed-point format that determine the scaling of DX- and DY-deltas.
You can read the values with
$
rpki-client 6.7 has just been released and will be available in the
rpki-client directory of any OpenBSD mirror soon.
rpki-client is a FREE, easy-to-use implementation of the Resource
Public Key Infrastructure (RPKI) for Relying Parties (RP) to
facilitate validation of the Route Origin of a BGP
sparc64 has used the MI mutex since year 2018. However, the MD code
still exists. The diff below removes it.
OK?
Index: arch/sparc64/sparc64/mutex.S
===
RCS file: arch/sparc64/sparc64/mutex.S
diff -N arch/sparc64/sparc64/mutex.S
---
On Mon, May 18, 2020 at 01:20:07PM -0400, Kurt Mosiejczuk 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 created by
Hi,
We could do with exposing certain metrics from bgpd, ospfd and pf.
I was considering a couple of approaches and really was just
interested in what would make most sense in general.
Has anyone else considered this at all?
Would this be useful to anyone else?
Also just to say I am not
On Mon, May 18, 2020 at 04:16:05PM +0100, Stuart Henderson wrote:
> On 2020/05/18 15:31, Richard Chivers wrote:
> > Hi,
> >
> > We could do with exposing certain metrics from bgpd, ospfd and pf.
> >
> > I was considering a couple of approaches and really was just
> > interested in what would
I suspect there are other inconsistancies in all these versions.
./usr.sbin/dvmrpd/in_cksum.c
./usr.sbin/eigrpd/in_cksum.c
./usr.sbin/ospfd/in_cksum.c
./usr.sbin/tcpdump/in_cksum.c
./sys/arch/alpha/alpha/in_cksum.c
./sys/arch/arm/arm/in_cksum_arm.S
./sys/arch/hppa/hppa/in_cksum.c
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
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 created by default from 8 to 16.
ok?
--Kurt
Index: MAKEDEV
> 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 created by default from 8 to 16.
>
> ok?
MAKEDEV is a generated file.
Thanks for the comments, some good things to think about.
Out of interest, can anyone think of some good examples of daemons which
call ctl commands, just wanting to review the patterns and approach, and
what is the best, best practice examples today.
On Mon, 18 May 2020, 16:46 Theo de Raadt,
> > ./usr.sbin/eigrpd/in_cksum.c
>
> This one uses unsigned char instead of u_char, but is otherwise the same
> as dvmrpd/ospfd.
Should probably be made identical.
On Mon, May 18, 2020 at 05:50:28PM +0200, Claudio Jeker wrote:
> On Mon, May 18, 2020 at 03:50:05PM +0200, Patrick Wildt wrote:
> > Hi,
> >
> > I was trying to tftpboot and had an issue with files of odd-length.
> > As it turns out, I think the in_cksum() that's called for UDP payload
> > cannot
On Mon, May 18, 2020 at 10:16:27AM -0600, Theo de Raadt wrote:
> I suspect there are other inconsistancies in all these versions.
>
> ./sys/arch/arm/arm/in_cksum_arm.S
> ./sys/arch/i386/i386/in_cksum.s
> ./sys/arch/sparc64/sparc64/in_cksum.S
> ./sys/arch/sh/sh/in_cksum.S
These are assembly and
On Thu, May 14 2020, Stefan Sperling wrote:
> The capablities info field in an association request contains an ESS bit
> which is set if the sender is an access point (there are other cases but
> they don't matter for us; see 802.11-2012 8.4.1.4 if you are interested).
>
> This bit is set when
On Sun, May 17, 2020 at 04:45:44PM +0200, Matthias Schmidt wrote:
> I have your diff running since yesterday and noticed no regression.
>
> iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
> iwm0: hw rev 0x230, fw ver 34.0.1
>
> Cheers
>
> Matthias
Great,
Hi,
I was trying to tftpboot and had an issue with files of odd-length.
As it turns out, I think the in_cksum() that's called for UDP payload
cannot handle a payload length that's not aligned to 16 bytes.
I don't know how in_cksum() is supposed to work exactly, but it looks
like the first step
On 2020/05/18 15:31, Richard Chivers wrote:
> Hi,
>
> We could do with exposing certain metrics from bgpd, ospfd and pf.
>
> I was considering a couple of approaches and really was just
> interested in what would make most sense in general.
>
> Has anyone else considered this at all?
>
> Would
On Mon, May 18, 2020 at 02:46:52PM +0100, Richard Chivers wrote:
> Hi,
>
> Thanks for the feedback, I wasn't happy with the detail flag either, I
> just missed coming back to rethink / change it.
>
> There was a lot of duplicate code i seem to remember, as much of the
> output is sent
Hi,
Thanks for the feedback, I wasn't happy with the detail flag either, I
just missed coming back to rethink / change it.
There was a lot of duplicate code i seem to remember, as much of the
output is sent regardless.
I will take a look over the next couple of days when I get a few
minutes to
On Mon, May 18, 2020 at 03:50:05PM +0200, Patrick Wildt wrote:
> Hi,
>
> I was trying to tftpboot and had an issue with files of odd-length.
> As it turns out, I think the in_cksum() that's called for UDP payload
> cannot handle a payload length that's not aligned to 16 bytes.
>
> I don't know
This diff converts octrtc(4) to use the interface,
to reduce use of .
Some highlights for reviewing:
* dt.dt_year contains the actual year, while tt->year has base 1900.
* dt.dt_wday uses range 0-6, whereas tt->dow's range is 1-7.
* octrtc_gettime() no longer extracts day of week because
Claudio Jeker wrote:
> Last note, please do not try to directly talk to the daemons always pass
> via the *ctl program. The API used between for example bgpd and bgpctl
> is not public and also not stable. It requires that both tools are in
> sync.
There is an additional reason for doing this.
It took me far too long to figure out how to do this, and I seem to
have found this patch when trying to figure it out again but a year
later I've forgotten how I figured it out.
I'm sure I messed up the formatting terribly, but being able to remember
`:.,'cs/foo/bar/` by looking in the manual
Hello Jonathan,
I think it makes sense to turn it on on inbound path. we certainly
get a performance boost if HW verifies header checksums for us.
I'm not sure about outbound path. chksum offload on outbound side got killed
back in 2016 (I think). All that logic behind dealing with various HW
So far I've completely ignored offloads in the ethernet drivers I've
written, but on having a quick look at the documentation I found that
mcx(4) checksum offload is extremely easy to use, and some simple testing
suggests that it helps quite a bit. I've seen tcpbench receive throughput
increase
Hi Andrew,
Andrew Hewus Fresh writes:
> I'm sure I messed up the formatting terribly, but being able to remember
> `:.,'cs/foo/bar/` by looking in the manual would make me happy.
Yes, this is one of those useful things that's documented elsewhere but
should be in the manpage.
This is more fully
40 matches
Mail list logo
