Scott Cheloha wrote:
> > On Jan 24, 2019, at 06:19, Lauri Tirkkonen wrote:
> >
> > [...]
> >
> > I haven't done any actual measurements though, so it's possible my
> > reading is wrong.
>
> Is there a "grepbench" or canonical corpus we can use to get a 95%
> CI on this and future changes?
Hi,
simplified diff from my last mail, only adding speed & altitude, now
with 100% less floating point in the kernel !
Use a #define KNOTTOMS (51444 / 100) instead of the wrong (1000 / 1.9438)
formula to convert from thousands of knots (nmea_atoi() returns an
integer which takes 3 extra digits
On Thu, Jan 24, 2019 at 03:56:17PM +0800, Kevin Lo wrote:
>
> First off, thanks for the diff. Right, urtwn(4) doesn't see any control
> frames in monitor mode, I think we also need to set R92C_RCR_ADF,
> R92C_RCR_ACF,
> and R92C_RCR_AMF bits in R92C_RCR to accept data/ctrl/mgmt frames
The tail end of make release on arm64 looks like this:
...
===> arm64/miniroot
cp miniroot64.fs /home/rel-arm64
su build -c 'exec make sha'
cd /home/rel-arm64; date -u "+Build date: %s - %+" > BUILDINFO; cksum -a
sha256 BUILDINFO INSTALL.`arch -ks` bsd bsd.mp bsd.rd BOOTAA64.EFI
configparser.c is left behind when running "make clean". You may want
to indent the assignments in the lines above to make it look nicer.
Best regards,
Caspar Schutijser
Index: Makefile
===
RCS file: /cvs/src/sbin/unwind/Makefile,v
Fix typo.
Best regards,
Caspar Schutijser
Index: resolver.c
===
RCS file: /cvs/src/sbin/unwind/resolver.c,v
retrieving revision 1.3
diff -u -p -U5 -r1.3 resolver.c
--- resolver.c 24 Jan 2019 15:33:44 - 1.3
+++ resolver.c
> On Jan 24, 2019, at 06:19, Lauri Tirkkonen wrote:
>
> [...]
>
> I haven't done any actual measurements though, so it's possible my
> reading is wrong.
Is there a "grepbench" or canonical corpus we can use to get a 95%
CI on this and future changes? People talk about grep(1) perf. like
CPU
Similar to these commits:
https://marc.info/?l=openbsd-cvs=154713176926865=2
https://marc.info/?l=openbsd-cvs=154814914309779=2
Thanks,
Caspar Schutijser
Index: unwinc.d
===
RCS file: /cvs/src/sbin/unwind/unwind.c,v
retrieving
On Thu, Jan 24 2019 18:08:25 -0600, Scott Cheloha wrote:
> not to be standoffish, I'm just travelling so I can't really look into it.
yeah, it's not like I have infinite time either. I'll try to do
something with this over the weekend but no promises.
> if you came forward with malloc numbers
Since introduction in 2007, `disable' has been unused. Looking at
iwm(4) shows a simple `void iwm_stop(struct ifnet *)' as well.
OK?
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.205
diff -u -p
On Thu, Jan 24, 2019 at 10:28:56AM +0100, Klemens Nanni wrote:
> Since introduction in 2007, `disable' has been unused. Looking at
> iwm(4) shows a simple `void iwm_stop(struct ifnet *)' as well.
>
> OK?
Yes. This has always bothered me.
I just never got around to removing it.
On Wed, Jan 23, 2019 at 09:50:18AM +0100, Jesper Wallin wrote:
>
> Hi,
>
> This patch will allow urtwn(4) to see control frames when monitor mode
> is enabled. I've only tested this with my TP-LINK TL-WN821N v5 card, so
> perhaps more checks are needed to avoid breaking other cards.
>
> If you
just a comment:
drivers with firmware have often had special parameters to the stop or
reset functions to indicate a difference between "stop moving traffic"
or "shut it all down". We seem to keep switching this back and forth.
Reason is we've had some very bizzare failure conditions in drivers,
On Thu, Jan 24 2019 04:22:20 -0700, Theo de Raadt wrote:
> I would like to know if this does more malloc. I worry it is an additional
> level of malloc per line.
It does do more malloc than plain fgetln since fgetln does no copying,
but nowhere near every line. The same buffer lnbuf is used for
On Thu, Jan 24 2019 04:40:08 -0700, Theo de Raadt wrote:
> >On Thu, Jan 24 2019 04:22:20 -0700, Theo de Raadt wrote:
> >> I would like to know if this does more malloc. I worry it is an additional
> >> level of malloc per line.
> >
> >It does do more malloc than plain fgetln since fgetln does no
On Thu, Jan 24 2019 13:58:04 +0200, Lauri Tirkkonen wrote:
> And even then I think the cost is negligible: getline grows
> the buffer in powers of 2, so only lines that happen to be twice as long
> as any previously encountered line pay the price.
Actually, I went to skim the fgetln()
>On Thu, Jan 24 2019 04:22:20 -0700, Theo de Raadt wrote:
>> I would like to know if this does more malloc. I worry it is an additional
>> level of malloc per line.
>
>It does do more malloc than plain fgetln since fgetln does no copying,
>but nowhere near every line. The same buffer lnbuf is
>> just a comment:
>>
>> drivers with firmware have often had special parameters to the stop or
>> reset functions to indicate a difference between "stop moving traffic"
>> or "shut it all down". We seem to keep switching this back and forth.
>> Reason is we've had some very bizzare failure
I would like to know if this does more malloc. I worry it is an additional
level of malloc per line.
>On Wed, Jan 23 2019 18:01:24 -0500, Ted Unangst wrote:
>> Lauri Tirkkonen wrote:
>> > > > oh, interesting. that's sloppy. can you please fix that first,
>> > > > separately?
>> > >
>> > >
ping
On 11/19/18 6:29 PM, Martijn van Duren wrote:
> So I hacked this together because I got annoyed by the fact that for
> every pid I want to investigate I had to rerun fstat.
>
> Diff below alleviates the searched pid from kvm_getfiles(3) to fstat(1).
> I left atomicity (is there any in
On Thu, Jan 24, 2019 at 04:35:02AM -0700, Theo de Raadt wrote:
> just a comment:
>
> drivers with firmware have often had special parameters to the stop or
> reset functions to indicate a difference between "stop moving traffic"
> or "shut it all down". We seem to keep switching this back and
On Wed, Jan 23, 2019 at 05:55:54PM -0500, Ted Unangst wrote:
> Stuart Henderson wrote:
> > On 2019/01/22 21:46, Ted Unangst wrote:
> > > The persist feature in doas (actually the kernel side implementation) has
> > > some
> > > additional checks. The idea was to prevent accidental usage, but in
On Wed, 23 Jan 2019 17:55:54 -0500, "Ted Unangst" wrote:
> Is make creating a second process group? I guess it is for job control? Need
> to find a place to stick the verauth flag such that later doas can find it...
The shell creates a new process group when running commands for job
control
23 matches
Mail list logo
