4 ms·

I think DiBona's position was and is eminently reasonable. As I understand things, the Android team tried to upstream wakelocks, and the kernel maintainers basi

by durin42 17y ago

I think DiBona's position was and is eminently reasonable. As I understand things, the Android team tried to upstream wakelocks, and the kernel maintainers basically said no, but without any proposal for something better. To my mind, that's begging for a fork. If it were _me_ getting that kind of feedback on a patch, it either means the functionality from the patch is completely unwelcome or that I'm supposed to guess the maintainer's mind on things. I've had this happen with patches, and I've had to call out a maintainer as being unreasonable in this regard. It was ugly, and I don't think I'd bother again, I'd just maintain and ship a patched version. Disclaimer: I work for Google, and enjoy spending time with Chris. His office makes my job more fun.

_delirium 17y ago
I can see some of both sides. From the kernel developers' perspective, wakelocks solve a special-case problem: they only work on systems where frequent suspend/resume is possible (e.g. ARM/SoC style devices), have tight kernel/app integration, and accepting them means basically forking the power-management support within the kernel, with one system for Android-style devices, and another system for everyone else. They'd prefer a more unified power-management API, but solving that problem in a way that works for everyone is a lot harder. AFAICT, nobody on either side has put much effort into solving that general API problem. Not sure who to blame for that, but in theory, the maintainers of the current power-management API could've put forth a counter-proposal for how to accommodate Android's concerns in their framework; or Google could've put forth a revised proposal for how to merge wakelocks-like functionality with the existing power-management API. Some of it might just be a mismatch between how the kernel process works and how Google usually does things. The convention is that when you submit an API-changing patch upstream, you're proposing: I think all users of Linux should have this new API, and you have to be prepared to defend the API design, modify it in response to criticism or concerns, etc. Ideally, you're supposed to get feedback from other potential users before you actually write the code, as opposed to designing everything unilaterally and presenting it as a done deal. From what I can tell, Google's approach was just a one-off: here's what we propose, and btw we already shipped it. Basically, skipped the step where they were supposed to first propose it and ask for feedback. An approach that might've gotten more positive results would be, before sending off the patch, send a short design proposal with something like: "Hey, for our needs we're thinking of the following API, because [explain why existing APIs are insufficient], and [explain rationale and use cases for this one]. What do people think?"

by durin42 17y ago

_delirium 17y ago

I can see some of both sides. From the kernel developers' perspective, wakelocks solve a special-case problem: they only work on systems where frequent suspend/resume is possible (e.g. ARM/SoC style devices), have tight kernel/app integration, and accepting them means basically forking the power-management support within the kernel, with one system for Android-style devices, and another system for everyone else. They'd prefer a more unified power-management API, but solving that problem in a way that works for everyone is a lot harder. AFAICT, nobody on either side has put much effort into solving that general API problem. Not sure who to blame for that, but in theory, the maintainers of the current power-management API could've put forth a counter-proposal for how to accommodate Android's concerns in their framework; or Google could've put forth a revised proposal for how to merge wakelocks-like functionality with the existing power-management API. Some of it might just be a mismatch between how the kernel process works and how Google usually does things. The convention is that when you submit an API-changing patch upstream, you're proposing: I think all users of Linux should have this new API, and you have to be prepared to defend the API design, modify it in response to criticism or concerns, etc. Ideally, you're supposed to get feedback from other potential users before you actually write the code, as opposed to designing everything unilaterally and presenting it as a done deal. From what I can tell, Google's approach was just a one-off: here's what we propose, and btw we already shipped it. Basically, skipped the step where they were supposed to first propose it and ask for feedback. An approach that might've gotten more positive results would be, before sending off the patch, send a short design proposal with something like: "Hey, for our needs we're thinking of the following API, because [explain why existing APIs are insufficient], and [explain rationale and use cases for this one]. What do people think?"