| |||||||||||||
Sony opens up the Dynamic Android Sensor HAL (DASH)Sony opens up the Dynamic Android Sensor HAL (DASH)Posted Aug 24, 2012 8:45 UTC (Fri) by Aissen (subscriber, #59976)Parent article: Sony opens up the Dynamic Android Sensor HAL (DASH)
I know it's the Android way, but I'm very uncomfortable with those "HALs". It's the kernel job to provide those abstractions !
(Log in to post comments)
Yet another HAL outside the kernel Posted Aug 24, 2012 9:30 UTC (Fri) by rvfh (subscriber, #31018) [Link]
"There's nothing in computing that can't be broken by another level of indirection."
Rob Pike
Userspace abstraction precedent Posted Aug 24, 2012 9:56 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
There are precedents on the non-Android Linux desktop
A PCI sound chipset, a USB headset, and a Bluetooth headset are very different from the perspective of the Linux kernel. The kernel is content to mediate both the USB and PCI solutions through a common userspace API (ALSA pcm) but Bluetooth data is just data until it hits userspace.
So the only way to have these three sound making devices behave interchangeably as far as, say, talking to your friend over VoIP, is either for every program to have separate handling for the different cases, or for a userspace abstraction to intermediate. That's one of the things the once widely despised PulseAudio does for you.
Or consider webcams. Kernel policy forbids format conversions and the like inside the kernel, and in recent years that policy has been increasingly enforced. Once upon a time cameras with custom encodings or weird format decisions would hide some conversion code in their kernel driver. No more. Today if you want cameras to work properly you use a userspace library which masks the various differences between cameras and offers to deliver plain RGB data (or various other useful formats) regardless of what the native camera hardware is.
The kernel is irreplaceable when it comes to access control, resource management, and so on. But when it comes to adding a "take a picture for your avatar" feature to a program, I want a userspace abstraction that can capture the picture just as well from a $5000 pro HD video camera as from the $5 USB webcam I, the developer, happen to own, without me needing to buy dozens of cameras to check they work.
Userspace abstraction precedent Posted Aug 26, 2012 12:26 UTC (Sun) by alankila (subscriber, #47141) [Link]
Expanding that a bit: since USB is a packet-based protocol, many USB drivers bring network programs into mind: you construct a packet of certain length, then tell the kernel driver to send it over the wire, then listen for response... The actual protocol is just binary data to kernel who only cares about the fact that the packets move in and out of the hardware.
The "do everything in kernel and then provide a file-based API to the programs" is merely ancient unix mentality. It is almost definitely not the best possible method to write every driver with.
|
|||||||||||||