How to patch linux kernel to add gyroscope support - linux-kernel

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.

Related

How can I modify, compile and install tun.ko?

I've never compiled a single kernel module. I would like to understand how to change the source of a kernel module, compile and install it on Debian SO.
Can someone illustrate the steps or tell me a tutorial about it?
Thank you and everyone.
This question is a bit confusing since a .ko file represents a kernel object. In other words, it has already been compiled.
To edit the module you would need the source code, most likely tun.c and some related files.
StackOverflow is more meant for specific questions to be answered, not a tutorial site. Please do some research about Linux modules and make an attempt to install the module yourself. Some good sites for beginners:
kernel.org
https://www.oreilly.com/library/view/linux-device-drivers/0596005903/
http://derekmolloy.ie/writing-a-linux-kernel-module-part-1-introduction/
The last of these is the least comprehensive, but quickest to get you up and running. Once you get to the point where you have detailed questions, post them here and you will get better help.

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

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?

Dependency solution when make/compile error from source code

Very often we need to install software from its source code. Most of the time I just hit "make world" or "make all" then it will work like a charm. But some other time we see make errors, and we need to install other packages in order to let the make go through. This is particularly a problem for compiling low-level systems, such as a Linux kernel or Xen hypervisor.
I have one experience with Xen 3.4. Maybe it has been documented in some corner documents, but it depends on udev-125 to work properly. The weird thing is it functions well most of the time when udev version is 160+, it only breaks in certain cases! It took me a few MONTHS to find out it was because of the wrong udev version!
To make developers' life easier, when a source code is made successfully in one machine, is there some tools to record the list of packages and versions of that machine? Such a 'snapshot' should be shipped with the source code as well, so that when someone meets the make error they at least have a successful 'snapshot' for reference.
Is there such a tool already?
If your software depends on a specific version of a dependency, you should write a check for your configure script/cmakefile/etc. that tests the version of the dependency and bails out if the wrong version was found.
Comparing the output of config.log (a file created by a configure script) can also help diagnose problems like you encountered.

STXXL vector_type does not seem to work

I wanted to try STXXL to find how efficient it is in reading a big data file from the disk.
So i setup the enviornment for using it.
Then i ran this program http://algo2.iti.kit.edu/dementiev/stxxl/tags/1.2.1/algo_2sort__file_8cpp-example.html in VS2010. However the file data was not mapped to the vector_type, in fact it deleted the contents of the file after this statement - vector_type v(&f);
I tried changing from stxxl::file::RDWR to stxxl::file::RDONLY, this time the file content was not deleted, however still the vector_type variable was empty.Request your support to proceed further.
Also, is STXXL used widely in commercial applications?
Best Regards,
Ramki.
You are running a code example from STXXL version 1.2.1, which version have you installed on your system?
Most up-to-date version is "Development 1.4" which comes with many improvements, a comprehensive documentation with a lot of short code examples and runs pretty well - check the official STXXL Website under "Downloads and Documentation". Using version 1.4 is highly recommended.
Please check if your problem still exists on the new "Development 1.4" version. The Installation Process has become much easier - read the Installation and Configuration Part of the Documentation at first.
The official webpage provides a (certainly incomplete) list of Publications,Ongoing and Completed Projects using the STXXL successfully - there is no reason why not using it in an commercial environment.

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