On Sun, 22 Feb 2015 08:40:59 -0500, Nicholas Krause said:

Validis, If that is the case , would you mind telling me how to do it.

Step 1: Get good enough at kernel hacking to forward-port all the Android-specific patches. Those should be available to you from Samsung as they are GPL. Step 2: Forward-port the patches. Step 3: Build and install your new kernel.

On Sun, 22 Feb 2015 13:19:40 -0500, Nicholas Krause said:

Validis, That was my concern. How much forward porting is required.

That will depend on your actual skill level. That which is a long weekend's work for a master kernel hacker will be several week's work for a journeyman, a summer's project for a beginner, and impossible for a neophyte. But I will go out on a limb and say that if you've already gotten the patch, looked at it, and still can't make even an estimate of how long it would take you, you're probably not going to be able to do the porting.

On Sun, 22 Feb 2015 20:02:14 -0500, nick said:

This is just a idea for now I haven't have the idea to look at making the porting patch(es) yet.

Then it really doesn't matter how long it will take, because it's not likely to actually happen. So why you bothering to ask?

On Mon, 23 Feb 2015 11:50:52 -0500, Nick Krause said:

I was curious if this is possible. As other distros like Red Hat are very hard to port the patches to from the main line kernel.

Forward porting the patches isn't much trouble - the Rawhide guys seem to be able to do that almost *every single day*, since they build against a near-nightly pull from Linus's git tree. What's difficult is beating patches into a condition that can be merged upstream - often the patch is one that the upstream maintainer doesn't want to accept (for instance, of the 60 patches in today's Rawhide kernel (kernel-3.20.0-0.rc0.git10.1.fc23.src.rpm), we have things like: die-floppy-die.patch - removes the PNP alias for floppy drives. Not suitable for upstream until we finally get disgustipated enough to throw floppy.c overboard. silence-fbcon-logo.patch - suppresses the framebuffer CPU icons at boot, and not suitable for upstream because it only exists to support Plymouth. hibernate-Disable-in-a-signed-modules-environment.patch - another one-liner that there's considerable room to disagree whether it should be upstream. Yes, it enhances security. However, it also puts a significant crimp in usability. Most of the Android patches are in a similar boat - they're probably not that hard to drag along release to release, but they're almost impossible to upstream due to philosophical differences.