[sigkill]

So this is one thing that puzzles me. Why can't phones have modular drivers like a PC? Phones of today are way more powerful than PC of the past, but it seems that manufacturers still want to keep an appliance like structure for the phone.

In my ideal world, I'd download (say) Android 4.4 and install it on my phone. After that, I'd hunt around, download and install the drivers for my phone like mic, camera, gyro, etc.

Why is this not possible already?

[ctz]

Historically a huge amount of effort went into making PC hardware enumerable at runtime and hotpluggable: BIOS, then ISA PnP, then PCI/PCIe, and ACPI. eg. There are BIOS functions dedicated to telling you, in no uncertain terms, what RAM you have and the addresses it appears at.

ARM's architecture is still quite firmly stuck with the embedded approach where you get your memory map and peripheral availability at compile time, probably by reading addresses from a manual published by your SoC manufacturer. Usually at early boot there is nothing which will tell you where your RAM is, what peripherals you have and where they are, etc. You either just have to know, or have some non-standard configuration mechanism which tells you.

Things are improving, but slowly. ACPI exists for ARM and is being actively worked on, but isn't widely deployed yet.

[userbinator]

Don't forget that there was also a huge amount of effort invested in making the PC backwards-compatible for software; although this has (unfortunately, IMHO) become somewhat decreased these days, you can still mostly count on a PC having the same "legacy" devices (8042, 8259, 8254, 8237, MC146818) that behave the same as they did in the AT, despite them being integrated into the chipset now. Those weren't enumerable since this was before PnP, but them being there was a pseudo-standard that software could depend on.

In contrast, ARM SoCs are extremely diverse, and the only thing they all have in common is an ARM CPU core. There is no one standard for where the peripherals are, how they behave, how the SoC boots, etc. There is no "standard platform" for ARM like there is the PC for x86. The closest "de-facto" platform I can see for smartphones is the Mediatek MT65xx, which is used by the majority of the generic Chinese ones (and some branded ones, like Lenovo).

[tcas]

Additionally, device tree support in the Linux kernel allows many board specific ports to be packaged onto a single kernel, and the bootloader specify which peripherals and their addresses and features are there. Still nowhere near as powerful as ACPI though.

[stusmall]

It is possible but there is no financial incentive to do so. There is no user expectation to install your own OS on a phone like there is a PC. Its just cheaper and easier to develop and test a product if you can assume the hardware/software are in lockstep and you completely control both.

Also you have to keep in mind, the driver situation in the embedded world can get dark fast. Manufacturers wanting to keep datasheets secret, drivers that are just pass-throughs so user space daemons can write to hardware so they don't have to comply with the GPL. It gets weird fast, and why bother with that mess if it won't win any more customers than just a few hardcore hackers and power users.

[andrewflnr]

Sounds like a crummy world to me if you have to hunt around for drivers. I'd rather everything just worked out of the box, with the option to change drivers around later if I want. Getting drivers working is one of the worst parts of an OS install.

[sliverstorm]

You are in a much better position to wrangle with a half-working PC than your phone. No hardware keyboard or mouse, for starters.

[ghughes]

Because it makes for a terrible user experience.