Custom Fedora RPM kernel...

[Thetargos]

Hello all... I made some RPMs based on a custom set of patches, preserving all of the Fedora's official patches (now thtat the kernels are not based off the -AC tree). For the time being I only have AMD64 packages built and am in the process of building generic x86_64, athlon and i686 packages of these. However I'd like to know before I put my machines to build these, if any one would be interested in testing them and provide feedback.

These packages are (as I said above) based on the official Fedora pathces and (for the time being) the Con Kolivas tree (to provide lower latency desktop and overall improved system performance) and the -nitro (http://forums.gentoo.org/viewtopic-t-401300.html) patch normally used by Gentoo people (yes I have too a gentoo system).

The full list of patches applied follows:

patch-2.6.14.2.bz2
blackhawk-logo.patch -- A quick and dirty logo I made, most probably I will change it with the newer Fedora logo

Fedora Patches.

linux-2.6-bzimage.patch
linux-2.6-x86-tune-p4.patch
linux-2.6-x86-apic-off-by-default.patch
linux-2.6-x86-vga-vidfail.patch
linux-2.6-ppc64-build.patch
linux-2.6-ppc64-eeh-panic.patch
linux-2.6-serial-of.patch
linux-2.6-xen.patch
linux-2.6-xen-additional.patch
linux-2.6-xen-compile.patch
linux-2.6-build-nonintconfig.patch
linux-2.6-build-userspace-headers-warning.patch
linux-2.6-build-qconfig-qt-lib64.patch
linux-2.6-build-reference-discarded-opd.patch
linux-2.6-execshield.patch
linux-2.6-execshield-xen.patch
linux-2.6-execshield-vdso.patch
linux-2.6-xen-vdso-note.patch
linux-2.6-modsign-core.patch
linux-2.6-modsign-crypto.patch
linux-2.6-modsign-ksign.patch
linux-2.6-modsign-mpilib.patch
linux-2.6-modsign-script.patch
linux-2.6-modsign-include.patch
linux-2.6-debug-slab-backtrace.patch
linux-2.6-debug-list_head.patch
linux-2.6-debug-taint-vm.patch
linux-2.6-debug-taint-check.patch
linux-2.6-debug-singlebiterror.patch
linux-2.6-debug-spinlock-taint.patch
linux-2.6-debug-spinlock-panic.patch
linux-2.6-debug-Wundef.patch
linux-2.6-debug-disable-builtins.patch
linux-2.6-debug-sleep-in-irq-warning.patch
linux-2.6-debug-reference-discarded-return-result.patch
linux-2.6-debug-panic-stackdump.patch
linux-2.6-devmem.patch
linux-2.6-devmem-xen.patch
linux-2.6-crash-driver.patch
linux-2.6-crash-xen.patch
linux-2.6-sleepon.patch
linux-2.6-default-elevator.patch
linux-2.6-max-symlinks.patch
linux-2.6-optimise-for-size.patch
linux-2.6-default-clocksource-tsc.patch
linux-2.6-scsi-advansys-enabler.patch
linux-2.6-scsi-megaraid-legacy.patch
linux-2.6-scsi-advansys-pcitable.patch
linux-2.6-NFSD-non-null-getxattr.patch
linux-2.6-NFSD-ctlbits.patch
linux-2.6-net-sundance-ip100A.patch
linux-2.6-net-atm-lanai-nodev-rmmod.patch
linux-2.6-net-acenic-use-after-free.patch
linux-2.6-crashdump-common.patch
linux-2.6-netdump.patch
linux-2.6-netconsole.patch
linux-2.6-diskdump.patch
linux-2.6-crashdump-reboot-exports.patch
linux-2.6-dump_smp_call_function.patch
linux-2.6-procfs-i_nlink-miscalculate.patch
linux-2.6-atkbd-dell-multimedia.patch
linux-2.6-mcs-canonicalise-getxattr.patch
linux-2.6-module_version.patch
linux-2.6-ide-floppy-eject.patch
linux-2.6-cx88-silence-debug.patch
linux-2.6-swsusp-nofreeze.patch
linux-2.6-input-kill-stupid-messages.patch
linux-2.6-input-usblegacy.patch
linux-2.6-serial-tickle-nmi.patch
linux-2.6-missing-exports.patch
linux-2.6-radeon-backlight.patch
linux-2.6-ide-tune-locking.patch
linux-2.6-autofs-pathlookup.patch
linux-2.6-8139too-suspend.patch
linux-2.6-selinux-hush.patch
linux-2.6-agp-sworks-hang.patch
linux-2.6-smsc-ircc2-pnp.patch
linux-2.6-ide-scsi-check_condition.patch
linux-2.6-usbhid-wireless-security-lock.patch
linux-2.6-net-sk98lin-vpd.patch
linux-2.6-w1-hush-debug.patch
linux-2.6-pwc-powerup-by-default.patch
linux-2.6-kauditd-suspend.patch
linux-2.6-firmware-timeout.patch
linux-2.6-suspend-mxcsr.patch
linux-2.6-i8k-dmi.patch
linux-2.6-acpi-silence-cutoff.patch
linux-2.6-acpi-thinkpad-c2c3.patch
linux-2.6-obsolete-idescsi-warning.patch
linux-2.6-obsolete-oss-warning.patch
linux-2.6-unexport-symbols.patch
linux-2.6-vm-oomkiller-debugging.patch
linux-2.6-vm-silence-atomic-alloc-failures.patch

Con Kolivas Patches.

2.6.14_to_staircase12.1.diff
schedrange.diff
schedbatch2.9.diff
sched-iso3.2.patch
smp-nice-support7.diff
1g_lowmem1_i386.diff
isobatch_ionice2.diff
rt_ionice.diff
pdflush-tweaks.patch
hz-default_values.patch
hz-no_default_250.patch
mm-swap_prefetch-18.patch
vm-mapped.diff
vm-lots_watermark.diff
vm-background_scan-1.diff
sched-staircase12.1_12.2.patch
mm-kswapd_inherit_prio.patch
mm-prio_dependant_scan.patch
mm-batch_prio.patch
sched-staircase12.2_13.patch

Nitro Patches.

linux-2.6-e100-badeeprom.patch
linux-2.6-shfs-0.35-rc4.diff
usbhid-readd-kconfig.patch
shutup-unneeded-warnings.patch
acpi_dsdt_initrd_initramfs.patch
git-alsa.patch
git-libata-all-1.patch
git-scsi-misc.patch
git-ntfs.patch
hz-extra_values.patch
parport-mutex.patch
ide-probe-delay.patch
increase-MAX_MP_BUSSES.patch
kmalloc-max.patch
posix-locks-match.patch
readahead-tune.patch
stack-limit.patch
unmap_vmas-lat.patch
reiser4-for-2.6.14-1.patch

Even though the tree to build these kernels is patched with the reiser4 patch, it is not configured by default!. In order to have reiser4 support you'd have to have installed in your system the resier4progs package and would have to install the SRPM of the kernel, edit the config file, enable reiser4 support, and rebuild with that tree. I added it just because some people are using reiser4 in Fedora systems. This feature is considered to be EXTREMELY EXPERIMENTAL and should NOT be enabled unless you REALLY KOW WHAT YOU ARE DOING!™

Note: The default configuration for these kernels is based off the configuration for the official Fedora kernels, with a few tweaks here and there to favor peroformance and still retain full stability (or at least that's the goal)

Now, anyone interested in testdriving these babies? :D

[storlied]

i have absolutly no clue what this post is about... but it sound intresting...... explain
do you have a patched custom kernel that gives great performance??? idk

[Thetargos]

i have absolutly no clue what this post is about... but it sound intresting...... explain
do you have a patched custom kernel that gives great performance??? idk
Yes...

When you've been in the Linux community for a while, you start to see people wanting to get the most out of their systems, or the latest patch to support x, y, z device, or improved a, b, c... Well my idea behind this all was based on that. Since i was running Red Hat 9 Shrike, I've been running custom kernels with some added patches to get an edge on performance. So I thought that there should be someone offering these kind of kernels in an RPM format easily deployable and installable by people. At the time I could build my own kernels and configure them to my heart's content, but I did not know how to build an RPM off the sources, nor how did RPM actually worked... I only had heard a few things about these governing files called spec files which control the behavior of RPM when building packages. So I dug into it and started to think of a way to share these.

Why did I start using custom kernels in the first place? Well, back in the 2.4.x era of kernels, it was a voiced secret that Red Hat kernels were a tad slower than a reference "vanilla" kernel, and that wasn't true as such, since it deeply depends on how the kernel is configured and what is the task the computer will be performing and stuff like that... And it actually made sense that Red Hat had these types of kernels, since it was to be run on a variety of environments and systems, and the computer should stay stable. And this was perfect for servers and OK for desktops. However as you added more interactive applications and games to the mix, the kernel became a bottle neck.

Under normal circumstances, there should little to no reasons to want to run a custom-made kernel. Still this has a disadvatage: You would have to configure it and build it yourself, having a binary RPM kernel around makes things a lot easier, since you can easily install the kernel you need on a broad range of systems, not matter if they're all alike (meaning you can strim even more the kernel to only have compiled in what you really need) or a broad variety of systems, which means you configure it more like a general purpose one able to interface with a lot of systems, in both cases you win, because you'd only have to build the kernel once and install as many times as you need.

So the reason behind this whole effort to offer these kind of kernels is to have a better performing kernel, but truly Fedorian in its roots, I did not want to skip any of the patches from Fedora (only a couple are not listed due duplication with some of the other patches), so these are actually revamped fedora kernels with improvements to make them a bit more extensible and faster.

When I made the migration from Windows to Linux, I was an avid gamer, and I still am, and for applications such as games (especially those as demanding as today's), the kernel can make all the difference between "somewhat playable" and "fully playable". Of course there are lots of variables that affect performance, even at kernel level, so I'm trying to stick to what the Fedora guys have done by providing widely compatible configurations with the tweaks where they count. These are mainly desktop kernels, which mean they're not as robust as a kernel that would be more suited for a server which could also make a fairly good desktop kernel. These are desktop kernels, that could be fairly decent server kernels, but not viceversa.

What I'm asking is to see if there's people interested in such kernels, and if there are, I'd be more than happy to share what I've made to the kernel in order to make it a bit more useable for gamers and generally people who need low latency systems (like musicians, and other scientific applications) and give them a try.

[storlied]

How can I add "patches" to my FC3 x86_64 machine? where can i find such patches?.. do i have to recompile the kernel?... i hope not......i mean...patches... should be something i can just apply....... i do want to get the most outta my system... performance wise... iv been lookin for tweaks n all sorts of things for a long time..... uhm...people say recompiling the kernel, gives a minimal performance increase.... n freankly... i dont wanna bother with it.... they said its a waste of 4 hours.... but uhm.... do you know how to shorten application startup time?....latency.... like i said... i dont really wanna recompile a kernel... seems like too much work... what can i do to get more performance without doin that?

[storlied]

n btw... yes.. if you have a complete "performance" kernel... i'd be glad to use it... i just dont wanna make one myself.... iv been searchin for a Long time for something like this.... a kernel made by others thats for performance..

[Thetargos]

How can I add "patches" to my FC3 x86_64 machine? where can i find such patches?.. do i have to recompile the kernel?... i hope not......i mean...patches... should be something i can just apply....... i do want to get the most outta my system... performance wise... iv been lookin for tweaks n all sorts of things for a long time..... uhm...people say recompiling the kernel, gives a minimal performance increase.... n freankly... i dont wanna bother with it.... they said its a waste of 4 hours.... but uhm.... do you know how to shorten application startup time?....latency.... like i said... i dont really wanna recompile a kernel... seems like too much work... what can i do to get more performance without doin that?
Well, those patches you find them by searching the web, Google's your friend ;)

Actually the Gentoo community forum is a good place to start ;)

And onto your questions:


Kernel recompilation is not recommended for every user, just for some, like when a certain critical device is not being picked up by your current kernel and such.
Speed wise, kernel recompilation can give you 0 performance gain, and 4 hours of your time lost, true. However, careful tuning of your kernel is critical if you go down this path, and that's where patches kick in. Kernel patches are different from "traditional" patches, in the sense that they're code patches, this is, they're actually text files with fixes to the underlying source code (in Linux and Unix you'll hear a lot about patches, and most the time people refer to these text patches). Once you apply these patches, some new features will be available to you to play with, and enable/disable some others.
For some people the whole point of (re)compiling their own kernels is to have a minimalistic kernel (as small as possible) tailored for thier machine and their machine alone, i.e all other hardware support is stripped out of the kernel, some claim this gives you an edge in performance and memory foot print (a small one, at that), but it's nice to have a kernel well tailored to your system, however if something goes wrong and you have to change, say, your motherboard, you should always have to keep a "fall back" kernel to have functioning system, otherwise your over specialized kernel will not be able to pickup and use your new motherboard.
Kernel-level tweaking can help you improve performance where most computers idle and waste resources at: I/O operations handling.
For shorter application startup, there are other tweaks (system tweaks) like PreLink, which accelerates application startup by trying to pre-load libraries, reducing application startup, however this also has to do with the previous point, I/O as information has to be read from the disk.
Latency is another issue which can be adressed at kernel level, by means of what's called the "tick" rate, or processor time given to applications while executing (fora lack of a better explanation), by augmenting this time, your application will have more processor time, reducing the latency for such application (however this can have unforseen consequences on other applications, like system services).


I don't have Fedora Core 3 Heidelberg installed anymore (though I've got access to plenty of machines with it, but none with x86_64 processors), so I can't offer FC3 x86_64 packages, I may be able to get at most i686 and athlon optimized kernel for FC3, the rest are for FC4 only, I'm affraid, as that's what I've got. And yes, the idea is to save you all the hassle of configuring and building up your own low-lat-dekstop kernel by providing pre-compiled, binary RPMS.

