Re: [PATCH] turn grub-emu into a port

[Robert Millan <rmh@aybabtu.com>]

On Sat, Oct 31, 2009 at 12:08:55AM +0100, Vladimir 'phcoder' Serbinenko wrote:
> Robert Millan wrote:
> > This turns grub-emu into a port in order to make it easier to port GRUB to
> > new CPUs.  A porter can then do the CPU port without having to worry about
> > firmware and/or hardware drivers initially.
> >
> > Patch attached.  Branch is available in
> > bzr+ssh://bzr.savannah.gnu.org/grub/people/robertmh/grub-emu/
> >
> >   
> Following hunk is a regression for me:
> -  return (tv.tv_sec * GRUB_TICKS_PER_SECOND
> -         + (((tv.tv_sec % GRUB_TICKS_PER_SECOND) * 1000000 + tv.tv_usec)
> -            * GRUB_TICKS_PER_SECOND / 1000000));
> +  GRUB_COMPILE_TIME_ASSERT (GRUB_TICKS_PER_SECOND == 1000000);
> +  return (tv.tv_sec * 1000000 + tv.tv_usec);
> Having virtual clock going at any rate is an advantage for debugging.

I don't get what you mean.  When GRUB runs on a Unix system, a tick
represents a 1000000th fraction of a second, and therefore
GRUB_TICKS_PER_SECOND is 1000000.

The old behaviour tried to emulate the behaviour of the specific hardware
platform, but with grub-emu being a standalone port this doesn't make sense.

I don't think we can have both things (old tick behaviour + portable grub-emu).
Was that behaviour useful?  It seems to me that GRUB routines don't directly
care about number of ticker per second, but rather just use it as a means to
archieve something else.  E.g. to compare output of grub_get_rtc().

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."