Re: a Debian executable on Android
Does build.prop do any good toward a device list? Write something to import it?
For that matter I'm not sure where a build.prop comes from, my guess
is an output from the kernel build telling what options were selected.
So is it possible to build a kernel keeping the necessary Android
options but adding ones we want? I think some guys on XDA do that,
but not with an eye toward mainstream Linux compatibility. I built
Linux kernel once years ago, used to build them for FreeBSD and
OpenBSD several times a year.
Keep Android stuff in a DMZ?
Re phones on network contracts, Motorola at least sells crippled
phones cheaply that are different from the full-price retail version.
I had a Motorola XT1527 I picked up cheaply on eBay which had been
sold to "Go Phone". Motorola's web form wouldn't give me the unlock
code for the bootloader, so it couldn't be rooted (from my viewpoint).
I also couldn't tether with it. Returned it, paid the $159 for the
retail version direct from Motorola and everything works fine. Same
model number. So I plan to stay away from contract phones. I'm on
Straight Talk anyway. Contract phones deserve to be ignored, they're
disposable appliances.
On 4/8/16, Paul Wise <pabs@debian.org> wrote:
> On Fri, Apr 8, 2016 at 1:18 PM, Alan Corey wrote:
>
>> I haven't looked into it far enough, but why can't Linux use Android's
>> device drivers that already exist? Do the hardware manufacturers own
>> them? It doesn't seem like it should be that different from a video
>> card or a network card driver. Google claims most of Android is open
>> source. The pace may be a bit much, phones come on the market and
>> become obsolete much quicker than other hardware. As I type into my
>> 14 year old desktop...
>
> It is complicated...
>
> A big part of it is the differences between ARM and PC architectures.
> Also, for years there was the Android fork of the Linux kernel, which
> had a bunch of new APIs but is mostly or all merged into mainline
> Linux these days I think(?). The vendors of CPUs, SoCs and mobile
> devices then forked from the Android fork of Linux, usually one fork
> per CPU, then one fork per SoC and one fork per mobile device, but
> sometimes some of those were shared within a vendor and some vendors
> did forward changes upstream. The Android-fork-specific APIs prevented
> sending drivers upstream to Linux mainline. In addition, the ARM
> architecture has no standard way of enumerating available devices and
> in Linux each device was supported by a compiled .c file and each
> Linux kernel binary could only run on one device. Linus got annoyed
> with this mess of .c files which leading to Linux on ARM adopting
> device-tree as a standard way to describe hardware. Right now, most
> devices don't ship device-tree files in the boot firmware but the
> Linux source tree has a repository of device-tree. This is changing as
> device-tree for ARM solidifies and becomes an ABI. In addition, each
> device vendor had their own boot mechanisms. More recently UEFI/ACPI
> have emerged as the standard boot mechanism for ARM servers so we may
> see that on mobile too at some point. At the same time, mobile devices
> have a life span of a couple of years due to the way people get them
> on phone network contracts. There often isn't enough time within two
> years to upstream all the changes into Linux mainline and once a
> device is out, there is no motivation to do that. The Linux kernel
> community meanwhile is using mobile devices but they work fine and
> they don't want to brick their phone, so they have no interest in
> mainlining that stuff. There is probably more to it than that, but
> this is the problem in a nutshell.
>
> Some links around this:
>
> https://lwn.net/SubscriberLink/682459/7e095da9f8e8fb2a/
> https://lwn.net/Articles/616859/
> https://lwn.net/Articles/573409/
> https://lwn.net/Articles/572692/
> http://elinux.org/CE_Workgroup_Device_Mainlining_Project
> https://lwn.net/Articles/662147/
> https://lwn.net/Articles/481661/
> https://lwn.net/Articles/472984/
> https://lwn.net/Articles/514901/
> https://lwn.net/Articles/647524/
> http://elinux.org/LWN_Obstacles_article_details
> http://elinux.org/Kernel_Mainlining
> http://elinux.org/Mainlining_improvement_ideas
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
>
--
Credit is the root of all evil. - AB1JX
Reply to: