Hi Folks
Just because I am trying things where I never went before..

From the repositories (Debian, Ubuntu, Mepis, etc) it is possible to get "kernel-sources-<various_versions>"
One can also get "kernel-headers-<various_versions>"

As I understood it, headers are the C files with a ".h" extension that are called in to be included by the C programs to make available functions necessary for that program.

1. Does installing the kernel-sources package automatically include all the header files needed?

2. Does one need to install the kernel-headers package available separately?

3. What kinds of applications compiling can be done having the headers available only?

4. When compiling a new kernel, is the kernel-sources package enough?

Thanks G

Kernel headers packages are a subset of the kernel source. You only need one of them. If you are not compiling a custom kernel, and are not interested in looking at / changing the code in the kernel you can install the kernel headers package rather than the kernel source and save disk space and download times.

You don't use the kernel headers to compile applications (except in VERY rare cases, like for example <a href=http://valgrind.org/>valgrind</a> or similar applications that deal with the kernel. Most likelty you will neverr need them, as you should use your package manner. It is seldom necessary to build from the source these days. If you use a decent distribution only very esoteric applications will be unavailable from the distributions repositories.

You will need the actual tools required to build the kernel of course, such as GCC (the compiler), but beyond that the source package - (and a lot of research and perseverance) - is all that is required to build a custom kernel.

The kernel headers define the interface between the userspace (regular) programs and the kernel. They were pulled out of the kernel itself to ensure that the interface stays the same between different kernel versions, so that programs do not need to be changed or recompiled when the kernel itself changes.

1) Installing the kernel source should install any dependant packages, including the appropriate version of the kernel headers.

2) No, if you use Synaptic or apt-get, the dependencies will be installed automatically. This also has the advantage that the system can automatically uninstall the headers package if the source package is removed (unless something else depends on it).

3) You only need the kernel headers to recompile any program. Obviously, you still need the kernel source to recompile the kernel itself, but that's the only thing it's used for.

4) You still need the headers to compile the kernel. But you shouldn't need to worry about that since the headers package will be automatically installed as a dependency.

I don't have answers to all of those questions, but I will say that you should not install new kernel headers unless you have a good reason to, because doing so will cause issues with gcc.

My thanks to all of you folk.

I have 4 Distros, each on their own partitions, and the GRUB menu.lst for the first of them gets to be the place we can choose which to boot. Obviously one is the main tructes stable one, and the rest are being tried out for curiosity. The Windows chunk has been commented out so long I have reformatted its space.

Most times, I am happy with the kernel the Distro comes with. Making a custom kernel is not so hard if one follows all the instructions. Getting it accepted by the rest of a pre-installed system is more awkward.

I wanted a low-latency kernel for real-time audio.
Is it possible to turn on/off or redefine just about any kernel configuration line simply by putting the new value as a kernel boot option on the boot command - instead of doing a whole recompile just to knobble one thing?

(In this case to set the TICK from 250Hz to 1000H)

Take a look here for all possible kernel parameters:
http://www.kernel.org/doc/Documentat...parameters.txt

Some things cannot be changed dynamically on boot like this, one of those things seems to be the Tick that you're talking about, I don't see it on there.

Thanks for the link.

I can see in it that the CONFIG_NO_HZ=y kernel setting can be done by passing the nohz=y (or n) to switch on or off the "tickless mode". This is the default anyway.

Unfortunately, the other parameter cannot be tweaked so easily. This is a snippet from the kernel config file copy kept in /boot.
CONFIG_HZ=1000, it seems, can only be had by recompiling. I am unsure whether using tickless mode would make the other parameter unnecessary.

Either way, I am not going to be messing with this rather nice MEPIS to get there. Instead, my dodgy kernels will be confined to a different partition. Also, I am thinking that crux or slack or some other distro more dedicated to real-time tasks would be a better way.

Examples for #3 - Kernel Headers Only.

nVidia Proprietary video drivers
ndiswrapper
Wireless card Drivers
etc..

for a decent list you could simply type m-a (provide you have module assistant installed) Choose the SELECT menu option, and then browse the list of various modules you can compile, using the Debian module assistant method.

I typically shortcut to install kernel headers when needed in Debian..
aptitude update
m-a update
m-a prepare

the current headers for my running kernel, are downloaded, installed and linked and I am ready to compile my module.

There are only a few options to change if you want to make your kernel low-latency. As usual there is a balance between throughput and latency.

When configuring your kernel go to and change the following:
Processor type and features --->

Preemption Model (Preemptible Kernel (Low-Latency Desktop))
Preempt The Big Kernel Lock
Timer frequency (1000 HZ)

That's all 3 of them, then recompile, install it, and possibly modify bootloader options as necessary.

Thanks H_TeXMeX_H.

I did exactly that.
Compiling a kernel is not as fearsome as some may think. Getting it to boot is also straightforward. Using make menuconfig also give the opportunity to lose huge piles of compiled stuff that will never be needed, for hardware that just is not present.

The problems arrive with certain software - eg. the NVidia graphics card driver module won't play. So un-install the NVidia, and start again, to recompile a nVidia module with the new kernel.

Besides the 3 options you mention, one can set up priorities to favor certain processes (eg. real-time 192kH sampling multichannel audio cards). This would not be appropriate in a mailserver (say). I am still reading the tips on how to do it.
Also, the way to get high throughput is to assign the highest priorities to the slowest intermittent processes. This is not always intuitively obvious.

In this case, incoming streams of (satellite data) to the soundcards cannot be interrupted unless the departures are too swift to trouble the buffering. At 1000Hz, the desktop and screen response will be fast, as will real-time audio/video. This is bound to be at the expense of some other processes.

for farslayer

When you have compiled your module, what is the next essential step to ensure it gets loaded - or do you have to load the special ones when you invoke the applications that need them?

Thanks ..
G

man modprobe
man modules

those should cover manually loading a module, and having a module load automatically at boot time.

others of related interest: insmod, lsmod, modinfo, modprobe.conf

is there a particular module you are interested in ? webcam, wireless, video, other ?

Yes, that is a small downside, that all modules must be re-compiled, one being the nvidia drivers.

You'll have to make decisions as to whether you want throughput or low-latency/real-time.

The lower the Timer frequency the fewer timer interrupts, the higher the throughput, what you would want on a server, something like 100 or 250 Hz. 300 Hz is the minimum recommended for multimedia work.

Preempting the Big Kernel Lock is optional, and does make the kernel more low-latency.

The Preemption Model goes from greatest throughput No Forced Preemption (Server), to less latency Voluntary Kernel Preemption (Desktop) and medium throughput, to Preemptible Kernel (Low-Latency Desktop).