mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Adrian Bunk <bunk@stusta.de>
Cc: Andrew Morton <akpm@osdl.org>, Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC: 2.6 patch] kernel/sys.c: remove unused exports
Date: Sun, 02 Jul 2006 10:52:22 -0600	[thread overview]
Message-ID: <m1ejx47xvd.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060629211807.GH19712@stusta.de> (Adrian Bunk's message of "Thu, 29 Jun 2006 23:18:08 +0200")

Adrian Bunk <bunk@stusta.de> writes:

> On Thu, Jun 29, 2006 at 01:06:33PM -0700, Andrew Morton wrote:
>> On Thu, 29 Jun 2006 21:58:28 +0200
>> Adrian Bunk <bunk@stusta.de> wrote:
>> 
>> > On Thu, Jun 29, 2006 at 12:44:00PM -0700, Andrew Morton wrote:
>> > > On Thu, 29 Jun 2006 12:36:08 -0700
>> > > Andrew Morton <akpm@osdl.org> wrote:
>> > > 
>> > > > On Thu, 29 Jun 2006 21:19:40 +0200
>> > > > Adrian Bunk <bunk@stusta.de> wrote:
>> > > > 
>> > > > > - EXPORT_SYMBOL_GPL's:
>> > > > >   - kernel_restart
>> > > > >   - kernel_halt
>> > > > 

So I can comment on kernel_restart and kernel_halt.
I think I come about as close as it comes to a maintainer
of the reboot infrastructure, and I did write those two functions.

The problem is they were created to address is several different
places in the kernel were performing reboots or halts and
did it inconsistently.  with the result that most localized bug
fixes would trigger a bug in another code path.

At the time the functions machine_halt, and machine_reboot were
exported functions.  So when I did the conversions I preserved
the presence of the export.

After all of the dust settled I think only the swap suspend
code calls into that and that code can't be built modular
so I think removing the exports are ok.

The other places that were calling into these code paths
are now calling emergency_restart().

Enough dust has settled and I can't spot any inappropriate
users in the kernel right now so removing those two exports sounds
fine with me.  We can always add them again if we get modular users.

As long as we are not encouraging people to reinvent this interface
badly again  I have no problems.  If I could think of an appropriate
reason why people would calls these interfaces other than in a watchdog driver
I would worry about people calling emergency_restart when the really wanted
kernel_restart, but didn't because they didn't have the export available.

Eric


  reply	other threads:[~2006-07-02 16:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-29 19:19 Adrian Bunk
2006-06-29 19:36 ` Andrew Morton
2006-06-29 19:44   ` Andrew Morton
2006-06-29 19:58     ` Adrian Bunk
2006-06-29 20:06       ` Andrew Morton
2006-06-29 21:18         ` Adrian Bunk
2006-07-02 16:52           ` Eric W. Biederman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-06-23 10:55 Adrian Bunk
2006-05-16 17:44 Adrian Bunk

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=m1ejx47xvd.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@osdl.org \
    --cc=bunk@stusta.de \
    --cc=gregkh@suse.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome