Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Posted Jul 12, 2012 13:26 UTC (Thu) by karim (subscriber, #114)In reply to: Yaghmour: Extending Android's HAL by etienne
Parent article: Yaghmour: Extending Android's HAL
Posted Jul 12, 2012 23:06 UTC (Thu)
by aryonoco (guest, #55563)
[Link] (10 responses)
I was just reading that Boeing has approved two in-flight entertainment systems for its new 787 Dreamliner, one made by French company Thales and the other by Panasonic, and both are based on Android, where in previous years most of these systems were Linux based.
This is in addition to all the set-top boxes and Smart TVs and game consoles smart watches and everything else which is coming out and is based on Android. Sure there are still a huge number of set-top boxes and such running vanilla Linux, but one gets the feeling that providing a "whole stack" with a functional and well-documented SDK is proving more than enough to shoehorn Android in areas where vanilla Linux used to dominate.
Posted Jul 13, 2012 4:47 UTC (Fri)
by tnoo (subscriber, #20427)
[Link] (1 responses)
Android is, AFAIK, Linux (kernel)/ Bionic (libc)/ [??] / Surface Manager, i.e. everything from Gnu replaced by custom components.
Posted Jul 14, 2012 6:36 UTC (Sat)
by steven676 (subscriber, #41893)
[Link]
Trouble is, this stack is very much oriented toward a PC desktop/server configuration -- support for touch-based interfaces hasn't until recently been available, and it's not baked into the stack. The result is that everyone building something like an on-demand in-flight entertainment system has been cooking up their own custom solution. While I'm sure the people doing this work are doing their best, the result inevitably seems to be something that barely works and crashes frequently (as anyone who's used the first generation of aircraft AVOD systems for any length of time can tell you).
What Android provides these vendors is a stack that's ready-made for touch-based interfaces and easily adaptable to ten-foot interfaces for STBs -- and doesn't crash when you look at it funny. I tend to think the advantage of being able to outsource all of that work to a company that's much better at doing it, for free, would drive IFE and STB vendors toward Android independent of any ecosystem considerations.
Posted Jul 13, 2012 14:07 UTC (Fri)
by karim (subscriber, #114)
[Link] (7 responses)
The thing that Android undeniably brings to the table is a compelling UX which ODMs can push to users with some assurance that they'll: a) know how to use out-of-the-box, b) like it. Plus, ODM gets to jump on the Android bandwagon and benefit from all the NRE Google is pouring into it. And to top it off, as you mention, there's a wonderful SDK with a lot of people who know how to program for Android. All good stuff for sure. In fact, so good, it's putting Android where Linux just couldn't reach.
None of that, though, diminishes Android's cost. It just makes it easier for big players to justify the switch. Small players, though, still struggle and are highly dependent on what their SoC manufacturer can give them.
Posted Jul 13, 2012 18:50 UTC (Fri)
by nix (subscriber, #2304)
[Link] (6 responses)
Posted Jul 13, 2012 20:20 UTC (Fri)
by karim (subscriber, #114)
[Link] (5 responses)
NRE: Non-Recurring Engineering. That's the engineers' salaries and the rest of the stuff that it costs upfront to get the product to the market and that "evaporates" as the number of units grows. Pretty much like the cost of making a movie, it gets lost after the thing reaches some ungodly sales numbers.
ODM: Original Design Manufacturer. Whomever is actually manufacturing the actual device (i.e. you may never hear about these guys and they may not be the same brand as that that appears on the actual item sold.)
UX: User eXperience. I use this pretty much freely to include both the User Interface and *everthing* the user gets in contact with when using the gizmo.
IFE: In-Flight Entertainment system.
SoC: System-on-Chip. This is something like the TI OMAP or Nvidiai Tegra. In the case of Android, these are chips with an ARM core and whole bunch of other integrated devices (USB controller, RAM interface, I2C, etc.) It's a pretty much a full "system on a single chip" ...
SDK: Software Development Kit. The package Google gives out to Android developers for creating Android applications.
Hope this helps,
Posted Jul 14, 2012 15:16 UTC (Sat)
by nix (subscriber, #2304)
[Link] (4 responses)
Posted Jul 15, 2012 0:00 UTC (Sun)
by jzbiciak (guest, #5246)
[Link]
NRE I believe is a more generic business term, though I could be wrong. I was introduced to the term and concept where I work when I hired in *mumble* *mumble* years ago.
I actually use the NRE concept quite a bit when working on my smaller projects that I intend to sell. (I have a hobby making video games for an old system.) There's a certain NRE required to get the first unit, plus the marginal costs of making each additional unit. You can use the two together to estimate the breakeven sales for a product.
Posted Jul 15, 2012 0:17 UTC (Sun)
by drag (guest, #31333)
[Link] (2 responses)
ODM is the company that actually manufacturers things. I can across that first with laptops and looking for stuff without Windows pre-installed.
The way it works is like this:
ODMs typically know surprising little about hardware design or software programming. Their expertise lie in manufacturing. They take the chipset design examples, copy them, and figure out how to duplicate their functionality as cheaply as possible while producing a streamlined design that is cheap to manufacturer. They then provide a variety of product lines that they offer to OEMs.
OEMs are the customer-facing corporations that produce products for consumption. They provide customer support and maintain relationships with retail outlets. They purchase from ODMs and will have the ODMs customize them for specific markets. This can include variations on CPUs and networking features, different plastic casings, and things of that nature.
Typically all OEMs do is things like install CPU, memory, hard drive, install the OS, and then ship them out. Higher end items tend to be much more boutique, of course.
Software integrators are companies that provide software expertise for OEMs. They are the ones that will take documentation from Chipset makers, ODMs, and program the low level OS stuff required for hardware compatibility.
So say I am part of a American corporation, a OEM, that wants to produce a tablet. (I could be Apple, Dell, or any other number of OEMs large or small) I will contract out with a software integrator firm in Taiwan and maybe another one that can do testing and integration here in the USA. I will use them to help pick out ODMs and I will get a board that is designed according to my specifications. Then I will work on case design and 'UX' features myself and contract out with another company to produce engineering examples with 3D printing techniques and such things. I'll get a few sample devices made, send them out for testing and development to the different groups. I will also send engineers to China or whereever it's being produced to inspect the manufacturing facilities and perform QA on the first series of devices produced. Once I screw around with the design meet the FCC requirements and other certification requirements it will go into full fledged production. The ODM will produce the devices, ship them to me. I will perform final QA, update the software on them (they will have something pre-installed, usually not the latest version), and then ship them out to retailers and/or customers.
Then invariably somebody would get angry with me about the source code and then it will be a pain to track down the software firms that produced the drivers and get them to cough up source code, which is something I didn't really care about in the first place. :P
Posted Jul 15, 2012 13:21 UTC (Sun)
by nix (subscriber, #2304)
[Link] (1 responses)
ODM as you describe it is definitely a domain-specific term, though not the embedded domain: I suspect it's the 'other people manufacture stuff first and then you soup it up' domain: firmware and the like. So if you've mostly been working in pure software firms, you won't have encountered that either.
Posted Jul 16, 2012 5:10 UTC (Mon)
by drag (guest, #31333)
[Link]
It is useful to remind yourself that money spent is money gone and if you are taking "sunk costs" (in the traditional economic 'money you already spent' way) into your decision making process you are doing it very wrong.
Posted Jul 13, 2012 9:09 UTC (Fri)
by etienne (guest, #25256)
[Link] (24 responses)
I did not read anywhere that the Linux kernel was licensed under some other license than GPLv2, even for Android.
Posted Jul 13, 2012 14:10 UTC (Fri)
by karim (subscriber, #114)
[Link] (23 responses)
You're right, Linux's licensing doesn't change because of Android. However, Android uses user-space .so "modules" to interface with hardware. Such files, per the kernel's own licensing, are off-limits to the GPL and are typically delivered in binary form only. Cyanogenmod installation scripts, for instance, will copy those original .so files off the device before reflashing and then put them back in the new image (i.e. you've bought a license to those files if you purchased the device.) That's where the rub is. The door is open for making those available in binary only and that's exactly what's happening.
Posted Jul 13, 2012 21:05 UTC (Fri)
by man_ls (guest, #15091)
[Link]
Posted Jul 13, 2012 23:37 UTC (Fri)
by swetland (guest, #63414)
[Link] (2 responses)
Only some hardware is abstracted through HAL modules (when an existing kernel interface does everything that needs doing it's used directly -- see the input/events subsystem for example.
In particular we avoid "userspace drivers" that directly touch hardware through mmap'd userspace registers and other insanity like that. I can't say for certain that no Android OEM does that, but I sure hope they don't -- the kernel is extremely good at resource management (both from a security and stability standpoint) and that's a strong argument for drivers to stay in the kernel where they belong.
Sometimes HAL libraries are used for "value add" software -- say some proprietary "sensor fusion" algorithm instead of just reading the gyro/compass/gps/etc directly. One nice thing about the HAL libraries is that they provide a clean break point to replace this stuff with alternative or open source implementations.
Posted Jul 14, 2012 12:43 UTC (Sat)
by mgross (guest, #38112)
[Link]
IMO the HAL is not just a shim for user mode to serialise or funnel access to selected kernel bits. Its really the bottom layer of how the android user mode OS exposes the kernel services it cares about to applications or services through the service manager and framework through JNI and binder.
thinking of it as just shim layer on top of kernel ABI's IMO is too simplistic.
Posted Jul 14, 2012 14:40 UTC (Sat)
by karim (subscriber, #114)
[Link]
Given that Android doesn't specify what this interface is, the door is open to do anything and everything in there, for better or worse and regardless of whether this is sane or not. I get that Google encourages people to stick by the rules and that's to its credit. And Android's use of a HAL was, from my point of view, speculatively likely crucial to get buy-in for Android as a platform. But it has the drawbacks of its benefits.
Posted Jul 14, 2012 7:17 UTC (Sat)
by paulj (subscriber, #341)
[Link] (18 responses)
The kernel's licence does not say such files are off-limits - this belief of yours is completely unfounded. The Linux COPYING says that "user programs that use kernel services by normal system calls" are not subject to the kernel's licence.
Posted Jul 14, 2012 12:20 UTC (Sat)
by karim (subscriber, #114)
[Link] (17 responses)
Thanks in advance for clarifying this for me.
Posted Jul 14, 2012 16:24 UTC (Sat)
by paulj (subscriber, #341)
[Link] (16 responses)
Now, whether some specific bit of user-space code does or does not meet the criteria, I don't know. I couldn't tell you either with any authority. You should consult a good lawyer specialising in this kind of thing, if there is doubt that matters to you. ;)
Posted Jul 14, 2012 16:53 UTC (Sat)
by karim (subscriber, #114)
[Link]
We're all safe, then, no lawyers needed here ;)
Posted Jul 15, 2012 8:00 UTC (Sun)
by cmccabe (guest, #60281)
[Link] (14 responses)
The note is there to clarify that userspace programs are not derived works of the kernel. This would have been true even if the note hadn't been posted, but the intention was to make it clear.
The recent Google vs. Oracle case should lay to rest any doubts about whether APIs are copyrightable (such as the API between the kernel and user space). The answer is no. Copyright doesn't flow through APIs. I think it's irresponsible to suggest that this issue is uncertain.
Posted Jul 15, 2012 8:57 UTC (Sun)
by paulj (subscriber, #341)
[Link] (13 responses)
Also, I think you've taken too broad an implication from the Google v Oracle case. Just because an API is not copyrightable, does not mean that an API is automatically a boundary for copyright derivation.
Posted Jul 15, 2012 13:24 UTC (Sun)
by nix (subscriber, #2304)
[Link] (12 responses)
Posted Jul 15, 2012 14:34 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
PS: to guys who unexported the 'kallsyms_lookup_name' function. I hate you.
Posted Jul 15, 2012 17:28 UTC (Sun)
by butlerm (subscriber, #13312)
[Link] (9 responses)
The idea that using _any_ kind of interface that does not involve incorporating actual code makes something a derived work is somewhere between an exercise in wishful thinking and a legal fantasy. Who came up with this idea? It is positively preposterous.
The legal definition of a derived work is simple. A new work is a derived work if it is "based on" a prior work - meaning it incorporates content from the prior work, content that merits copyright protection in the first place. A fork of the kernel is a prototypical example of a work "based on" the kernel. _Nothing_ that merely talks to the kernel that does not itself contain substantial content copied from the kernel is based on the kernel.
Works that communicate with the kernel might be said to be based on kernel interfaces, but in America at least, courts are wise enough to know that extending copyright protection to interfaces would lead to no end of absurdities. Linux would be illegal, Microsoft would retain a copyright interest in all Windows applications, drivers would require licenses from hardware manufacturers, executables would require licenses from processor manufacturers, and on and on.
There wouldn't be any faster way for the free software movement to commit suicide than to get the idea that functional interfaces are deserving of copyright protection enshrined into law.
Posted Jul 15, 2012 19:09 UTC (Sun)
by bjartur (guest, #67801)
[Link] (2 responses)
I reckon that GPLv2 triggers only on "distribution," (whatever that means) and thus this should only be a concern for software vendors (including vendors of hardware that contains Linux).
Posted Jul 16, 2012 6:26 UTC (Mon)
by butlerm (subscriber, #13312)
[Link] (1 responses)
That is an interesting theory, but the status of a composite work (such as a distribution) is a separate question. The question at hand is whether mere functional compatibility makes component A a derivative work of component B. There certainly isn't a trace of that in the definition:
Oddly enough whether a work is usable or not has nothing to do with it. It isn't an issue that copyright law touches on at all.
Posted Jul 17, 2012 16:01 UTC (Tue)
by bjartur (guest, #67801)
[Link]
I believe the errata in and of it self to be an original work. But when bundled with the textbook, the composition surely must constitute a derived work. Annotations are usually useless without the annotated work. This article does, on the other hand, not forbid reviews, for example.
Drivers bundled with a kernel can similarly be considered as "elaborations, or other modifications which, as a whole, represent an original work of authorship."
Obviously, IANAL. Additionally, I don't speak English natively, and am in fact quite uncertain as to whether I'm interpreting the last sentence of your quotation of 17 USC 101 correctly.
Posted Jul 15, 2012 22:30 UTC (Sun)
by paulj (subscriber, #341)
[Link] (5 responses)
I'm not a lawyer, and I don't want to play one on TV either. However, I'm reasonably sure the above is quite incorrect, from my layman's understanding of corporate legal advice as well as >15 years of following free software. For one thing, there is US case law showing that copyright derivation can occur without any literal copying at all.
As an aside:
One thing I've learned is that programmers' often make the mistake, when it comes to legal issues, of approaching the law as if it were a precise machine, with deterministic outcomes. This is far from the case. Further, with respect to copyright issues and derivation particularly, programmers often assume that the technical boundaries they are familiar with (APIs, function calls, memory address spaces, sockets, networks) must have legal meaning and map clearly to legal boundaries (I used to think that way). However, that isn't the case. The legal space can completely ignore such technical boundaries quite easily, if it wishes, and perhaps focus instead on apparently abstract, subjective details.
Basically, what have I learned is that programmers often suck at legal issues. Particularly wrt copyright derivation issues: you'll be very hard pressed to get precise, objective guidance from a lawyer on when exactly a work does and does not derive from any other. Which means programmers should probably be wary about attempting to give such guidance.
Posted Jul 16, 2012 6:52 UTC (Mon)
by butlerm (subscriber, #13312)
[Link] (4 responses)
Posted Jul 16, 2012 11:19 UTC (Mon)
by paulj (subscriber, #341)
[Link] (3 responses)
The FSF and the SFLC also seem to disagree with your claim. E.g. there would be no need for the LGPL if your claims were correct. Using the GPL on libraries would be effectively the same as the LGPL in your view, if "interfaces"[1] automatically were a barrier to copyright derivation, or if the mechanics of DLLs somehow meant one code linking to another did not "incorporate"[1] the other (and thus, can't derive as you seem to claim).
Basically, it is your claims that appears the unusual one, at odds with years of practice across the Free Software world, and in software generally. It's also at odds with my personal knowledge of actual legal advice (which is hearsay to you, admittedly). It is your claim that needs to be substantiated.
The best advice, if this kind of thing matters to someone, is to go ask a good lawyer about the specifics of a case.
The worst thing to do, if you have code that calls other code, is to assume that because you as a programmer can see a clear distinction between the 2 (e.g. because of function calls, or IPC, or XML-RPC, etc), that therefore your code can not be subject to the licence of the other. Or, to listen to legal advice from anonymous commentators on technical forums to the same effect… ;)
1. What does this mean exactly? I bet you can come up with a technical definition, but that doesn't mean it has any legal meaning.
Posted Jul 16, 2012 13:52 UTC (Mon)
by fuhchee (guest, #40059)
[Link]
Note that the FSF has an interest in broadening the application of their policies/licenses, so a public relations overreach in this direction would not be hard to fathom.
"and in software generally"
How so? Can you point to situations where e.g. extension / patch for some proprietary software was deemed "derivative" in the copyright sense?
Posted Jul 16, 2012 20:12 UTC (Mon)
by rqosa (subscriber, #24136)
[Link]
> there would be no need for the LGPL if your claims were correct Not in the case of statically-linked binaries — because those include copies of parts of the static library, they are clearly derived works of the library, so the LGPL's "linking exception" is necessary there. There's also the case of libraries with header files that contain actual code (e.g. preprocessor macro functions or C++ template functions), not just interface definitions.
Posted Jul 17, 2012 1:37 UTC (Tue)
by butlerm (subscriber, #13312)
[Link]
On the contrary, distribution of GPL/LGPL software requires compliance with the terms of the license. If the license said (for example) you cannot jointly distribute this item with anything that we frown upon, you would have to follow those rules or lose the right to distribute completely.
The issue with derivative works governs only those who distribute independently. If the secondary work is not a derivative work, the producers of the original work have no copyright interest in it. The authors of the secondary work can distribute it however they feel like unless they require a license to the original work. If they do require such a license, the licensors can make them do practically anything - from standing on their heads every morning to providing free technical support.
Posted Jul 16, 2012 7:25 UTC (Mon)
by cmccabe (guest, #60281)
[Link]
It's true that if you apply a patch to the running kernel from userspace, that patch is probably a derived work of the kernel. And if you have some debugger-like interface that allows you to make arbitrary function calls, your debugging script may also be a derived work.
But neither of those things is an API. An API is a stable interface that abstracts away the implementation of the functionality.
If FreeBSD added some of the same system calls that Linux has, that wouldn't make it a derived work of Linux, any more than Linux is a derived work of SysV UNIX because it implemented most of the SysV system calls. That is the meaning of the Oracle vs. Google ruling.
We should all be thankful that this is the case. Otherwise open source and free software would become impossible. Let's be done with this issue.
Yaghmour: Extending Android's HAL
Vanilla Linux
Vanilla Linux
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Chipset manufacturers ---> Design chipsets based on historical evidence of what sells and what customers want. Chipset manufacturers then take those designs and produce engineering boards (which is what costs $1500+) and then also example designs that teach manufacturers how to produce the devices. They will then make basic drivers based on those designs for Linux and Windows and provide that source code and documentation to other software integration companies that specialize in contracting out for OEMs.
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
If I understood it well, the paucity of free software drivers is making it more difficult for others to build their own. So in a way, Google is being bitten by their own allergy to GPLv2? That is interesting.
GPL bites back
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Android uses user-space .so "modules" to interface with hardware. Such files, per the kernel's own licensing, are off-limits to the GPL
Yaghmour: Extending Android's HAL
a) that user-space libraries are not "user programs"?
or
b) the use of std fileops to talk to hardware from user-space makes callers of said fileops subject to the kernel's license?
or
c) that somehow the kernels used in Android devices expose new APIs not already exposed by the kernel? (keeping in mind that the Android kernel add-ons have now been merged into mainline)
or
d) something else I'm missing?
or
e) a combination of the above?
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
> licence automatically granted *any* user-space code a get-out from the
> kernel GPL licence, but that such an interpretation is not justified by
> the actual licence. The kernel licence foreword clearly constrains the
> exception to apply only to userspace programmes that use "normal system
> calls".
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
The theory is that bundling works that would be useless without the others makes the bundle a derived work of the components.
Yaghmour: Extending Android's HAL
A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”. (17 USC 101)
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
A new work is a derived work if it is "based on" a prior work - meaning it incorporates content from the prior work, content that merits copyright protection in the first place. … _Nothing_ that merely talks to the kernel that does not itself contain substantial content copied from the kernel is based on the kernel.
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL
Yaghmour: Extending Android's HAL