Kernel Summit 2006: Software suspend

Posted Jul 19, 2006 16:55 UTC (Wed) by christian.convey (guest, #39159)
In reply to: Kernel Summit 2006: Software suspend by NCunningham
Parent article: Kernel Summit 2006: Software suspend

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.

to post comments

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.