> Keep in mind, though, that a solution which is acceptable for Android > has to include making sure that crappy applications don't cause the Ted if you are speaking for Android do you think you should post from a google address or with a google .sig ? > battery to get drained. There seem to be some people who seem > adamently against this requirement. From the Android folks' > perspective, this is part of what is required to have an open app > store, as opposed to one where each application has to be carefully > screened and approved ala the Apple iPhone App Store. The other vendors appear to be managing nicely without magic blockers. I conjecture therefore there are other solutions. > We need to agree on the requirements up front, because otherwise this > is going to be a waste of everyone's time. This is why I am trying to understand the problem properly. > And if we can't get agreement on requirements, I'd suggest appealing > this whole thing to Linus. Either he'll agree to the requirements > and/or the existing implementation, in which case we can move on with The existing implementation has been comprehensively rejected by half the x86 maintainers and scheduler people to start with. That's a fairly big 'No'. > our lives, or he'll say no, in which case it will be blately obvious > that it was Linux developer community who rejected the Android > approach, despite a fairly large amount of effort trying to get > something that satisfies *all* of the various LKML developers who have Ted save the politicing and blame mongering for management meetings please. If we don't have a solution it means that between us we couldn't find a viable solution. Maybe there isn't one, maybe we missed it. It's as much 'google rejects kernel approach' as 'kernel rejects google approach' and more importantly its actually 'we (cumulative) were not smart enough between us to figure it out' > P.S. Keep in mind how this looks from an outsider's perspective; an > embedded manufacturer spends a fairly large amount of time answering > one set of review comments, and a few weeks later, more people pop up, > and make a much deeper set of complaints, and request that the current > implementation be completely thrown out and that someone new be > designed from scratch --- and the new design isn't even going to meet > all of the requirements that the embedded manufacturer thought were > necessary. Is it any wonder a number of embedded developers have > decided it's Just Too Hard to Work With the LKML? In some cases it is easier to do stuff yourself than work with others. One of the conditions of working in a public space is that you do so without harming others. This is why in much of the western world you can drive a car around your own land without a licence but must have one to drive on a public road. This is why a restuarant must meet different food standards to a home kitchen. This is why the kernel standards are higher than what you go off and do in private. Android is a very unique and extremely narrow environment. If it really is special enough to need its own kernel fork it isn't the first case for that and it's not a problem. The GPL is quite happy to encourage this. Time will then answer the questions because in 3 years time either every non Google phone will be kicking butt without suspend blockers, or every phone vendor using Linux with a traditional user space will be demanding them. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
