public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Patrick Mochel <mochel@osdl.org>
Cc: "Adam J. Richter" <adam@yggdrasil.com>,
	<linux-kernel@vger.kernel.org>, <eblade@blackmagik.dynup.net>,
	Russell King <rmk@arm.linux.org.uk>
Subject: Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices
Date: 20 Oct 2002 17:57:12 -0600	[thread overview]
Message-ID: <m18z0swtnr.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0210201330380.963-100000@cherise.pdx.osdl.net>

Patrick Mochel <mochel@osdl.org> writes:

> > Mostly I want a comment from Patrick Mochel why he made the change,
> > and roughly what he was thinking.  So I have a good idea about which
> > code I need to dig into and send patches to fix.  If he makes a good
> > case for an independent shutdown, method I am fine with that, just
> > every driver in the kernel needs to change, and that is a heck of a
> > lot of work before 2.6.  Otherwise we can go back to calling remove.
> 
> The main problem is locking and refcounting on the device objects. 
> ->remove() is removing objects from the device tree and freeing them. This 
> is not good when we expect the list to remain intact while we iterate over 
> it. 
>
> This is fine when a device is unplugged or a module is removed, but 
> completely unnecessary during a power transition. Nothing is going away; 
> we're just turning everything off. And, we don't we don't have to mess 
> with getting the list traversal right, since we can assume it's intact. 
 
O.k.  That is very good reason for making the change.

> In short, it's about the data structures, not the hardware. It is going to
> require modification to drivers, but the changes should be small and make
> the code cleaner. It can also happen gradually. There is going to be a lot
> of cleanup of drivers in the coming months as more things are converted to
> exploit the driver model, anyway. 
>> 
> In general, I agree with the patch that you sent later in the thread. I'll 
> apply it, at least for now. 

My big concern is with getting the shutdown path setup in a manner
that works, and gets testing.  When booting linux from linux with
sys_kexec a lot of my problems come back to some device driver not
getting shutdown.

Question, is there a method from the class shutdown code that we
can/should call, during reboot.  I just have this memory that for
network interfaces simply downing the interface tends to put it in
a quiescent state.  And I am wondering if that might be a general
thing we can take advantage of.  Though if the class remove methods
modify the data structures I guess that is out.

Eric

  reply	other threads:[~2002-10-20 23:52 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-20  7:01 Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices Adam J. Richter
2002-10-20  9:17 ` Eric W. Biederman
2002-10-20 20:43   ` Patrick Mochel
2002-10-20 23:57     ` Eric W. Biederman [this message]
2002-10-21 17:13       ` Patrick Mochel
  -- strict thread matches above, loose matches on Subject: below --
2002-10-21 22:26 Adam J. Richter
2002-10-21 20:56 Adam J. Richter
2002-10-22  4:28 ` Eric W. Biederman
2002-10-17  1:50 Adam J. Richter
2002-10-17  9:08 ` Eric W. Biederman
2002-10-15 19:52 Adam J. Richter
2002-10-16 12:13 ` Eric W. Biederman
2002-10-15 18:54 Adam J. Richter
2002-10-15  2:53 Adam J. Richter
2002-10-15 16:59 ` Eric W. Biederman
2002-10-14 18:41 Adam J. Richter
2002-10-14 20:05 ` Eric W. Biederman
2002-10-15  4:55   ` Eric Blade
2002-10-16  8:01 ` Pavel Machek
2002-10-14 15:25 Adam J. Richter
2002-10-14 16:44 ` Eric W. Biederman
2002-10-14 17:48   ` Richard B. Johnson
2002-10-14 19:28     ` Eric W. Biederman
2002-10-14 20:17       ` Richard B. Johnson
2002-10-13 23:59 Adam J. Richter
2002-10-14  0:07 ` Eric W. Biederman
2002-10-14  5:38   ` Eric Blade
2002-10-14 15:28     ` Eric W. Biederman
2002-10-15  4:34       ` Eric Blade
2002-10-13 23:10 Adam J. Richter
2002-10-13 23:15 ` Russell King
2002-10-14  0:03   ` Eric W. Biederman
2002-10-13 23:54 ` Eric W. Biederman
2002-10-13 22:14 Adam J. Richter
2002-10-13 22:31 ` Russell King
2002-10-13 23:49 ` Eric W. Biederman
2002-10-15 16:35 ` Patrick Mochel
2002-10-15 20:04   ` Mikael Pettersson
2002-10-19 18:30   ` Eric W. Biederman
2002-10-20  9:47     ` Eric W. Biederman
2002-10-13 19:24 Adam J. Richter
2002-10-13 19:51 ` Eric Blade
2002-10-13 21:27   ` Eric W. Biederman
2002-10-13 22:52 ` Andries Brouwer
2002-10-14  0:30   ` Eric W. Biederman

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=m18z0swtnr.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=adam@yggdrasil.com \
    --cc=eblade@blackmagik.dynup.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=rmk@arm.linux.org.uk \
    /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