Devs Discuss Android's Possible Readmission To Linux Kernel

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."'"

Comments

Re:Cheaper costs

[girlintraining]

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:Would you rather have completely unsupported HW

[tepples]

So I, an end user, am inside a Best Buy store, and I don't have a cell phone with a data plan to check what is in stock against the distro's HCL. How do I find peripherals that are definitely compatible with a free OS?

Re:Would you rather have completely unsupported HW

[Anonymous Coward]

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:Backwards?

[10101001 10101001]

it is if you accept the status quo. If you took all drivers out of the main tree and created a new tree specially for driver code, not only would the kernel suddenly get smaller and easier to work with (as you at least wouldn't have to download all that useless-to-you driver code) but the distinction between them would help to keep drivers as separate, truly distinct modules.

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.

Of course this only happens with a stable ABI. Break that every version and all that driver code starts to wither. Keep it and you won't have to keep going back to fix up the interfaces. A stable ABI would be a good thing.

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.

And, no that doesn't mean the interfaces couldn't ever be changed, you can change them in major versions of the kernel, just that anything built for 2.6.0 should still work with 2.6.100

So, you wish to turn major version changes into an even more political thing than it is now because?

It won't be perfect, but it'll be a lot easier to manage for driver writers. I can't see how it would be too much of a hardship for kernel developers either, unless they only churn the code in an amateur 'just hack it until it works' way.

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