mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: kernel list <linux-kernel@vger.kernel.org>
Subject: Merging swsusp
Date: Sun, 12 Sep 2004 23:00:11 +0200	[thread overview]
Message-ID: <20040912210011.GA3322@elf.ucw.cz> (raw)

Hi!

Configuration of my provider changed and now I'm in blacklist. Anyway,
it looks like swsusp2 is closer to merge...

...
<ncunningham@linuxmail.org>: host linuxmail-org.mr.outblaze.com[205.158.62.52]
    said: 554 EMail from mailserver at 160.218.40.135 is refused. See
    http://spamblock.outblaze.com/160.218.40.135 (in reply to RCPT TO command)
...

Hi!

> At long last I'm approaching readiness for merging. I have a patch still
> to apply to this tree and some functional rearrangement of patches to
> do, but I've got the following at the moment. Is it the sort of thing
> you want to see? I plan to submit the patches in groups:
> 
> 1. Little patches that pass on fixes submitted by various people (giving
> credit of course): ati-agp, ne2k, ali5451, alps for example.
> 2. Refrigerator improvements (workthreads, refrigerator proper,
> proccess.c replacement).
> 3. New exports for building suspend as modules.
> 4. Nosave improvements in mm init.
> 5. New code to disable mce, slab reap, oom killer etc while suspending
> (things the mess up a two-step image save/restore or should otherwise be
> put on ice) and to add hooks for suspend.
> 6. Arch specific lowlevel code (currently mac/ppc and x86. x86_64 to
> follow shortly).
> 7. Always-built-in suspend code.
> 8. Suspend core module.
> 9. Suspend user interface modules.
> 10. Suspend compression modules (encryption also planned).
> 11. Suspend image writer modules (generic file writer planned).
> 12. Documentation patches.

Looks good.

> I'm sure that there will be plenty of suggestions as to how I can do
> things better, so I'm not deluding myself into thinking this will all be
> accepted immediately. Nevertheless, I want to get your initial thoughts.
> By the way, will this be too many/too large to post to LKML as well?

I believe it should be okay on linux-kernel. Individual patches are
quite small.
								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


----- End forwarded message -----

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

                 reply	other threads:[~2004-09-12 21:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20040912210011.GA3322@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --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

all inboxes | Powered by JetHome®