Printable View
For people interested in makeing their linux box faster better cooler..
the big Kernel Hacking howto is the one to read for u.
I found it helpfull. Finaly my cheap-ass tv-card is supported by linux.
http://www.kernelhacking.org/docs/ke...WTO/index.html
JinX
Do you really find that a kernel that is compiled is noticably faster?
I used to build my own when I was running SuSE 6.2 to address problems with the RAID card but now I find the standard kernels actually run well.
I think it is. Yes, the standard kernels run fine, but they're bloated. Back in the day, distros came with only a bare-bones kernel that got the system up and running, and that was about it. Now, we have all these distros trying to go mainstream, so they're compiling in everything but the kitchen sink to try and work with as much hardware as possible out of the box.
Removing undeeded funtionality will make the kernel smaller and faster, and code that is compiled directly into the kernel, as opposed to a module, will execute faster because the kernel doesn't have to stop and load/unload the module. I think there is a noticeable performance improvement in a custom kernel.
Then, of course, there are the security implications of removing unneeded options and disabling loadable module support, because modules give an attacker an easy avenue to insert malicious code into a running kernel.
So yes, there are good reasons to do it.
I remember when it was necessary to to modify CFLAGS and HOSTCFLAGS in the make file to optimise the kernel for Pentium Processors but these kernels are now standard.
I'm never sure if the modules are hazards, and the logic, don't load it if you don't need it, seems compelling. The monolithic kernel locks you into a moment of time, and my luck always works as follows. The driver that I need gets updated 30 seconds after I build the kernel.
The original post had nothing to do with "compiling a custom kernel." Kernel hacking is writing code and developing drivers for unsupported hardware and/or improving existing drivers.
I disagree. The kernel doesn't load/unload any modules. Unless, you have enabled automatic module loading support (or whatever the name is), and in that case it will automatically load a module if it is needed. Such an example would be when you start X-windows and the kernel automatically loads your DRM module.Quote:
code that is compiled directly into the kernel, as opposed to a module, will execute faster because the kernel doesn't have to stop and load/unload the module.
In fact, having modules could actually speed things up. If you don't have a use for a certain peice of hardware at the time, then what is the point of wasting your memory with uneeded drivers?
--Sudo
Indeed, I manualy had to change a bttv-module to get the tuner of my television-card working.
I had a lot of help from the HOWTO above..
as for compiling ur own kernel..
that is ALWAYS faster..
not only less bloated, also optimized for ur gear..
I am a slackware user and usualy don't even download the .tgz slack-packs..
Stick with the source and you'll allways outrun any .rpm based app..
Thanks for the link Jinx, I can actually benefit from it. Im thinking of working on my own of it.. Till then, it's strickly my VisualBasic stuff.
We had started the over haul of the Mylex Raid card driver, which back in the SuSE 6.2 days had to be compiled into the kernel if you wanted YAST to work.
By the time we were into our 6th or 7th build, having hacked on the device driver for 2 weeks- Freshmeat annouces a new driver. A RedHat -rpm. (Dandelion comes through)
Download the RedHat iso's and we are on our way.
This seems to be the hackers problem. The production kernel is announced, within 8 months the source is updated 18 - 19 times. This time out (the 2.4 kernel) the Grub loader had problems with the Mylex controller, no one here even thought that hacking the driver was a good idea. Use lilo and wait, it will get fixed (It was)
We play with the odd numbered kernels to get a feel for what is coming and tweaking is always fun BUT unless you do nothing else the new kernels just come to quickly.
so true,
usualy the kernels update too d4mn fast...
and waiting a bit or fondeling with other software solutions works better.
unless u use "exotic" hardware, most companies only bring out (closed source) windows drivers..
so then ur on your own..
That seems like a lot of work when all you should need to do is install Redhat's package manager... not the whole distro.Quote:
Thankfully that's slowly changing. I am looking forward to the day when I can buy any hardware I want without worrying whether or not it will work in Linux.Quote:
Originally posted here by the_JinX
most companies only bring out (closed source) windows drivers..
so then ur on your own..
--Sudo
One of the big problems with not compiling your own kernel is that most kernels will run basic i686 or i586 code on your machine.
In RedHat 7.1 my Athlon Thunderbird 1.2GHz is detected as only an i586 processor. I can recompile the kernel for the athlon directly, which will incredibly optimize it, so that my linux box isn't running as if it were simply a Pentium 1.2GHz (a slight exaggeration, I know).
Excellent point. The same applies to all software on Linux. Why download binaries that use the i586 instruction set when you have a P4 or a AMD processor? This is why I try to compile all of my software from source, so that it will be optimized for my P4 using the i686 Inst. set. But if you insist on using binaries, find one that matches your setup.Quote:
Originally posted here by chsh
One of the big problems with not compiling your own kernel is that most kernels will run basic i686 or i586 code on your machine.
In RedHat 7.1 my Athlon Thunderbird 1.2GHz is detected as only an i586 processor. I can recompile the kernel for the athlon directly, which will incredibly optimize it, so that my linux box isn't running as if it were simply a Pentium 1.2GHz (a slight exaggeration, I know).
--Sudo