[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] turn grub-emu into a port
From: |
Robert Millan |
Subject: |
Re: [PATCH] turn grub-emu into a port |
Date: |
Sat, 31 Oct 2009 11:06:26 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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."