Re: [PATCH] mn10300: time: Provide 64-bit persistent clock time

From: John Stultz
Date: Fri Jul 24 2015 - 23:28:15 EST


On Mon, Jul 20, 2015 at 5:45 PM, Xunlei Pang <xlpang@xxxxxxx> wrote:
> From: Xunlei Pang <pang.xunlei@xxxxxxxxxx>
>
> As part of addressing the "y2038 problem" for in-kernel uses,
> convert update_persistent_clock() to update_persistent_clock64(),
> read_persistent_clock() to read_persistent_clock64() using
> timespec64 for MN10300.

The arch changes look ok.


> Add the common weak version of update_persistent_clock() to make
> the compiler happy, since we don't have any update_persistent_clock()
> defined for MN10300 after converting it to update_persistent_clock64().

So it wasn't immediately obvious why this was needed (compiler
unhappiness isn't really a good explanation). Looking at it, it seems
that the weak update_persistent_clock64() wants a
update_persistent_clock() call to exist (which probably should have
been added when the weak update_persistent_clock64 was added). So it
looks like even if the arch defines a update_persistent_clock64(),
the weak one still throws a undefined symbol compiler error, right?

The weak update_persistent_clock() bit should probably be added in a
separate patch, since its not really tied to this arch change (really
any arch that switches to update_persistent_clock64 would have this
issue, no?).

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/