Slackware ARM (current) epic mistake: the current Android kernels are kicked out!
In a perfect world, some ARMv5TE device will run perfectly with the 3.10.7 kernel of Slackware ARM current, like an x86 system under Slackware.
BUT, we live in an imperfect world and some ARM devices find full support only on their Android kernel, 2.6.32.x or 3.0.8. Slackware ARM 14.0 works perfectly with the Android kernel 2.6.32.9, under WM8650 platform. What processor is, surprise, surprise!, an ARMv5TE. For those who do not know, ARMv5TE is the standard Slackware ARM platform, like i486 is for Slackware x86. BUT, Slackware ARM current refuse to work with this kernel, which is, ironically, also completely open source as custom drivers, because of its GLIBC, who like an minimum kernel version as 3.1.0. Also, Slackware ARM current works perfectly against GLIBC from the version 14.0. I consider this is an epic mistake! And the Slackware team should urgently reconsider the situation of Slackware ARM current on the 2.6.32.x and 3.0.x kernels that are supported by Android. And, YES! Slackware ARM current should and must support these Android kernels, not to copy ad-literal the Slackware x86(_64) version! |
Slackware ARM is a software project; it should focus on providing the most current stable software platform. If your hardware is not supporting more recent kernels you should stay on the older software platform; IMHO.
We have see this too often in the OSS world to not have learned this lesson; if you wait for vendors to get their act together on driver compatibility etc, you get paralyzed. If you allow that to happen your software platform becomes uninteresting and you never get drivers or support. If you need newer packages on the 14.0 platform grab them from the current source tree and build them against the libc in 14.0. |
Quote:
When Google prefers to stay in 2.6.32 and 3.0.8, for the millions of devices that are sold, do not think it's epic that You ask to at least an 3.1 kernel? Basically, you have a 2.6.32.x kernel that works perfectly (because Android is basically a Linux based on busybox, plus the graphical user interface) and a modern kernel 3.10.7, which does not have video drivers, sound, ethernet, etc.. Quote:
How about the developers should recompile their GLIBC with --enable-kernel=2.6.31 , which offer more fun to users, for real? Quote:
Yes, maybe I am able to do this, but today are sold hundreds of thousands android netbooks. I'm not sure that all of their owners are able to recompile Slackware, even if they are able to customize a kernel package. Finally, In my opinion, trying to enter forced an gratuit incompatibility with the main vendor where you are able to get a functional kernel for you hardware platform, is a huge mistake. |
I agree completely with the op, this sound like stopping to support x86 platform when x64 come out. Maybe one day it will happen but how many years has passed ?
Slackware ARM it's now more like a toy than a distribution don't kill it completely. I don't think that Pat would ever do something like this, it's just pointless. |
Quote:
If you do use it and you have to criticize it about something, please elaborate and try to be specific. Quote:
but, hoping I'm not missing something, I see no probs in rebuilding your own glibc with whatever --enable-kernel option you prefer, if you need it. you can't blame distributions if vendors just can't keep up. |
Quote:
Quote:
I said also that an GLIBC rebuilding I can estimate to spend something like 12 hours, that, with all your Linux in a slow SDCARD? ;) |
Quote:
"I see that -current requires a minimum kernel version of 3.1. I'd like to run it on my Android which is stuck on Linux 2.6. Is there a reason that 3.1.0 is needed; is there a possibility to change this?" I have absolutely no interest in even going back in my mind to determine if it *is* required now. However, bare in mind that at some point, glibc will _require_ a newer kernel release (not just because I compiled it to), and most likely your device will still be stuck at an old kernel. What you need to also consider is that these Android devices are meant to be used as-is. They're not for developers, so unless someone's particularly interested in the device, the support won't make it into the kernel.org kernels and you'll be stuck on an old Kernel release forever and a day. Secondly, if you check the change log, you'll find that I *reverted* to an older minimum kernel so that the Raspberry Pi users could upgrade, since I thought that RPi users had a newer kernel than they did, because it's categorised as supported. Nowhere on the web site or in any of the documentation does it or has it ever said that Android devices, running an old Linux kernel is supported, and I have never recommended using Slackware ARM with someone else's Linux kernel and modules. If it was, I'd have probably not caused these devices to be rendered unusable with -current. I provide two kernels for ARMv5 devices - Kirkwood Plug Computers and the Versatile machine which emulated by QEMU. These kernels provide *only* support for their intended platforms - they are not multi platform kernels, and would never support your Android device -- so your comment about them not providing support is an "epic" misunderstanding on your part. Given that currently the ARMv5 support is not multi platform, you'll never seen a kernel in Slackware ARM that can work on your ARMv5 android since I need to build individual kernels for each target device. Celyr - your comment's just baseless. A 'toy' distribution? You have no understanding of the ARM ecosystem and how things hang together. If you'd bother to look at the supported devices and documentation, you'd find that it's installable with the regular Slackware installer on 4 device types. I'll leave it as an exercise to find out some more, should you be interested in venturing your mind in to the real world. |
Let me try to understand the logic here better. OP wants to run Slackware ARM on his device. But his device only runs on Android due to proprietary or non-mainline drivers. So he wants to use an Android kernel on Slackware ARM. But he can't run the Android kernel on Slackware-current, because of an ABI issue. Is this correct?
|
Quote:
Quote:
|
I can totaly understand Stuart's (drmozes) frustration to get his work understood and properly credited, especially considerered that the OP could have read the changelog, joined the mailing list and voiced his concerns there and probably in a more polite way.
However one good thing that I would like to pick from his post is that, in my opinion, in order for the ARM port to roam free and fly high, is to fork form the x86_64 directory structure and keep an eye (not just copy) on the Android/Linaro/Ubuntu ARM world, which has become the de facto standard, same as Slackware was the de facto standard Linux distribution in 1992-1993. |
Quote:
There are a large number of idiosyncrasies in Fedora and Ubuntu with regards to various implementations and configurations, and these can be attributed to the general approach of those distributions. Given that I was able to get Slackware ARM running on the Chromebook in under 30 mins, and others have managed to get it running on a multitude of other devices, to me demonstrates that it's flexible enough to be used on a number of devices. |
Quote:
1) Quote:
2) The ARM port should fork. That's it. The directory structure should be similar if not compatible with Android - a read only system partition, a 'cache' partition, and an external SD card. That's it. The concept of a file system that grows with time doesn't apply to smartphones and tablets. 3) Quote:
I could go on. Nevertheless I support your hard work and I understand the limitations and the constrains you had to overcome during these years. |
Quote:
Quote:
Quote:
|
Quote:
As far as this readonly system, cache, and sd card business. Read Stuart's own post he is not targeting smartphones and tablets. Slackware has never worked anything like that out of box; something called Slackware should therefor not work like that. Honestly Ottavio it sounds like what you and Darth really want is to run Android. If you were happily using Slackware ARM 14.0 its not as if its going to suddenly stop working the day 14.1, or 20.0 for that matter, is released. Nobody is expecting you to get rid of anything, and it should be little trouble building any higher level packages on 14.0 for good while yet. 14.0 will certainly be "supported" for a good while yet as well. Finally keep up the good work Stuart your port is excellent! |
Quote:
I don't buy the "netbooks are dead" line either. Desktop, laptop, netbook, tablet, smartphone all have their role to play and there is overlap at every step of the progression. edit: Apologies chem, I went over some of the ground you'd already covered there - Hadn't read your post at that stage. |
All times are GMT -5. The time now is 04:47 PM. |