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 bef
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? P
> 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 t
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
miniroot64.fs
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
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
Similar to these commits:
https://marc.info/?l=openbsd-cvs&m=154713176926865&w=2
https://marc.info/?l=openbsd-cvs&m=154814914309779&w=2
Thanks,
Caspar Schutijser
Index: unwinc.d
===
RCS file: /cvs/src/sbin/unwind/unwind.c,v
retriev
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 fr
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 explicitl
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 suppo
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
>
>> 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 condi
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 for
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 kvm_g
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() implementati
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 c
>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
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 e
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,
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?
>> > >
>> > > Sure,
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.
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 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
23 matches
Mail list logo
