Messages in this thread | | | Date | Fri, 24 Sep 1999 14:00:06 -0700 | From | David Hinds <> | Subject | Re: [Q]: Linux and real device drivers |
| |
On Fri, Sep 24, 1999 at 09:25:35PM +0200, Jes Sorensen wrote:
> David> That's a good example, which reinforces one of my points. An > David> sk_buff is essentially an opaque data structure for device > David> drivers: whatever the changes were, I was oblivious to them, > David> because they had no impact on network driver code. > > Except that it changes the layout of struct skbuff, which the drivers > need to be recompiled for to make sure they don't break things.
Sure, but the version checking on modules requires this anyway, and doesn't distinguish between public and private interfaces. Because all driver references to sk_buff structures are through helper functions, we also have the option of arranging things so that even layout changes would not require driver recompiles. I think that's a good model to follow in designing robust API's.
Things like:
current->state = TASK_INTERRUPTIBLE;
are fragile because they expose implementation details, while things like:
if (signal_pending(current)) ...
are more robust to changes in underlying implementation. As the kernel has evolved, lots of things that used to be done the first way are now done the second way. I approve.
> David> o Addition of 'flush' pointer to middle of 'struct > David> file_operations' rather than the end, needlessly breaking > David> static initializers. > > This was done deliberately and you know it, it was put in the middle > to make sure people noticed it.
Well, no, I don't remember the history of it, and the consequence of my noticing it was just to add a NULL pointer to the initializers for a bunch of drivers (with a macro so I could still build for 2.0.*). Maybe the intent was for people to notice and take some other action, but in that case, it seems to have not achieved that purpose. I'm no expert on this side of the kernel and couldn't even tell you what this entry point is supposed to be for. It appears to be set to NULL for every device driver in the kernel tree.
The concept of deliberately implementing an API change so that it will break code, just so that people will notice it, with no other reason for the breakage, seems somewhat twisted to me.
-- 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/
| |