That's a good example, which reinforces one of my points. An sk_buff
is essentially an opaque data structure for device drivers: whatever
the changes were, I was oblivious to them, because they had no impact
on network driver code.
Maybe the changes impacted some other network stack components that
could be modularized, but I consider the sk_buff stuff to be one of
the better-thought-out parts of the driver API because changes like
this are generally invisible to other parts of the kernel.
Looking at the kernel compatibility #defines I use for PCMCIA for
handling 2.0.* to 2.3.* kernels, I don't see any that seem obviously
related to bug fixes. Some are related to new functionality (dentry
code). A lot are just syntax changes. I handle almost all by just
implementing the new syntax for the old kernels, so that the actual
source code looks current.
Some gratuitously annoying changes:
o changing parameters of dev_kfree_skb() and poll_wait() without
changing the name. Can't easily be hidden in a macro.
o Addition of 'flush' pointer to middle of 'struct file_operations'
rather than the end, needlessly breaking static initializers.
o Redefinition of invalidate_inodes() to take a 'struct super_block'
instead of a device number, without changing the name, when 90% of
the callers actually want the old form. So it bloats the kernel
*and* can't be hidden in a macro.
Most API changes have minimal impact on driver writers, if they can be
easily hidden away in a header file. I'm indifferent to these. Some
changes can't be hidden (things like the changes to the file operation
calls after the dentry stuff was added), and these don't bother me
either, if they are necessary for implementing useful functionality.
Things that bother me are changes that needlessly require source code
changes when, with almost no effort, they could have been done in ways
that did not impact existing code.
-- Dave Hinds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/