Kernel Summit 2006: Software suspend

Posted Jul 18, 2006 21:51 UTC (Tue) by NCunningham (guest, #6457)
In reply to: Kernel Summit 2006: Software suspend by maks
Parent article: Kernel Summit 2006: Software suspend

Yes, Rafael's fixes have helped.

It's not so much that I like my 'out of tree playfield', as that dealing
with Pavel is a pain. For some reason, we just don't get along, and
submitting patches to him is like banging your head against a brick wall.
Noone is going to want to try that for long.

But he had the foresight and understood the process well enough to fork
swsusp and get the fork merged when it was still beta software, whereas I
ignorantly thought it was best to get it working properly and well before
merging.

Given the above, I don't know what the way ahead is from here, but if
someone wants to suggest one (and it doesn't kill me in the process :>),
I'm willing to listen.

to post comments

Kernel Summit 2006: Software suspend

Posted Jul 18, 2006 22:32 UTC (Tue) by maks (guest, #32426) [Link] (1 responses)

> Given the above, I don't know what the way ahead is from here, but if
> someone wants to suggest one (and it doesn't kill me in the process :>),
> I'm willing to listen.

the hole suspend2 base is much to huge to get gobbed on once. even ubuntu cares about driver fixes these days.

concerning pavel i remember him merging 2 bad in kernel solutions to one,
that was already a very good start.

you have been last year in locked in one room. the advise gregkh and others have most probably given is incremental improvements on the in kernel solution. make out of swsusp and suspend2 a great in tree suspend3 :)

Kernel Summit 2006: Software suspend

Posted Jul 18, 2006 23:11 UTC (Tue) by bojan (subscriber, #14302) [Link]

> the hole suspend2 base is much to huge to get gobbed on once. even ubuntu cares about driver fixes these days.

Split Suspend2 patches were posted to LKML recently. Sure, there were real technical complaints from people that actually reviewed the patches - all of these are being addressed as I understand, with some of the stuff already done.

Unfortunately, some other developers have chosen to repeat myths about Suspend2 instead of actually reviewing the code. Like: don't have userui in kernel - it hasn't been there for a while. Or: can you remove crytpo/compression - well, ignore two files from the patch etc. I guess Nigel is right when he says that the initial invasive nature of Suspend2 patches is still lingering in the air, although it hasn't been true for a while now.

> make out of swsusp and suspend2 a great in tree suspend3

Well, that would be a great outcome. However, it seems that it isn't going to happen. Current suspend subsystem maintainer wants to keep the in-kernel code (mostly) the way it is to reduce complexity. I was under the impression that Linux kernel has gone way past that point (i.e. of being really simple) with the introduction of many advanced features, but then again I don't know the code of it, so I'm probably wrong.

Kernel Summit 2006: Software suspend

Posted Jul 19, 2006 16:55 UTC (Wed) by christian.convey (guest, #39159) [Link] (2 responses)

I suggest looking for a sequence of patches that would be made to the tree, that would ultimately result in the code looking exactly as you want.

For example, first try to submit patches that provide the front-end that you want, but that works on swsup. Second, ensure the drivers are up to snuff. Finally, now that the differences between the in-tree code and your ideal are small, provide patches that finish the job.

The key here is that you ensure every patch is desirable to the kernel maintainers even if they're not committed to making suspend2 be tge standard. Just a thought. I'm not a kernel maintainer, but I do believe this general approach works well in the research field.

Kernel Summit 2006: Software suspend

Posted Jul 19, 2006 20:02 UTC (Wed) by bojan (subscriber, #14302) [Link] (1 responses)

> Second, ensure the drivers are up to snuff.

You are kidding, right? Nigel is to do *all* driver fixing by himself?

Obviously, Nigel would have to have intimate knowledge of every single broken driver out there and then have the time to actually fix it. In fact, Nigel did fix quite a few, but asking to do the lot is a bit much.

AFAIK, current suspend subsystem maintainers fix drivers only when they happen to have a good handle on the driver in question. Otherwise, they defer to that subsystem maintainer.

Kernel Summit 2006: Software suspend

Posted Jul 19, 2006 21:21 UTC (Wed) by christian.convey (guest, #39159) [Link]

No, I'm *not* suggesting that Nigel does this work himself necessarily. The specific plan I gave was just an example of incremental progress. I have no idea whether or not that particular plan would be a good one. And even if it is, I'm not saying that Nigel needs to do the work himself - just that he needs to ensure that the kernel tree evolves in a way compatible with his plan to get all of suspend2 into it.

Don't miss my main point: breaking a large change into smaller, more digestable changes is sometimes the most expedience way to achieve the results of the large change. That was my only point.