[storlied]

damn... tis what i was lookin for.... someone who made a performance kernel for x86-64.... i was about to ask if i gave you my specs n what i wanted in the kernel, if you could make me one......

[storlied]

is there something like prelink for FC3? that would work with x86_64

[Thetargos]

PreLink already comes in FC3. There are other system tweaks you could perform to get the most out of your system... I'm in the process too of writting a "performance guide" for Fedora, not really a howto, rather tips on what to look to increment your performance without having to under go heavy tasks (as kernel recompile or application re-compile), but I'm not done yet.

About building you a kernel, that's what I'm doing, only for FC4, since I don't have access to an FC3 machine, what I could do is to lend you the .src.rpm and tell you how to rebuild it for x86_64, only in my configuration I make a distintion between generic x86_64, amd64 and em64t (or pretend to do so, as the default fedora kernel is built for a generic x86_64 architecture).

Edit
Problem is that the .src.rpm is almost 40Mb in size (ouch!)

[storlied]

hmm... do you think i could see what you got so far on that guide? or your notes or something..

[storlied]

since it's for FC4, would it work on mine?

[storlied]

oh jesus christ, 40mb......im on 56k....that will be an all nighter download... lol

[Thetargos]

hmm... do you think i could see what you got so far on that guide? or your notes or something..
Problem with this is that most of it is on my head, but you can take a look at plenty of useful hints and tips over at www.fedorafaq.org, as I get around put on written words all that I've learnt, performance wise, in Fedora.

