public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@clear.net.nz>
To: Pavel Machek <pavel@ucw.cz>, Patrick Mochel <mochel@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] New system device API
Date: Tue, 10 Jun 2003 11:09:29 +1200	[thread overview]
Message-ID: <1055200110.2119.9.camel@laptop-linux> (raw)
In-Reply-To: <20030609220442.GD508@elf.ucw.cz>

Good morning, gentlemen.

Can I bring up an issue a little off topic? Is it currently possible for
us to say 'I want to suspend X but not Y?', and if so how is it done? I
ask because someone recently mentioned the spinning up and down of IDE
during swsusp. That occurs because we can (AFAIK) only say suspend
everything at the moment. It would be good if we could put to sleep
everything except your system devices and the devices used to write the
image while preparing the image, and only suspend the remaining devices
once the image has been written. Is such a thing already implemented?

As an aside, I've gone to a 1.0 pre series for 2.4 swsusp, so it
shouldn't be long before I'm working on 2.5. I've already created
swsusp25.bkbits.net, but nothing is in it at the moment. My intention is
that as I prepare the patches and Pavel says 'That looks ok', I'll add
them to the tree and we can ask Linus to pull from there.

Regards,

Nigel

On Tue, 2003-06-10 at 10:04, Pavel Machek wrote:
> Hi!
> 
> > > Well, can you be a little more concrete? I do not see any description
> > > about what is system device and what is not.
> > > 
> > > Keyboard controller is very deeply integrated into the system. If it
> > > is not system device, what is it?
> > 
> > I apologize that the description of system devices is not in the driver 
> > model documentation. From the linux.conf.au paper:
> > 
> > System-level devices are devices that are integral to the routine
> > operation of the system. This includes devices such as processors,
> > interrupt controllers, and system timers. System devices do not follow
> > normal read/write semantics. Because of this, they are not typically
> > regarded as I/O devices, and are not represented in any standard
> > way. 
> 
> What about mtrr's? They seem like system-level devices to me. Still
> its usefull to have kmalloc in its suspend routine, which moves it to
> SAVE_STATE phase.
> 
> Decision on which level to put it is up to programmer, and it seems
> wrong to hardcode it into architecture. It may be more convient to do
> save stating at place where you still can kmalloc...
> 								Pavel
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

Be diligent to present yourself approved to God as a workman who does
not need to be ashamed, handling accurately the word of truth.
	-- 2 Timothy 2:15, NASB.


  reply	other threads:[~2003-06-09 22:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-07  1:18 [RFC] New system device API Patrick Mochel
2003-06-07 20:33 ` Pavel Machek
2003-06-09 16:19   ` Patrick Mochel
2003-06-09 18:42     ` Pavel Machek
2003-06-09 20:30       ` Patrick Mochel
2003-06-09 21:07         ` Pavel Machek
2003-06-09 21:15           ` Patrick Mochel
2003-06-09 21:23             ` Pavel Machek
2003-06-09 21:40               ` Patrick Mochel
2003-06-09 22:04                 ` Pavel Machek
2003-06-09 23:09                   ` Nigel Cunningham [this message]
2003-06-09 23:16                     ` Pavel Machek
2003-06-09 23:24                       ` Nigel Cunningham
2003-06-09 23:25                         ` Patrick Mochel
2003-06-09 23:26                         ` Pavel Machek
2003-06-09 21:32             ` Pavel Machek
2003-06-09 21:41               ` Patrick Mochel
2003-06-10 18:27               ` Jesse Pollard
  -- strict thread matches above, loose matches on Subject: below --
2003-06-07 10:34 mikpe
2003-06-09 16:18 ` Patrick Mochel
2003-06-09 17:39 mikpe

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=1055200110.2119.9.camel@laptop-linux \
    --to=ncunningham@clear.net.nz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=pavel@ucw.cz \
    /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