1st steps into compiling kernel

[PastAsNew]

I'm an experienced C/C++ programmer but completely new to Linux. I want to get into kernel and device driver programming, and there is something I need to understand before I go any further.

• If different distributions claim to have the same version of kernel, is it absolutely certain that they will have been built using identical kernel source? Or will their kernels simply be "based on" the same kernels?
• I get the impression from stuff I've read I should not compile the source provided by my distribution (KateOS 3.6 in my case), but download the original kernel source to compile on one side, so to speak. Does this seem right?

Grateful for any help. Thanks.

[oz]

The kernel source comes from here:

The Linux Kernel Archives

The developers working on the kernel for each distribution modify and patch the kernel as they see fit for their particular distribution.

Check this link for working with the kernel:

http://www.digitalhermit.com/linux/K...ild-HOWTO.html

...it's never failed me.

[i92guboj]

If different distributions claim to have the same version of kernel, is it absolutely certain that they will have been built using identical kernel source? Or will their kernels simply be "based on" the same kernels?

You can't be 100% sure. Most distros will -indeed- patch the kernel to a greater or lesser degree. Most distros are sane enough not to throw a thousand patches there, at least not in the official main kernel for the distro. Some of them might offer different kernel patchsets that you can use if you wish, for example Gentoo does this. It also offers a package with the vanilla kernel as from upstream.

In any case, the distro documentation or the dev mailing lists or forums will probably be a good place to start researching that. Some distros will offer the kernel already patches, some offer separate patchsets, it just depends on how the packagers for the distro do the work. However everything that's released as gpl must be made available in source form.

Whether these patches are going to play games with your own ones only depends on the sections of the code that you are going to patch.

I get the impression from stuff I've read I should not compile the source provided by my distribution (KateOS 3.6 in my case), but download the original kernel source to compile on one side, so to speak. Does this seem right?

It depends. If you only intend to produce and support this patches for kateOS (whatever that is, I've never heard of it) then by all means use whatever it provides. But if you want the patch to work with the most distros you are going to have to use a vanilla kernel source tree. And depending on what you are going to do, you might also need to concentrate on a particular version, because the kernel changes every day and there's no guarantee that your patch for vanilla 2.6.28 will work in .29 or .30

[PastAsNew]

It also offers a package with the vanilla kernel as from upstream.

I hit a bit of an Eric Morecambe moment here ... understand the words but not quite in that order . By vanilla do you mean the pure unadulterated kernel source? And by upstream do you mean before anyone's had their wicked way with it?

[PastAsNew]

The kernel source comes from here:

The Linux Kernel Archives

The developers working on the kernel for each distribution modify and patch the kernel as they see fit for their particular distribution.

Check this link for working with the kernel:

http://www.digitalhermit.com/linux/K...ild-HOWTO.html

...it's never failed me.

Am I right in thinking the first link is the place to go for the official unadulterated versions of Linux source - vanilla I'm guessing people call it? And the second link looks excellent, albeit a tad terrifying; I'll no doubt be spending much time there.

[i92guboj]

Am I right in thinking the first link is the place to go for the official unadulterated versions of Linux source - vanilla I'm guessing people call it? And the second link looks excellent, albeit a tad terrifying; I'll no doubt be spending much time there.

Yep. That's the official kernel place. Where the Linux kernel lives, unpatched, in all its glory. The first thing you should be doing to get in touch with this, is to learn how to build a working kernel. It can be illustrative as well to see how the cumulative patches work, and how to upgrade your kernel in that fashion.

That's will also serve as an exercise if you don't used the patch tool in the past so much. You will probably have to use it a lot if you are really going to get into kernel programming. Patch and diff, that is

[PastAsNew]

Yep. That's the official kernel place. Where the Linux kernel lives, unpatched, in all its glory. The first thing you should be doing to get in touch with this, is to learn how to build a working kernel. It can be illustrative as well to see how the cumulative patches work, and how to upgrade your kernel in that fashion.

That's will also serve as an exercise if you don't used the patch tool in the past so much. You will probably have to use it a lot if you are really going to get into kernel programming. Patch and diff, that is

Many thanks

[vonbiber]

I don't know about kateos but I do know that some distros patch their
sources.
There should be something in the doc that should tell you so.
I use slackware (12.2) myself.
The kernel sources provided by slackware are not tampered with.
Instead of rebuilding with the same version I prefer to download
the latest kernel version (2.6.29.1). I built this new version.
After a couple of trials and errors I was able to boot on it
(I always make backups of
/boot/vmlinuz* /boot/config* /boot/System.map* and
/lib/modules/$(uname -r)
so that if anything goes wrong I could revert to the old version)

Before you start building you should make a checklist of things
that should be set in the config (filesystems, framebuffer, your
hardware driver support, etc.)

I followed these steps (after unpacking the linux-2.6.29.1.tar.bz2 in /usr/src)

cd /usr/src/linux-2.6.29.1
version=2.6.29.1
make menuconfig
make bzImage modules
cd /boot
mkdir backup
mv vmlinuz* System.map* config* backup
cd /lib/modules
mkdir backup
mv $(uname -r) backup
cd /usr/src/linux-$version
cp System.map /boot/System.map-$version
cp arch/x86/boot/bzImage /boot/vmlinuz-$version
cp .config /boot/config-$version
make modules_install
cd /boot
ln -s System.map-$version System.map
ln -s vmlinuz-$version vmlinuz
ln -s config-$version config

[PastAsNew]

Before I can go any further I need to clear something else up. It was suggested to me I intall Git and then clone in the whole kernel repository, which I've done. Seems a good idea 'cos then I can diff changes others have done and maybe learn stuff. But two key problems at this moment with that ...

• Running 'git tag' shows me all the labelled tags, but none of the patched versions are in this repository. So it therefore has 2.6.29 but not 2.6.29.1 for instance. Are the patched versions held in a separate repository?
• When I cloned in the repository it did an automatic checkout for me at the end of that. How can I check what version is checked out at any time - I cannot suss a git command to do this.

And beyond this, am I maybe making my newbie life even more difficult by trying to run with Git? Version control in itself is not a problem for me, but does it introduce cascaded complications for me at this time - patch versions for instance?

[PastAsNew]

My brain feels like a grenade's gone off inside it ... I am so confused ... cascaded/nested confusion!

• Can you build a development kernel without affecting your currently running kernel?
• Is there any way of debugging your development kernel without trashing your current kernel, and without it being the default kernel at boot time?

Thanks