Re: Attempted summary of suspend-blockers LKML thread, take three

[Brian Swetland]

On Thu, Aug 12, 2010 at 12:05 PM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
> On Thu, Aug 12, 2010 at 9:21 PM, Ted Ts'o <tytso@xxxxxxx> wrote:
>> On Thu, Aug 12, 2010 at 07:46:03PM +0300, Felipe Contreras wrote:
>>
>>> All the Android community had to do is push the drivers *without*
>>> suspend blockers, then the Android kernel wouldn't be so different and
>>> thus wouldn't be considered a fork. AFAIU the kernel side wakelocks
>>> are already in the kernel, so there's no excuse not to merge the
>>> drivers.
>>
>> What's there is not good enough, because it's missing the statistics
>> and reporting so that badly behaved kernel and userspace drivers that
>> take wakelocks can be found.
>
> You don't need to have all the code merged in, hell, you only needed
> wakelock stubs.
>
> You should take the point of view of the community as a whole, and
> forget about Android for a second; the important thing is to bring the
> code-bases closer, and that means merging the drivers. For that, you
> don't need anything extra.

Stubs would be 100% fine by me.  Previous discussion has indicated
that they are not acceptable without some firm timeline for removal.
I don't think I can commit to a firm removal timeline while we're
still making almost no forward progress.

If we don't have to commit to yanking them back out in two releases or
whatnot, then awesome, let's drop some stubs in and off we go,
worrying about merging drivers that everyone agrees they want.

Question though -- has every feature ever added to the kernel been a
feature that there's pre-existing usage of?  Seems like a chicken and
egg problem.  Also, some people seem to think there's value in being
able to build kernels "out of the box" that work with the Android
userspace -- given that there are a few devices out there that have
that userspace on 'em.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/