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): How reproducible: Always Steps to Reproduce: 1.Look at sources 2. 3. 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 backwards compatible. Additional info:
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...