Re: sparse warning, or why does jifies_to_msecs() return an int?

[Nish Aravamudan <nish.aravamudan@gmail.com>]

On 1/14/05, David Mosberger <davidm@napali.hpl.hp.com> wrote:
> I'm seeing the following warning from sparse:
> 
> include/linux/jiffies.h:262:9: warning: cast truncates bits from constant value (3ffffffffffffffe becomes fffffffe)
> 
> it took me a while to realize that this is due to
> the jiffies_to_msecs(MAX_JIFFY_OFFSET) call in
> msecs_to_jiffies() and due to the fact that
> jiffies_to_msecs() returns only an "unsigned int".
> 
> Is there are a good reason to constrain the return value to 4 billion
> msecs?  If so, what's the proper way to shut up sparse?

Is there any logical reason to need longer than 46 days of
milliseconds? I mean, sure, we could support years in milliseconds,
but why  :) ? If you need longer, specify in seconds. Or add an
interface which does days :) I think it's perfectly reasonable to
constrain time units representative storage in the following manner:

seconds: unsigned int
milliseconds: unsigned int
microseconds: unsigned long
nanoseconds: u64

These are the assumptions I have made in my timeofday-based soft-timer
rework, for what it's worth.

I will look into all the math, though, as all the conversions need to
be accurate for my rework (to support existing interfaces).

Thanks,
Nish