All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Anders Gustafsson <andersg@0x63.nu>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] machine_reboot and friends
Date: 07 Jun 2003 22:18:48 -0700	[thread overview]
Message-ID: <1055049528.18387.7.camel@nighthawk> (raw)
In-Reply-To: <20030606215159.GB10721@h55p111.delphi.afb.lu.se>

On Fri, 2003-06-06 at 14:51, Anders Gustafsson wrote:
> What if machine_restart/machine_halt/machine_power_off were made
> functionpointers instead? And let the architectures assign to them
> instead of defining the functions? Some architectures are already
> doing this.

We don't usually abstract out architecture features with function
pointers.  The more standard way is with definitions in
architecture-specific files.  Also, the 

               if(machine_restart)
                       machine_restart(NULL);

stuff is fairly messy, and it would probably be preferable to do
something like this instead:

void machine_restart(void)
{
               if(arch_machine_restart)
                       arch_machine_restart(NULL);
}

Then, let the architectures define arch_machine_restart(), and keep tons
of duplicate if()s from being scattered around.

> A bit orthogonal: Different architechtures do different things if the action
> fails (or is unimplemented), some panic, some return, some do "for(;;);",
> isn't it about time someone defined the semantics for these functions?

Not really.  It's architecture specific :)  Some machines simply don't
have a recourse when something that low-level fails.  Is there a case
when something happens that you don't expect?  The three architecures
that I compile for work happily, and as I expect.

-- 
Dave Hansen
haveblue@us.ibm.com


      reply	other threads:[~2003-06-08  5:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-06 21:51 [RFC] machine_reboot and friends Anders Gustafsson
2003-06-08  5:18 ` Dave Hansen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1055049528.18387.7.camel@nighthawk \
    --to=haveblue@us.ibm.com \
    --cc=andersg@0x63.nu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.