[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Implement grub_sleep() and grub_ticksleep()

From: Robert Millan
Subject: Re: [PATCH] Implement grub_sleep() and grub_ticksleep()
Date: Tue, 16 Oct 2007 22:06:47 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Tue, Oct 16, 2007 at 08:46:16PM +0200, Marco Gerards wrote:
> >
> > That's what grub_ticksleep does.  grub_sleep() counts in seconds because
> > I tried to mimic POSIX which seems to be a trend for grub_* functions.  I
> > think it can be used for menu timeout although I didn't have time to look.
> Right.  Although I do not like setting the time in
> GRUB_TICKS_PER_SECOND for millisecond stuff, etc.  In that case
> everyone has to implement the same functionality.

Moved to grub_millisleep().

> > OTOH, this wouldn't be the first place in grub where __i386__ is tested ;-)
> Oh?  Perhaps that code is wrong?

Actually now that I check it's only in one file.  But the code is right afaict.

> >> > +
> >> > +void
> >> > +grub_ticksleep (grub_uint32_t ticks)
> >> > +{
> >> > +  grub_uint32_t end_at;
> >> > +  end_at = grub_get_rtc () + ticks;
> >> > +  while (grub_get_rtc () < end_at)
> >> > +    grub_cpu_idle ();
> >> > +}
> >> 
> >> Why do you recreate this for every arch?  This seems portable as long
> >> as you can sleep a bit from time to time.
> >
> > What if a platform provides a sleep-like mechanism, but not a get_rtc-like
> > one?  You can implement sleep around get_rtc easily, but not the other way
> > around.  This is the case for LB (simply because grub_get_rtc is not
> > implemented yet), but it could also happen on platforms that are designed
> > not to provide it or are just buggy.
> Well, I have no objections to this approach.

Ok.  I made it a bit better by implementing grub_millisleep_generic in
kern/misc.c and making each port just use that, having the option to do it
their way if preferred.

> Are you sure init.c is
> the right place?

Mostly.  I've observed that for code that doesn't obviously belong somewhere
else, it tends to be in init.c if it's in C and startup.S if it's in asm (in
i386/pc/startup.S it actually gets to the extreme, since only a small part of
it is used for "startup" as such).

So I think init.c is fine.

Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Attachment: time.diff
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]