[storlied]

dude, get on msn... i added you..

[Thetargos]

oh jesus christ, 40mb......im on 56k....that will be an all nighter download... lol
I know is quite a bit, drop me a line at thetargos at tutopia dot com and I'll give you a link to my FTP server from where you'll be able to download the file.

[Thetargos]

Well, i'm in the process of finding hosting for these packages, most likely will open a SourceForge account. As of right now I've got AMD64-(SMP) and generic x86_64(-SMP) packages built with .athlon and .i686 soon to follow (just as the laptop finishes building them).

[Thetargos]

I've got some i386 test builds. Kernels for i686(-smp) and athlon(-smp). If you'd like to try them and give some feedback, just drop me a line.

I hope the SourceForge.net people will review my petition for this project soon, so I have where to host the files.

[Thetargos]

The SFN project is up, and I'm in the process of uplaoding the necessary files, if you've got any ideas or want to contribute in any way, just let me know! I'll post here when all the packages have been uploaded.

[UnknownEntity]

Please do :-)

I really want to try a patched up kernel based off the latest version. I get some nasty IRQ errors at boot, and I think it's preventing me from using my nvidia drivers :-(.

I have an x86_64 system.

[Thetargos]

Sorry for the inactivity in th last couple days, I had to take a weekend off... Anyway, I'll be uploading the files, as soon as I correct a problem in the .spec file that prevents version 1 of the CFKP series to even complete the -bp when rpmbuild is called (apparently a permissons problem, or ran out of disk space... ) for i386 systems (i686 and athlon).

