[Fwd: Re: [Suspend2-devel] Extent of suspend2 interactions with other kernel systems?]

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[Fwd: Re: [Suspend2-devel] Extent of suspend2 interactions with other kernel systems?]

Karl Hegbloom
FYI...  ;-)

There is a person on the Suspend2 development list (Bojan Smojver) who
is patching a Rawhide kernel 2.6.14-1.1709_FC5 kernel.  I don't know if
he's with the Fedora project or not.  He says that kernel is based on

Nigel Cunningham has been posting incremental patches lately, perhaps
intending to make it easier to maintain a kernel source containing the

I'm finding that the 'hibernate' script works better than the
'acpi-support' hibernate and sleep does.  My Athlon-64 workstation will
hibernate to RAM only with the 'hibernate' script; it fails with stock
'acpi-support' scripts.  I really think that Ubuntu should be using it.
It works with ACPI, the present swsusp, and with the Suspend2 patch.

Also see:




 Suspend2 User-UI for Usplash (in development):


Karl Hegbloom <[hidden email]>

Hi Karl.

On Wed, 2005-11-23 at 23:50, Karl Hegbloom wrote:
> If I have a kernel source, and want to apply the suspend2 patch along
> with some arbitrary set of other patches, what do I need to know wrt how
> suspend2 interacts with other kernel subsystems?

Not much. The main changes that affect other subsystems relate to
freezing kernel threads. Suspend has a different freezer implementation
to the one in the unpatched kernel. It essentially involves modifying
calls to try_to_freeze into try_todo_list, and modifying the creation of
workqueues and kthreads that need to run during suspend (there aren't
many of them) to use nofreeze variants.

> What kinds of patches will need to be fixed up and in what way?  That
> is, patches that affect subsystem X could potentially Z unless you
> ensure that A, B, and C.
> What are the potential conflicts or pitfalls that could occur?
> Where can I read about each thing in the responses to the above?
> When will suspend2 be available via a git repository?  Please?

My general plan is:

- Add last new functionality to Suspend2 (done)
- Bug fix until the only reported problems relate to drivers (in
- Finish preparing the git tree (in progress)
- Seek to get Suspend2 into mm (quite possibly involving another round
of modifications to make X, Y and Z happy).

> I really want to _lobby_ for (and potentially help work on) getting
> Suspend2 into Ubuntu "Dapper Drake", because I know it works better and
> on a wider variety of hardware than the swsusp system.  I know that the
> debate over doing so will tend to come down to Maintainability and
> Stability.

Which is why I'm going for bug fixing too.

> Having the tree in Git will certainly make that maintenance into a much
> more natural process.  It's very difficult to maintain a kernel source
> package where you are continually applying and fixing up a huge patch
> like Suspend2.  How do you upgrade the patch, for instance?  Start over
> with fresh kernel source each time?  That's just totally impossible to
> manage without having Suspend2 in Git, so that incremental changesets
> can be merged at will.  On the stability front, Git would allow a stable
> and development branch to be maintained more easily, so that the
> distributions can ship with known stable releases of Suspend2 in their
> kernels.
I'm hoping that with 2.2, development will pretty much stop. I don't see
anything major that still needs to be added, and so expect the majority
of future changes to be fixing bugs and adapting to new kernel versions.
Oh, I would like to reinstate support for building as modules, but that
shouldn't be a big change since we've had it in the past.



kernel-team mailing list
[hidden email]