> > suspend blockers are completely backwards as they basically disable > > the kernels ability to do resource management. > > I don't think this is a defect in the approach but the point of it.
I think it's both. It's the point of it, and that itself is a defect. Its designed wrongly. > drivers code is needed anyway. What looses the kernel by implementing > suspend blockers, and later a more finegrained approach and mapping the > userspace part of suspend blockers on that finegrained approach later > on? The Linux approach is to do the job right. That means getting the interface right and so it works across all the interested parties (or as close as we can get). > > - how much delay of wakeups is tolerated (missing interface) > > Doesn't solve the segregation problem and is probably overkill for most > applications. I see this as an orthogonal thing (i.e. not > affecting this merge). The key question that matters for suspend management is 'what wakeup delay is tolerated'. So it's absolutely fundamental. > True. But I wouldnt say, that it is the linux kernel who should force > this politics onto its users. This is the Linux way of doing things. It's like the GPL and being shouted at by Linus. They are things you accept when you choose to take part. Google chose to use Linux, if they want a feature upstream then the way you get it there is to figure out how to solve the real problem and make *everyone* (within reason) happy. We now have suggestions how to do the job properly so the right thing is probably to go and explore those suggestions not merge crap. Merging crap won't help anyway. The rest of the kernel community can still simply stonewall those interfaces, and a volunteer community has ways of dealing with abuse of process, notably by simply not getting around to, or implementing things directly contrary to the crap bits. So it's not even in the interest of people to play political games. Even if you get away with in the short term the people who rely on the junk will end up out on a limb and holding the baby when the crap hits the fan (see reiserfs) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
