> On Mon, 16 Aug 1999, Gerard Roudier wrote:
> >
> > Why is jiffies type still 'unsigned long', given that all calculations
> > that try to be not too wrong with wrap-around just cast timer values to
> > signed long?
>
> Why not?
>
> You shouldn't really do compares on it anyway, so the type doesn't matter.
> And to me, "unsigned" makes much more sense for time as it is implemented
> in the kernel - it never goes negative, but it can wrap. That's basically
> what "unsigned" means.
Indeed. I missed that.
> Also the C standard actually guarantees nice wrapping behaviour for
> unsigned, something it doesn't guarantee for signed values. So as long as
> you're working with wrapping values, you should always use unsigned. We
> then at the last possible moment know that we're playing with a two's
> complement machine, and that's where we do the signed cast to test the
> high bit to make it easy on the compiler, but you could conceptually think
> of it as a test for the high bit (which is portable C) rather than as a
> test for the sign (which is _not_ portable C, but nobody cares because
> nobody sane does anything but two's complement).
And this one too. :)
> So I really don't see the point of trying to change the type to anything
> else or trying to hide it with some random new typedef that doesn't buy
> you anything in real life. Don't abstract things away unless you get some
> real _advantage_ from the abstraction, and I don't see the advantage.
I just ran 'grep jiffies `find . -name "*.c"` on 2.3.13 tree and the
result was 168909 bytes / 2419 lines.
Not all the lines involve jiffies explicitely in arithmetic expressions
but a large part of the lines do. Probably most are correct, but it would
be a nightmare to check all that stuff for a human.
There were some other proposals in my posting that allow to avoid to deal
explicitely with jiffies and arithmetic expression involving kernel time
values. They are pretty simple and trivial macros I will use to make the
drivers I maintain jiffies-safe (modulo the right type for kernel time
I missed).
By the way, I didn't propose to incorporate these tiny and trivial stuff
in the kernel main stream, but just asked if they were acceptable by the
kernel maintainers if I actually use them.
Thanks a lot for you answer.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/