pause_ms() wrapper

[Adrian Chadd]

Can we please name it something that indicates it's not designed to be exact?

The .. exactness of various calls has been a thorn in the side of a
few people, myself included. I've been bitten by the callout precision
changes :(

I like linux's usleep_range() for example. It makes it obvious that
you can get anything inside that bar. How hard is that to do with
pause_sbt() ?


-adrian


On 2 September 2016 at 12:22, John Baldwin <jhb at freebsd.org> wrote:
> Figuring out the 3 arguments required for pause_sbt() can be a bit
> non-obvious (at least to me).  To that end, I'd like to have a simple
> wrapper around pause_sbt() that accepts milliseconds.  It would align
> itself on hardclock similar to the hz-based wrapper.  OTOH, we could
> change the implementation at some point to use something more resaonable
> in terms of precision, etc.  However, most of the time when I want to
> sleep for N milliseconds (or N microseconds) due to some hardware spec,
> I don't really have a strong opinion on the precision.  Having all the
> callers try to figure out a precision would seem to inevitably result
> in inconsistencies.  To start with I'd like to just add this:
>
> #define pause_ms(wmesg, msecs)                                          \
>         pause_sbt((wmesg), SBT_1MS * (msecs), 0, C_HARDCLOCK)
>
> Which you can use as 'pause_ms("pcieflr", 100);'.
>
> Are there any objections?  Do people want other wrappers?  Should we
> use more nuanced math similar to what was done in r296775?
>
> --
> John Baldwin
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"