Well, the basic reason is that the patches on developerworks are meant to be applied on an unchanged "vanilla" kernel as from http://www.kernel.org
Every distributor patches the kernel in a way so that the patches on developerworks may or may not apply cleanly. Apart from applying, it is also the question whether the compiled kernel (with distributor specific patches together with the patches from developerworks) works as expected. The intention of developerworks was (and still is) to provide code for the vanilla kernel so that everyone can have a look at them, can roll their own system and can provide feedback. So, in a way it is IBM's Linux/390 interface to the Open Source world. Patches are labelled "recommended", if the pass the tests, otherwise - if they are still in development or the testers have not run all their testcases - they are marked "experimental". In parallel, we are working actively to get the recommended patches integrated into the mainstream places (official kernel tree, official gcc tree, etc.). Developerworks is also the interface to all distribution partners. Just as they have the original kernel sources as well as a huge amount of other sources and experience for their own kernel (and other tools), they use developerworks as one of their sources. So, regarding the timer patch (and other code on developerworks) you have several choices: Roll your own with the vanilla kernel and the description which patches have to be applied in which order. Roll your own with the distribution kernel and resolve the problems (here the --dryrun option of patch might be of help). Ask your distribution partner to provide an update of their distribution (or ask about their plans) which includes the features you need. Kind regards, Christoph
