Compiling a Patch

[Tsarevich]

Okay, so have compiled a kernel before, but never a patch. First, there are two kinds of patches. One: a tarred pack as you have on kernel.org. While one is a .c.diff file. So what do we do with it?

I want to compile this: http://steve-parker.org/speedtouchconf/n_hdlc.c.diff

[i92guboj]

Okay, so have compiled a kernel before, but never a patch. First, there are two kinds of patches. One: a tarred pack as you have on kernel.org. While one is a .c.diff file. So what do we do with it?

I want to compile this: http://steve-parker.org/speedtouchconf/n_hdlc.c.diff

You don't *compile* a patch.

You *apply* the patch to your kernel sources, and then compile the kernel as you always do.

For example, if you have your kernel sources in $$HOME/linux-<version>/ you would do this:

cd $HOME/linux-<version>
wget http://steve-parker.org/speedtouchconf/n_hdlc.c.diff
cat n_hdlc.c.diff | patch -p1

After that, you just make menuconfig or whatever you usually do to configure your kernel, set the new options if any, and compile and install your kernel as always.

Some things to consider:

- The -p<number> parameter might be different, it depends on how the patch was made. Just try -p1, -p0, -p2 or whatever

- The patches are usually designed for a given kernel version. There's is a chance that it will work with other versions as well. But don't blindly assume it. When patching, look out for error messages about "rejects". Sometimes, these rejects are easy to fix, but it depends.

[valan]

patch -p1 < n_hdlc.c.diff

http://www.linuxheadquarters.com/how...nelpatch.shtml

[i92guboj]

patch -p1 < n_hdlc.c.diff

Linux Headquarters: Applying a Kernel Patch

The good thing about the other way, is that it's easily adaptable for patches that are compressed using bzip2 or gzip.

cat n_hdlc.c.diff | patch -p1
bzcat n_hdlc.c.diff | patch -p1
zcat n_hdlc.c.diff | patch -p1

Which makes it very convenient.

[Tsarevich]

So you have to recompile the kernel for a patch?

[i92guboj]

So you have to recompile the kernel for a patch?

Of course. That's a patch for the sources. If you change the sources in any way (either manually or via a patch) you need to recompile them to get a new binary with all the new features.

In linux you will not find the tipical binary patches that you are used to in Windows, in case that that's what you were thinking about... It would be completely unpractical and non-portable.

[Tsarevich]

Okay, all commands give a similar output. So there's no point of the last commands coz its not a gzipped patch. Here's one output with the -p1 argument:

----------------------------
Reversed (or previously applied) patch detected! assumme -R? [n]

I do 'Y'

Then Apply anyway? [n]
-----------------------------

I do the same 'y' and a .rej(ected) file is written to drivers/char/n_hdlc.c.rej.

With the other (-p{2,3}) args, the system can't find the file.

I am totally frustrated.

[i92guboj]

What kernel version are you trying to patch?

[Tsarevich]

2.6.23.9 or I can also download 2.6.25 if required.

[i92guboj]

----------------------------
Reversed (or previously applied) patch detected! assumme -R? [n]

I do 'Y'

Then Apply anyway? [n]
-----------------------------

2.6.23.9 or I can also download 2.6.25 if required.

Well, That error usually means that the patch has already been applied, so there's no poing in applying it again. And that's fine, since the patch you are willing to use was designed for 2.4.x kernels, and you are trying to apply it on a 2.6.x kernel which already seems to include the features you are trying to get with the patch. So, there's no point in using the patch.

Look at this fragment, the first few lines of the patch:

*** linux/drivers/char/n_hdlc.c	Fri Feb  9 20:30:22 2001
--- linux-2.4.3/drivers/char/n_hdlc.c	Tue May  1 17:25:06 2001

It was made against 2.4.3.

Also, look at the instructions on that web site:

SpeedTouchConf - Home

Somewhere in the middle of the page you can read:

Requires kernel 2.4.18+ OR N_HDLC patch
Many distros (including Ubuntu) now use Debian, not all can be tested, but Debian in general is no problem.

Notice the "OR".

It seems that you don't need to patch the kernel at all.