Not great, but not terrible either
It's not great that the android drivers can't be put into mainline... I think it'd be better overall if they were. But, I do agree that if they are using their own locks, their own framebuffer code, slapping in an extra security model, etc., and not really trying to use what's in the kernel (or make a good reason why they NEED seperate code), then it's better to pull it out... every platform having it's own platform-specific lock types and etc. would be a huge mess before long.
It's not terrible either though, it's fairly common for odd platforms to have their own kernel versions... MIPS and PA-RISC did for quite a while (the bulk of the MIPS or PA-RISC support was merged in, but it took a while for the bugs to be worked out of mainline, requiring platform-specific kernel patches to actually yield a bootable kernel.) A lot of embedded platforms have their own branches, with lower memory and CPU power than a typical desktop or server, the branch can be cut down in ways that are not portable but speed up the kernel for that platform; embedded platforms (including Android) also don't have expansion slots, so the user is not going to put some new card in then lament not having drivers from a newer kernel.
Ultimately, if there's enough interest, I suppose the Android code can be made to use regular locks and framebuffer code, and then be merged into the mainline kernel. If it turns out the performance is lower or something (maybe the special locks sped things up...), people would then still have the choice between a "stock" mainline kernel and an Android kernel.


