From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.7) Gecko/20010316
Description of problem:
The addition of timer_ticks to the middle of task_struct forces
providers of binary loadable modules to re-evaluate each of your kernels and
re-spin their modules each time you put out a kernel. Was this your intention?
You could at least have added it to the end of the structure!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Look at sources
Actual Results: Our dcedfs.o module built for 2.4.9-12 no longer works on a
kernel that was supposed to be a security update of your kernel.
Expected Results: Kernel structures and interfaces for 2.4.9 should be
This field was added to enable a modification to the scheduler which increases
performance under threaded applications by 20% or more.
> You could at least have added it to the end of the structure!
The task struct is ordered very carefully for the "hot path" accessed fields to
be in the first cacheline. Adding this field to the end of the structure would
have added an extra cacheline access to the hotpath -> not acceptible.
> Actual Results: Our dcedfs.o module built for 2.4.9-12 no longer works on a
> kernel that was supposed to be a security update of your kernel.
I sincerely hope that you as binary only kernel module provider do not ask your
customers to use modules compiled for different kernel versions.
> Expected Results: Kernel structures and interfaces for 2.4.9 should be
> backwards compatible.
The INTERNAL kernel ABI is NOT a guaranteed interface, and there is no way for
Red Hat to even verify that it has not changed. This happens to be what Open
Source is about as well: you have the source so for internal changes it's
trivial to recompile.
People who think they found a loophole in the GPL license of the kernel and ship
binary only modules have one pain: every new kernel needs a recompile. Comes
with the teratory...