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." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
