Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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.
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)
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.
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.
Quote:
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
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.
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.
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.
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?
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.
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.
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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.