[lkml]   [1999]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Q]: Linux and real device drivers
    > Kernel sk_buff layout change during 2.0 to fix the big ping attack 8-P

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.021 / U:40.448 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site