| |||||||||||||
Yaghmour: Extending Android's HALYaghmour: Extending Android's HALPosted Jul 13, 2012 23:29 UTC (Fri) by swetland (subscriber, #63414)Parent article: Yaghmour: Extending Android's HAL
Android often simply uses the standard kernel device interfaces (whenever possible, actually), for example using the stock input/event drivers.
The HAL libraries are intended to cover situations where there isn't a clear, simple, and uniform kernel interface for something, or where the subsystem in question tends to be highly device-specific and oem-customized.
For example, some devices use an audio HAL which interacts directly with the kernel ALSA drivers (using a thing wrapper library called tinyalsa), some devices use non-standard audio drivers (like the original G1) but still have an open source audio HAL, some vendors (for reason I don't quite follow) ship with closed audio HALs, and some vendors (I believe) use an audio HAL that wraps the lgpl libalsa.
Vendors are welcome to use whatever license they like for these modules. They are neither required to be open source no required not to be (though we try to make as much open source as possible for the lead "Nexus" devices and prefer solutions that allow for that).
The Android HAL module interfaces are being cleaned up over time, sometimes being eliminated in favor of a new standardized kernel interfaces, sometimes being expanded to allow for new functionality. They'll continue to evolve.
(Log in to post comments)
Yaghmour: Extending Android's HAL Posted Jul 14, 2012 0:26 UTC (Sat) by slashdot (guest, #22014) [Link]
Having the ability to do driver stuff in userspace is quite useful for things like decoding raw data from cameras, etc.
However, allowing binary drivers through the backdoor this way is not really acceptable and it's a pity that Android doesn't force open source userspace driver components via suitable licensing.
BTW, why isn't Google doing that, since it would improve their ability to push new Android versions to all devices and generally manage the Android ecosystem?
It's not like Android has any successful competitors (other than iOS, which cannot be licensed), so manufacturers would be pretty much forced to continue using Android and open their drivers.
Of course, on the topic, someone should also sue AMD and nVidia for their potential GPL violations of the Linux kernel...
Yaghmour: Extending Android's HAL Posted Jul 14, 2012 3:32 UTC (Sat) by swetland (subscriber, #63414) [Link]
The Android ecosystem is an inclusive one, including being inclusive of OEMs wanting to bolt in various proprietary "value add" bits in userspace if they want. We strongly encourage GPL2 kernel drivers, and we've never shipped a lead device that uses binary blobs in the kernel.
We also minimize the use of userspace proprietary goop as much as possible -- the more recent Nexus devices tend to have the opengl libraries be closed (but the kernel side of GPU support as GPLv2), and firmware that is needed for wifi/bt, and sometimes a handful of other things, but the vast majority of SoC, platform, and peripheral support as plain 'ol GPLv2 Linux kernel drivers.
It's rare that anything in a HAL library is something you'd *want* in the kernel -- usually it's policy stuff (audio routing, modem control, etc) or image processing or whatnot, not stuff that would likely be accepted as Linux kernel drivers even if it was open source. I certainly agree that having as much stuff as possible fully open is the place we want to go, but I am not seeing the HAL mechanism being used as some kind of "backdoor" to avoid writing GPL'd kernel drivers.
Yaghmour: Extending Android's HAL Posted Jul 14, 2012 14:34 UTC (Sat) by karim (subscriber, #114) [Link]
Thx for taking the time to follow-up Brian, appreciated as always.
True, Google does its best to keep its lead devices open source in as much as possible.
True, HAL modules aren't required to be binary only (and I don't think I said that.)
True, where possible, HAL modules use standard kernel functionality when possible.
However, to the exception of input/events (frameworks/base/services/input/EventHub.cpp opens /dev/input/* directly), my reading of the sources is that almost everything else goes through a HAL definition in either hardware/libhardware/include/hardware/*.h or hardware_legacy/libhardware/include/hardware_legacy/*h; there's of course storage that goes through vold and some of the networking going through netd. That is true even for HAL components (modules or parts of libhardware_legacy.so) that use standard kernel functionality (like power and wifi). IOW, in as far as I can see, the HAL isn't just for parts "where there isn't a clear, simple, and uniform kernel interface for something".
That said, my blog post was mainly technical and did not make a judgement call on any of the abstractions being used. However, as I said in one of the comments above, and this is a totally separate issue, the net result of Android's use of a HAL is that developers have far fewer open source examples to start from then when developers only had Linux kernel drivers to implement.
Simply because it turns out that, de facto, the HAL modules end up not being open sourced: the manufacturer isn't required to make them available, whether said HAL modules use std Linux interfaces or not. Manufacturer doesn't have to, so he doesn't. Software freedom and other moral issues asside, the reality is that this means that the vast majority of Android devices out there (most of which are not the lead device developed by Google) will never have their HAL modules implementations published. And that means there are few examples of HAL module implementations to look at for creating your own.
Yaghmour: Extending Android's HAL Posted Jul 16, 2012 7:13 UTC (Mon) by MKesper (guest, #38539) [Link] Keep in mind also that having Free Software hardware drivers for all systems isn't an academic issue: Innovative things like the Frankencamera are not possible without free drivers!
|
|||||||||||||