Bits of Google's dead Project Ara modular mobe live on in Linux 4.9 Google may have killed off its modular smartphone Project Ara idea, but some of the code that would have made it happen looks like coming to the Linux Kernel. So says none other than Linus Torvalds himself, in his Linux Kernel Mailing List post announcing the first release candidate of Linux 4.9. Torvalds tossed in a barb …
to extend Simon Sharwood, Reg APAC Editor's comments. The thing is phone makers should start adopting moralities than wait sitting pregnant with hope of project ara delivery. for example in my country it takes approx $5 to unsolder and solder a replacement component on motherboard from another phone. now most people are ok to spend this much but phone makers are deliberately changing dimensions of front and back camera module inside so it could not be connected even through soldering means. LG i saw videos that it uses a bitchy cement on RAM so it can not be unsoldered. Samsung was more ethical in similar videos letting straight unsoldering through heat gun. phone makers must first adopt morals and ethics to in first phase enable phone repairmen then 2nd phase this ara whatever letting user itself getting enabled.
youtube videos
How to replace emmc LG D380 to 8GB using UFiBOX ........ watch at 00min:51sec
Samsung Galaxy S3 dead repair by changing EMMC ........... watch at 03min 56sec
Exploding S7 propaganda wont deter me from buying Samsung products.
The fact that Linus is having to bother about a vestigial bit of code that's relevant only to a tiny segment of the user base suggests to me that there's a lot more to be gained from a modular kernel than a modular phone.
I'm not even sure why that's still such a controversial proposition, but I suspect I'm about to find out...
> Care to actually explain why "there's a lot more to be gained from a modular kernel than a modular phone"?
What he's saying is - why should drivers have to be committed into the main kernel source, by no less than Torvalds himself? Hardware vendors don't need to get their drivers committed into the Windows source tree by Microsoft.
A properly modular kernel would let separate people/companies write and publish their own Linux drivers which build separately from the kernel, but interoperate seamlessly with it.
Failing that, a stable ABI would be a step in the right direction.
"why should drivers have to be committed into the main kernel source, by no less than Torvalds himself? "
Do you actually know anything about kernel modules ?
Try :-
http://www.thegeekstuff.com/2013/07/write-linux-kernel-module/
(How to Write Your Own Linux Kernel Module with a Simple Example)
Do you actually know anything about kernel modules ?
S/he knows that the ABI is not stable, rendering them pretty useless. Windows, Mac, Solaris, and FreeBSD (within major revisions) manage to keep stability, why is Linux such a special snowflake?
@Anonymous Coward - "why should drivers have to be committed into the main kernel source, by no less than Torvalds himself"
Torvalds didn't. Greg Kroah-Hartman did. Torvalds is the top manager, and Kroah-Hartman is the middle manager responsible for that area. If you want something like that in the Linux kernel, then you write it, convince Kroah-Hartman that it should go in, and Kroah-Hartman gets it approved by Torvalds. So long as Kroah-Hartman has a good record of success, Torvalds will give it a cursory glance and rubber stamp it. You know, just like any other really big software project?
As it happens, Kroah-Hartman also works for Google on that project (top kernel developers are in much demand by companies who can pay top salaries), so he has an inside track on approvals. He'll still be deep in the brown stuff with Torvalds though if he screws up on it.
It originated with Nokia by the way, and Google have extended it. Nokia originally created it to make it easy to integrate cameras from different suppliers.
Oh, and it's not a driver. It's a communications system that includes a lot of components which need to be controlled by the kernel. It offers low-latency, in-order message delivery, QoS, standardized device classes,, etc. If they could have done it with a driver, they would have just done it with a driver. A lot of phone drivers never end up in the main line kernel (they're "out of tree" drivers).
Saying that this could have been "added as a driver if only they did whatever" is like claiming that you can add USB to an operating system "as a driver" and got a standardized USB mass storage, keyboards, mice, printers, cameras, etc., and be able to plug any of those into a device without having to hunt around on the Internet for a special driver for each one.
Guess what? Even Microsoft - the king of "you need another driver for that" (YNADFT) - clued in on that bit when it came to USB.
Sometimes I really have to shake my head at the people who still pine for the days of when Windows need a special OEM driver for every single sodding different USB flash drive.
I feel the same way - although as an established hardware molester I can appreciate that passing a buffer allocated on the stack (with a transient existence by its very nature) to a DMA-capable peripheral (which is by definition meant to operate somewhat independently from whatever the software is doing) is not the brightest of ideas, even if you swear your code goes nowhere until the buffer is spent. But that's probably a gross oversimplification anyway - I'm absolutely clueless about any OS-related code...
CONFIG_HAVE_ARCH_VMAP_STACK: this is a great addition. Initially for x86 but hopefully the other architectures where this is possible will follow suit sooner rather than later.
For those not understanding its purpose or operation - it is simply using the virtual memory mapper to allocate pages of memory for the stack of each kernel task and including guard pages either end so that any stray writes can be detected and contained almost as soon as they happen.
[0] http://lwn.net/Articles/691631/
Correct me if I'm wrong, but to most people, the cool part of the modular phone project was the modular hardware aspect- which has been killed- and not the bits of OS that are being used for other things that are not modular phones. At the end of the day, we don't get a modular phone.
this will presumably make life a little bit easier for for future attempts. The idea's not dead - it's still around in the form of clip-on hardware which, in my opinion, is the right way to do it. Google's approach was simply far to ambitious for far too little potential gain.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