Anyway, the x86_64 and amd64 files will be up by tonight, followed by a small read me here.

[Thetargos]

Files for AMD64 and generic x86_64 architectures are now available from the Custom Fedora Kernel Project (http://sourceforge.net/projects/cfkp) source forge downloads section. Pleae report back any problems you may encounter with these files. Thaks.

As a sort of ReadMe:

Please read all this before you install these packages!

These kenrel files were created due to the lack of availability of binary releases of kernel packages, plus a patch that incorporated all the patches the Fedora crew applies to the official kernel, plus some other patches aimed toward improved system performance.

The binary kenrels are based off the original configuration files from the official Fedora kernels, with some changes to enable those features (or change a couple values, where applicable) to improve system performance. What this means is that these kernels aim to support a wide range of hardware devices while having spped enhacements.

Note: System performance is due to a number of factors, from which one of those is the time the kernel spends doing some tasks. By installing a kernel which would help to lower the time it spends when peforming certains tasks, it would be possible to increase overall system performance, however, other aspects have to be taken into account for this: such as how many services the system has running in the background at any one time; which of the system services currently loaded are not really needed and are only wasting clock cycles, I/O, etc? System tweaking should cover way more areas than only the kernel, and as such these packages are not recommended for the casual user. It is quite possible that person would not notice any increase in the performance of their computers, these packages are aimed toward desktop use and should (theoretically) make the system more responsive, however a number of factors may interfere with this in the desktop experience such as amount of RAM, HDD speed and memory throughput, amongs others. To check if everything is working as it should, check your log files often and run a number system tests trying to compare the official kernel and this one. never erease the latest official kernel, so you have a fallback should anything go wrong!

Besides the offiicial Fedora kernel patches, these packages have the Con Kolivas and Nitro patches applied (which include the 2.6.14.2 patch). Even though the Reiser4 patch has been applied, none of the binaries have the filesystem configured, if you would like to enable it, you will have to either do it from the .src.rpm package (you'll still need to modify the config, and make sure it works through the rpmbulid process) or apply the source patch to an unpatched 2.6.14 kernel source tree, and install the reiserprogs package version 4 to make use of this filesystem (reason why it is not configured in the binaries). A word of advice, if you'd like to try Reiser4, you should build it agains the main kernel image, and not as a module.

Installation.

These packages do not substitute the official Fedora Core kernels, and as such, you will have to --force their installation. This is not a bug, but a feature™, becuase unless you really want to run these kernels, you should stick to the official Fedora ones! You have been warned.

To install the rpms simply:

rpm -ivh --force kernel-<version>-CFKP_<release>_FC#.<arch>.rpm

Where:
<version> is the main kernel version, <release> the release version for that kernel version and <arch> the architecture. Substitute accordingly.

If you will require (most likely you will) to build additional drivers for the kernel, for instance, graphics drivers, you will also need the -devel version of the package. This may also require to be --force'd

Features:

The binary packages already come with support for NTFS partitions, using the mainline kernel driver, i.e no write support. Other features include:

Processor specific builds (i686, athlon, amd64 and generic x86_64)
Preemption for low latency desktop, instead of kernel voluntary preemption.
System Hz set at 1000.
Some less noisy debug options.
Additional hardware support:

SCSI

iSCSI support.
Pacific Digital ADMA SATA adapter support.
Promise PATA 2027x support
Silicon Image SIL3124/3132 support
Silicon Image / CMD 680 PATA support

Graphics support: Custom logo.
Sound: git's ALSA tree.
USB mouse polling for improved mouse-input precision



Though these packages are intended to be stable, they have not been tested on other systems other than my own, as such, you have to be extreme careful if you want to use them! If you'd rather use the stand alone patch (which includes all Fedora's patches, plus the rest and some example configs), I assume you already know how to:

Get a vanilla kernel source tree.
Apply patches against a source tree, specifically a kernel source tree.
Configure and build your own kernel.


A note to OverClockers: Only once has a similar kernel been tested on an overclocked system, and it had trouble, so if you want to use these packages/patches in an overclocked system, make sure you disable your OC when you boot these kernels for the first time, and then re-do your OverClock as if it was a NEW systen, i. e. with small increments at any given time!

[UnknownEntity]

I am testing it on my X86_64 Intel box as I type this. How do I use the devel package to install my nvidia drivers? It's no where near the size of a normal source code package. The nvidia setup program says it doesn't detect the sourcecode package for the installed kernel.

Thanks

[Thetargos]

I am testing it on my X86_64 Intel box as I type this. How do I use the devel package to install my nvidia drivers? It's no where near the size of a normal source code package. The nvidia setup program says it doesn't detect the sourcecode package for the installed kernel.

Thanks
Maybe I should make that part clear. You only need the binary kernel. The kernel-devel will allow you to build additional drivers for the kernel, provided the kernel-devel and kernel packages match in versioning, arch, etc. So if you're running kernel-2.6.14-CFKP_1_FC4.x86_64.rpm, in order to install your nvidia or ATi drivers (or to build any other module, provided you have the code for that module, like modem's) you would need the kernel-devel-2.6.14-CFKP_1_FC4.x86_64.rpm package, in order to do that. The .src.rpm is only provided so people can build their own RPMs.

