On Sat, 15 Sep 2018, Thomas Gleixner wrote:
> >
> > So reverting this is not really an option.
> Maybe we can :)
Thanks for checking into this more. We've been looking at the uses you
described, and hopefully we can have something to submit for review (or at
least discuss) relatively soon.
>
On Thu, 6 Sep 2018, Thomas Gleixner wrote:
> On Wed, 5 Sep 2018, Rick Ratzel wrote:
>
> > We're looking for suggestions on how best to proceed with a new change
> > that ideally both supports the use case described above, as well as
> > addresses the symptoms brought up in the initial commit (nega
Rick,
On Wed, 5 Sep 2018, Rick Ratzel wrote:
> We're looking for suggestions on how best to proceed with a new change
> that ideally both supports the use case described above, as well as
> addresses the symptoms brought up in the initial commit (negative boot
> time causes get_expiry() to overfl
Hello,
We have a use case that was broken by the commit e1d7ba873555 (time: Always
make sure wall_to_monotonic isn't positive). We've been reverting the commit
in our builds, but we'd greatly prefer a solution consistent with the mainline.
We also think our use case isn't unique to us, and ma
4 matches
Mail list logo
