> The intent was to wait a 30th of a second. In practice it has always
> fired 30ms hence. It's a magic number, so I'd just call it 30ms.
> miod might have an opinion on whether those extra milliseconds would
> be useful in the event that sparc64 is ever able to timeout with
> millisecond or
On Mon, Jan 21, 2019 at 09:05:19PM -0500, Ted Unangst wrote:
> Scott Cheloha wrote:
> > > > diff --git sys/arch/sparc64/dev/fd.c sys/arch/sparc64/dev/fd.c
> > > > index 8d548062f83..654d8c95524 100644
> > > > --- sys/arch/sparc64/dev/fd.c
> > > > +++ sys/arch/sparc64/dev/fd.c
> > > > @@ -1632,7
Scott Cheloha wrote:
> > > diff --git sys/arch/sparc64/dev/fd.c sys/arch/sparc64/dev/fd.c
> > > index 8d548062f83..654d8c95524 100644
> > > --- sys/arch/sparc64/dev/fd.c
> > > +++ sys/arch/sparc64/dev/fd.c
> > > @@ -1632,7 +1632,7 @@ loop:
> > > fdc->sc_state = RECALCOMPLETE;
> > >
On Mon, Jan 21, 2019 at 04:59:38AM +0100, Claudio Jeker wrote:
> On Sat, Jan 12, 2019 at 10:40:35PM -0600, Amit Kulkarni wrote:
> > > [...]
> >
> > Thanks for the feedback Claudio and Mark!
> >
> > Here is a new diff based on your suggestions, [...]
> >
> > diff --git
On Sat, Jan 12, 2019 at 10:40:35PM -0600, Amit Kulkarni wrote:
> > You started to convert the wrong timeout_add() calls. Doing a blind
> > timeout_add() to timeout_add_msec() conversion especially on calls with 0
> > or 1 tick sleep time is the wrong approach.
> > The right approach is to identify
> You started to convert the wrong timeout_add() calls. Doing a blind
> timeout_add() to timeout_add_msec() conversion especially on calls with 0
> or 1 tick sleep time is the wrong approach.
> The right approach is to identify calls that do sleep for a well defined time
> (1sec, 50ms or whatever)
> Date: Sun, 6 Jan 2019 21:46:01 -0600
> From: Amit Kulkarni
>
> > > Even on amd64, I won't be able to test, because of missing hardware.
> > > If you think something is wrong, please will you let me have your
> > > feedback?
> >
> > I'm a bit stunned at the zeal to push untested diffs into the
On Sun, Jan 06, 2019 at 01:43:19PM -0600, Amit Kulkarni wrote:
> Hi,
>
> Referring to the end of mpi's message, and also mlarkin@ later comment
> https://marc.info/?l=openbsd-tech=154577028830964=2
>
> I am trying to replace some easy timeout_add() calls with timeout_add_msec().
>
> My current
> > Even on amd64, I won't be able to test, because of missing hardware.
> > If you think something is wrong, please will you let me have your
> > feedback?
>
> I'm a bit stunned at the zeal to push untested diffs into the tree
>
> (you didn't ask anyone to test it for you)
I requested for
Amit Kulkarni wrote:
> Even on amd64, I won't be able to test, because of missing hardware.
> If you think something is wrong, please will you let me have your
> feedback?
I'm a bit stunned at the zeal to push untested diffs into the tree
(you didn't ask anyone to test it for you)
Even on amd64, I won't be able to test, because of missing hardware.
If you think something is wrong, please will you let me have your
feedback?
Thanks
On Sun, Jan 6, 2019 at 4:56 PM Theo de Raadt wrote:
>
> Amit Kulkarni wrote:
>
> > Hi,
> >
> > Referring to the end of mpi's message, and
Amit Kulkarni wrote:
> Hi,
>
> Referring to the end of mpi's message, and also mlarkin@ later comment
> https://marc.info/?l=openbsd-tech=154577028830964=2
>
> I am trying to replace some easy timeout_add() calls with timeout_add_msec().
>
> My current understanding with the occurences of
Hi,
Referring to the end of mpi's message, and also mlarkin@ later comment
https://marc.info/?l=openbsd-tech=154577028830964=2
I am trying to replace some easy timeout_add() calls with timeout_add_msec().
My current understanding with the occurences of timeout_add() in the tree is
that: if
13 matches
Mail list logo