[UnknownEntity]

Yes, it was my mistake. I clicked on the wrong rpm for the devel package. I had the smp devel and the standard kernel. lol

It was late. :-(

It's working good though. I haven't had any issues with it since I installed it.

[Thetargos]

Good to hear.

For some reason I still have a bit of trouble getting the i386 builds to actually BUILD... I'm gonna test in a whole other system, since it seems it may be local to the particular computer I'm trying to build on.

[Thetargos]

Finally!! I've been able to correct a problem in the spec file which was preventing me from building i386 packages. You can now find i386 (athlon and i686) packages in the project's download area. Don't forget to give your feedback!!

I'm working on pre-alpha, extremely experimental 2.6.15-rc2 packages right now, with Fedora patches plus CK and some of the Nitro ones. A full change log will be posted soon, stay tuned.

[scottmuz]

Big thanks!!! Thetargos for all your work on this.

Just installed the athlon 2.6.14 kernel and it is noticably snappier than the vanilla FC 2.6.14 kernel.

The icing on the cake would be if you could set this up to operate via a yum repo so we could pick up updates through the normal yum update process.

[Thetargos]

Big thanks!!! Thetargos for all your work on this.

Just installed the athlon 2.6.14 kernel and it is noticably snappier than the vanilla FC 2.6.14 kernel.

The icing on the cake would be if you could set this up to operate via a yum repo so we could pick up updates through the normal yum update process.
Thanks for your kind words.

I know it'd be very comfortable for people to have this yum-able. However at this point it is not intended to be that way for a number of reasons:


Fedora developers have put a lot of effort and thougt on what would be a general-purpose-suited-for-many-systems kernel. As such they picked (and wrote) a number of patches for it.
These kernels are targeted to people who would like a better performer kernel, although it could potentially be less stable/compatible than the standard Fedora kernel. That's why I, amongst other reasons, made the Official kernel take precedence and require that installation needs --force flags to be successful. Kind of a reminder that this is in no way supported, nor endorsed by the Fedora Project.
While true, YUM would make installation much easier and even faster, I'd better wait for people to give feed back on how do they like the kernel.


I'll keep working on this project, as I'm a [happy] Fedora user, and I hope what this project is about would be found to be helpful for other people too.

[Thetargos]

The next revision of the packages will feature the CK6 patchset. Not much has changed from the previous, but Con added some rather interesting back ports from the .15-rc2-CK1 patch, and they're worth it (at least on my systems). Expect them to appear on-line, some time tomorrow, as they're being built tonight. As always, a stand alone patch will be available.

Amongst other changes is the addition of 2.6.14.3 too.

[Ceb]

Hi Thetargos!
I compiled my custom kernel.
I don't want to keep all the compiled things, so i would like to build a devel package.
Could you plz help me? How to start? What files do i need to get a working devel package?
Thx for your help.

Ceb

[Thetargos]

I don't know if I understand you correctly. You only want to build the kernel-devel target without building the other packages (kernel-<version>.rpm and debuginfo)?

[Ceb]

I try to be more exact this time.
I compiled the kernel (make rpm) and installed it, works fine :) .I have linked the entire source where it belongs.
No problem there,but i know i could get rid most of the source and keep the headers and some other files.
I just don't know which directories/files to keep from source. This would be first step and from the remains i could possibly build the kernel-<version>-devel.rpm. I hope, so i can manage it with rpm.

