Devs Discuss Android's Possible Readmission To Linux Kernel 151
MonsterTrimble writes "At the Linux Collaboration Summit, Google and Linux Kernel Developers are meeting to discuss the issues surrounding the Android fork and how it can be re-admitted to the mainline kernel. From the article: 'James Bottomley, Linux SCSI subsystem maintainer and Novell distinguished engineer, said during the kernel panel that forks are prevalent in embedded systems where companies use the fork once, then "throw it away. Google is not the first to have done something like this by far, just the one that's made the most publicity. Hopefully the function of this collaboration summit is that there is some collaboration over the next two days and we might actually solve it."'"
Re:Cheaper costs (Score:5, Interesting)
I'm not so sure... I think the Nokia N900 has got it beat.
Yeah, but who's heard of the Nokia N900, or even knows what that means, outside geek circles? On the other hand, billboards and TVs everywhere are blasting out "Droid does". For bringing a hackable system to the masses, Android has it beat.
Re:Backwards? (Score:2, Interesting)
The last thing Linux needs is a set-in-stone kernel interface: 'backwards compatibility' is what has ensured that Windows remains a steaming pile of kludges and security holes as no old components can be thrown away.
I can only presume that you are actually Bill Gates and want to destroy Linux by forcing it to repeat Windows' mistakes.
Re:Would you rather have completely unsupported HW (Score:3, Interesting)
Re:Would you rather have completely unsupported HW (Score:2, Interesting)
1. Class compatibility.
Prefer to buy the object which says it implements a device class standard. AHCI is a good example. Classes rule so much that in a lot of cases all the non-class compatible products just went away - HID and ATAPI are good examples of that. In a few cases products don't advertise their class compliance but there's a well known sign that you can learn before you start looking. For example, if a webcam has the symbol that means it's designed to work with Vista, that means it'll work with a modern Linux too, because to get that symbol from Microsoft the webcam must be class compliant.
Today class compatibility covers almost all: input devices, USB storage, onboard sound, internal drives including optical drives, Bluetooth, mid-range webcams.
Class compatibility remains spotty for: add-on PCI sound cards, high-end cameras, graphics display (it's limited to VGA, blergh), printers
Class compatibility is non-existent for: most networking, including WiFi, digital TV, fingerprint readers, scanners
2. "No" drivers
When class compatibility doesn't exist, and you have the choice between two products that make no mention of any OS except Windows, but one says it works without drivers, buy that one. Of course it needs drivers, but they must be built in to Windows, which means hardware of this type is common, and it existed at least long enough ago to include drivers for Windows, which means there's an excellent chance drivers for Linux exist or soon will.
3. Look for the logo
It's not everywhere, but in some categories you will see a penguin logo (or other Free OS logos) on products that offer some support. Now, this doesn't mean you're necessarily going to get a nice Free Software driver that works out the box. It may be an x86 Ubuntu only binary driver, or a patch that only works against Linux 2.6.4 or something equally useless. That's why I didn't list this as option 1. But it's usually a better sign than nothing at all.
Re:Cheaper costs (Score:1, Interesting)
I would add a qualification to the statement that Android is the most hackable phone out there.
Depending on the model you get, the phone might come pre-rooted and ready to flash custom images. Or you can get it into fastboot mode so you can flash something.
Or a model might be harder to root and require a bug in the firmware signing, the OS, or something along those lines.
Or some models just may not receive the installed base to attract the top notch developers that are willing to take the time and trouble to get root.
And as time goes on, some carriers are demanding that the Android models be locked down. For example, the Backflip that doesn't allow sideloading of apps.
And it only is going to get worse. We are going to see models which have no ADB access at all, and where the only way to flash them is either an update.zip or an OTA update. There are already apps like the Blizzard Authenticator out there which refuse to run if they see a file named /bin/su. And it is going to be a matter of time before we see a process killing background task that will auto-kill anything that isn't on a signed manifest, so if someone gets a root shell, it gets killed immediately. And of course, someone can make a process to detect rooted phones and disable them and the owner's Google account permanently.
The moral: Only buy devices on providers who are root friendly, such as an Android Dev Phone (assuming they make an adp3 and higher with modern CPUs), a Nexus One, or most HTC devices. If possible, buy a popular model where Cyanogen or other modding deities will be putting out ROMS out on.
Some providers have android phones, and they are the front line models. Verizon and T-Mobile come to mind. Other providers have Android phones, but definitely are there only as token phone, as they have their own smartphone they are championing like the iPhone.
If people vote with their wallets with this issue, we might still have a modding community in the future.
Re:Backwards? (Score:1, Interesting)
Nope, the embedded market is the opposite, and is like the parent describes.
In the mainstream, you have perhaps nvidia and others who make closed source stuff dreading any disruptive shifting of the internals, while the kernel developers will make the chances needed to make things work and improve the kernel.
Embedded? From THAT point of view, the kernel is the mainline and what to aspire being compatible with, while they may have custom hacks to make the kernel loadable by a boot loader, they may have custom one-off drivers (One-off? I mean, instead of doing any existing plug-n-play, using the kernel to set up DMA and I/O, etc., the driver may just do it itself. Perfectly functional but completely non-portable, and inappropriate to plop in the mainline kernel source in that form.) They may have custom optimizations for either speed or space, that are also non-portable. And then they endeavor to re-port their custom changes to newer kernels from time to time.
Android specifically? From what I heard, there were a lot of ARM optimizations and drivers. The ARM improvements are probably already mainline, and drivers being implemented when possible. BUT, although the kernel has plenty of lock types already, Google introduced a new one seemingly superflously, and the drivers tend to use it instead of one of the numerous existing lock types. They introduced a new security model, even though there's users&groups, Access Control Lists, and 1 or 2 additional VERY flexible security systems already in the kernel tree. They also have their frame buffer drivers implementing a new type of framebuffer Google implemented instead of just showing as a standard Linux framebuffer, and making improvements to that framebuffer code as needed. These three are the real issues from what I've read, the kernel guys would VASTLY prefer the lock, securtiy model, and extra framebuffer type not go in kernel unless Google makes a VERY compelling case there's a reason for it.
Re:Backwards? (Score:2, Interesting)
Linux is a monolithic kernel. Just because you can load or unload parts of it at runtime doesn't make those parts of it any less monolithic in design. Taking drivers out of the main tree won't make the modules any more distinct, stable, or secure. It would, potentially, better classify what is and is not a driver. That's the only main change I can really see in the move.
Nothing about a stable ABI moves code outside of kernel space. It would encourage the production of binary drivers, though, which if anything would worsen security and stability.
So, you wish to turn major version changes into an even more political thing than it is now because?
It's funny. Your argument for a stable API is, if anything, an argument to make it so driver writers *don't* have to manage drivers. That's hardly a surprise, since I think most driver writers are of the mindset that if the hardware doesn't change, they should only have to write code for the hardware once and never have to touch the code again. It's not the mindset of "I wrote this code perfectly with perfect stability and security and consideration on exactly what my hardware does". Often enough, it's "good, it seems to work, that's good enough". Not surprisingly, kernel developers, who are concerned about more than "good enough" want code that's well designed, stable, and secure, with hopefully flexibility to work with many devices in a close to optimal way. This invariably puts them at odds with driver writers who are uninterested in maintaining anything*.
For kernel developers, a stable ABI includes negative consequences like static or binary drivers that hold back redesign and introduce security and stability concerns. It does nothing to address drivers having to reside in kernel space. Yes, this is a byproduct of "amateur 'just hack it until it works'", but that claim can be put on just about C developer. That doesn't mean all or even most developers actually function that way in the kernel development. But, even with simple screening for obvious bad design in submissions, bugs can be very obfuscated in C; Linux nor any modern OS I know of are willing to spend the time and energy to show code is provably correct**, so trying their best and fixing problems later is the best one can reasonably expect in any remotely large, modern OS.
*I don't mean this to be totally lambasting of driver writers. I can understand that trying to support hardware which you don't even have the specs on is frustrating, so one getting the hardware to seemingly work is usually enough to want to provide others a driver, even if one's work is incomplete or potentially sloppy (not the code itself but the design relative to what's possible). And once hardware does appear supported, one's interest are usually in coding something else (like a driver for other hardware), not doing furt