widening ticks

The global "ticks" variable counts hardclock ticks, it's widely used in
the kernel for low-precision timekeeping.  The linuxkpi provides a very
similar variable, "jiffies", but there's an incompatibility: the former
is a signed int and the latter is an unsigned long.  It's not
particularly easy to paper over this difference, which has been
responsible for some nasty bugs, and modifying drivers to store the
jiffies value in a signed int is error-prone and a maintenance burden
that the linuxkpi is supposed to avoid.

It would be nice to provide a compatible implementation of jiffies.  I
can see a few approaches:
- Define a 64-bit ticks variable, say ticks64, and make hardclock()
  update both ticks and ticks64.  Then #define jiffies ticks64 on 64-bit
  platforms.  This is the simplest to implement, but it adds extra work
  to hardclock() and is somewhat ugly.
- Make ticks an int64_t or a long and convert our native code
  accordingly.  This is cleaner but requires a lot of auditing to avoid
  introducing bugs, though perhaps some code could be left unmodified,
  implicitly truncating the value to an int.  For example I think
  sched_pctcpu_update() is fine.  I've gotten an amd64 kernel to compile
  and boot with this change, but it's hard to be confident in it.  This
  approach also has the potential downside of bloating structures that
  store a ticks value, and it can't be MFCed.
- Introduce a 64-bit ticks variable, ticks64, and
  #define ticks ((int)ticks64).  This requires renaming any struct
  fields and local vars named "ticks", of which there's a decent number,
  but that can be done fairly mechanically.

Is there another solution which avoids these pitfalls?  If not, should
we go ahead with one of these approaches?  If so, which one?