[Thetargos]

Ah, ok... In order to know what exactly keep, I'd suggest you to check what does -devel install, that'll tell you what to keep and what to waste.

rpm -ql kernel-<your_version>-devel

[Ceb]

Thx for your fast reply and kind help.
I'll try and build that package, but now it's time for bed. 1:40 AM here :D

[Thetargos]

Time to announce the latest packages and the new website for the project:

http://cfkp.sf.net

Release notes:

First Beta release of a 2.6.15 kernel for the Fedora Core 4
distribution. This release is based on the patches from the Fedora Core
5 2.6.15 kernel, Con Kolivas patchset 2 for the 2.6.15 kernel and a
series of patches part of the nitro3 patchset

This release should be considered experimental and you should avoid use
of these packages on a production system or at your own risk. If your
computer is nuked, your toaster fails to work or it suddenly has foam
coming from its slots, or if your harddrive suddenly decides to boot
into Windows, we can't be held responisble... You have been warned.

The CFKP kernels are specially tweaked kernels based on Fedora official
kernels for improved performance and features. They DO NOT aim to be a
complete substitute of the original Fedora kernels, as the Fedora
kernels are the product of careful planning and patching to get the best
possible kernel for the users at any given time. For this reason they
may not be great performers (though they do farily), but they are
stable kernels.

Amongst the features offered by these packages are:

* Lowlatency desktop voluntary kernel preemption.
* 1000 Hz internal ticker.
* Use of the Anticipatory I/O scheduler.
* Built for specific architectures.
* Latest libata.
* Latest ACPI support.

Supported architectures are: i386 in the forms of i686 PentiumIV
optimized and K7 Athlon and x86_64 in a configuration for EM64T
optimization and AMD64 specific, all available in SMP configurations
too. These kernels are not available for PPC architectures (I don't have a
PPC based computer, sorry).

Comments and suggestions regarding these packages, please contact me at:

thetargos [at] gmail [dot] com