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
Related
I have a utility service x which is in maven repo and is used by some of my other services. We normally update the minor version of the service x when we make small changes and we are currently on version 1.0.15.
No I am making another change and I was thinking whether I should update version to 1.0.16 or I should update the version like 1.1.0.
If anyone can provide an explanation on how this should be done in general, that would I am sure help other developers as well as me. Please let me know if you need further information.
Different projects follow different standards on this, so follow what the repository has done to date.
A well-regarded standard for this is called Semantic Versioning (https://semver.org/). If you are starting a new project or there isn't a standard already in place, I would recommend using this.
Semantic Versions are in the format: MAJOR.MINOR.PATCH.
If you have fixed a bug: increase the patch version
If you have introduced new functionality in a non-breaking way: increase the minor version (and reset patch to 0)
If you have introduced breaking changes: increase the major version (and reset the patch and minor version to 0).
If you are unsure whether your change is a breaking change or not - consider your package (or API) from its consumers' perspectives. If their code has to change as a result of your change then it's a breaking change.
I am creating a PythonAnalyzer using the following code:
var interpreterFactory = InterpreterFactoryCreator.CreateAnalysisInterpreterFactory(
PythonLanguageVersion.V36.ToVersion());
var analyzer = PythonAnalyzer.Create(interpreterFactory);
Later on I also create and analyze a simple python module, that looks like this:
name = input('What is your name?\n')
print('Hi, %s.' % name)
Then I do module.Analysis.GetValuesByIndex("name", 4).
At this moment I expected the "value" to be 'str', because that's what Visual Studio shows when I open the same file in it. However, I get 'object' instead. So it seems that the PythonAnalyzer when constructed as mentioned above lacks some important information about where to look for standard library and/or its types.
Unfortunately, the documentation on PythonAnalyzer is lacking, so I was hoping the community could help understand how to configure it properly.
Congratulations on getting so far :)
What you're hitting here is the fact that CreateAnalysisInterpreterFactory is really intended for "pure" cases, where you have access to all the code that you're trying to analyze and nothing needs to be looked up. It is mostly used for the unit tests, or as a fallback when no copies of Python are installed. Depending on precisely which version of PTVS you are using, the bare information you're getting is either coming from DefaultDB\v3\python.pyi or CompletionDB\__builtin__.idb, both of which are somewhat lacking (by design).
Assuming you have a copy of Python installed, I would suggest creating an instance of InterpreterConfiguration with all of its details, and passing that to CreateInterpreterFactory (without "Analysis").
If you're on the latest sources (strongly recommended), this may run the interpreter in the background to collect information from it (you can control caching of this info with the DatabasePath and UseExistingCache members of InterpreterFactoryCreationOptions). If you are using the older version still, you'll need to trigger a completion DB regeneration or have one that you've created through VS.
And a final caveat: this part of PTVS is currently under some pretty heavy development at time of writing, so you'll either want to keep updating the version you're working against or stick with a slightly older one. Also feel free to post questions like this on the GitHub site, as while this is technically public API, it's barely documented at all and so the best help will come from the dev team.
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.
I'm developing a site for my company and I also need to modify the native component "mailto" to fit our needs.
I'm working with a joomla 2.5
I was wondering if future updates occur, what will happen to the lines I've added, for example, in "\components\com_mailto\controller.php"...
I haven't find answers on the net.
Also, for the same reason, I've modified the default layout of an article. Should I rename it? and if yes, how, because I couldn't do it (when I've tried the article did not display).
Thanks for your help
Before starting to edit core Joomla components, should should always have a look at the options you have. I don't believe in editing core file as it simply causes problems for updates when released, therefore in my opinion, you have 2 options:
I always make a note of all my requirements and start looking for a 3rd party extension that caters for my requirements.
If I cannot find a 3rd party extension and don't particularly want to start digging into it's code, I would go with developing a plugin. Plugins are used to manipulate the behavior or something and therefore come in extremely handy for when you would require core editing.
Editing the layout of an extension view is completely fine, but it's strongly recommended you make a Template Override so that if the extension does ever get updated, your changes won't get overridden.
So to answer you initial question, any line you have added to the controller.php file will get overridden when you decide to update the extension.
Hope this helps
While the answer from Lodder is totally valid, as a last resource you can also consider forking the com_mailto as a separate component.
This has some disadvantages:
you need to rename all the files involved (controllers, models, views)
you need to maintain it and keep in in sync with future updates (consider than you are now on 2.5.x and in a year you might want to upgrade to 3.x).
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.