Can I find the base version of the *.patch file? - linux-kernel

I see https://patchwork.kernel.org/.
I have an old question.
Various *.patch files for the linux kernel are available on the Internet.
However, I can not tell which kernel version I created the patch file with.
For example, there is https://patchwork.kernel.org/patch/6509121/.
At the bottom of the page is a patch.
Can I find out which Kernel version or git version patch file this patch contains?
I wondered about https://patchwork.kernel.org/ or any other source code.
What rules are there?
Or should anyone try to apply it with patch files?

Related

How to port patches created for older kernel version to new version without changing the original maintainer

While building yocto images for various SOCs, patches are used to add the internal changes to the mainline kernel. When a new kernel version releases, sometimes the old patches fail at a couple of hunks (say 2 out of 6). Now, I want a way to preserve the older patch with maintainer name, subject or other metadata. But I cannot find any tool which can do this.
I have used rediff from patchutils. It works fine for adding or removing new lines and even removing hunks but it fails if the new change is not in line with the patch. So, is there any tool or a way, the kernel developers maintain the patches?

TortoiseGit Apply patch serial

Im trying to apply serial patch files (like 22 serial patch files) and when I have a merge issue using tortoise, patch stops, i manually fix the conflict, but the patch never resumes.
Anyone knows a good tutorial or video that explains how to do it with tortoise git? (using latest version)
Tx!
For future reference, this is the best that I have found
https://tortoisegit.org/docs/tortoisegit/tgit-dug-patch.html

Source code is different from original version

We are working on a .NET application and recently started using Git for version control.
Our latest release was tagged in Git, and now i am trying to debug some issue.
Here's what i did:
Installed the app (from the release) on my Pc.
Checked out the tagged release version.
Started VS and attached to the process.
Placed breakpoints over some part of the code.
I am getting the message: "Source code is different from original version", however this is the actual code that was compiled to release this installed version.
What am i doing wrong here?
using VS2008 if that matters.
BTW: What is the mechanism that is used to compare if the binaries are different from source code?
When cloning the repo from Git, for example, it will change all files/folders date to the current date. Is this value (datetime) used to determine source code vs. binary?
The problem was i didnt use (or store) the original symbols for this release.
I previously thought symbols only contained source code line information and were not needed to actually debug the program under VS. apparently i was wrong.
A good resource on symbols for anyone who's looking into problems with them: http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
This post also contains a few other links to MSDN Magazine with more valuable information.

How to patch linux kernel to add gyroscope support

I'm trying to use MPU3000/3050 by Invensense with embedded linux (ARM-based LPC3141 board, Embedded Artists).
I found this interesting patch on the Internet
https://patchwork.kernel.org/patch/703991/
how can I implement it in my kernel?
Read this article for detailed instructions on how to apply a patch.
Warning: kernel patches are quite often highly specific to the version of Linux they were developed for, so if your kernel version is different from the one the patch was originally made for you may encounter some problems.
Edit: I had a look at this particular patch and essentially it creates a new file (mpu3050.c) and modifies drivers/input/misc/Makefile and drivers/input/misc/Kconfig. Even if everything else fails the new file should be created, and the mods to the existing files can probably be done manually.
I don't know about the details, but you should download the kernel from www.kernel.org, patch it with the 'patch' utility and configure it to compile it. You should search some manuals for the configuration.
I am not sure if you already knew this, though.

Patching Linux Kernel

I have a set of patch files which was used to patch the Linux 2.6.29 kernel for supporting my custom functionality.
I would like to know if it is possible to use the same patch files to patch my new kernel (linux 2.6.32) for getting the same functionality.
Thanks & Regards,
Sen
The patch is always dependent on the kernel version. How well the patch applies depends on how different the version which it was made for vs. the version it was applied to is. In the best case.
There will be four possibilites:
Neither the file, data structures, or APIs have changed, and the files will just cleanly apply.
The data structures and APIs have not changed, but there were minor changes to the file outside of your patched area. So, patch will work, and give you minor errors indicating the lines were shifted a bit.
Some of the code inside the patched area changed, so the patch will not apply. You will have to manually figure out what these differences are, and possibly apply that section of the patch manually to get it to apply. Patch will fail, and will save a ".rej" file showing the rejected section.
Functional changes have been made to the code, data structures, or APIs have changed. So you will not be able to port the patches without figuring out how the underlying code has changed, and modifying the patches to apply to the new paradigm. Of course, you might not know this is the case, and you may have a patch that applies just fine, but then the kernel crashes - so beware! ;-)
There is no definitive answer here. It heavily depends on the contents of the patch and the code that it touches. If it's the addition of a new module, it'll probably. Get both versions of the kernel and diff the relevant code pieces to see if they have changed much. If your patch is for a piece that haven't changed, you're in luck.
of course you can apply your patches with a new Linux version. At least you can (and should!) try to do so. If you're lucky it works... But it really depends on the patches and how version dependend they are.
Philip

Resources