> > That's very good. But if it is done in a conceptually flawed way, some > > better solution should be considered for upstream merge. > > How is it flawed? Serious question. - It means changing drivers and quite a few apps - It doesn't solve the problem of rogue apps if they end up owning locks - It puts the deep knowledge of the platform in the applications - It gives the apps control of the action taken not policy indication - It doesn't resolve the problem of synchronization of take/releases stopping any suspend - The kernel parts are not generically useful, merely effective for solving a specific problem right now - even things like VM migration to/from phones seems to break it - It inverts the whole logic the kernel is following and trend it is following that suspend is simply a very deep idle (with implementations merged) If it was a localised turd I wouldn't worry. There are plenty df deep unmentionables hidden away enirely in platform specific code that deal with everything from stoned hardware engineers to crazed software stack implementations. Here is a question back the other way perhaps - If the existing kerne was almostl entirely read only, or you had to pay a large fee per line of code changed outside your own driver how would you implement the wakelock/suspend blocker API ? Because if you take the path that 'we want wakelockers' that is essentially the question you have to answer. How do you merge it so that nobody outside of your driver and maybe a spot of arch code knows about it. You are permitted a couple of sneaky substitions of core function bits in headers. Right now bits are going to leak out over the kernel which is the cause of friction. At the point it's invisible to everyone else they cease to be stakeholders so you don't have keep them happy. You've only got a couple in your patches but its painfully obvious from Matthew and your comments you'll end up needing a ton more and these will get everywhere as Android grows hardware platforms and CPU support as phones become more featureful and PC like. The moment a phone grows a USB base station with hub for example the entire USB stack becomes burdened with them. Matthew has already indicated networking needs them. Good luck with Dave Miller on that. I'm asking questions to look for generalised approaches, or even better doing it without new kernel stuff in the first place, but it's not the only way. Alan _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
