Messages in this thread | | | Subject | Re: [Q]: Linux and real device drivers | From | Jes Sorensen <> | Date | 25 Sep 1999 11:44:39 +0200 |
| |
>>>>> "David" == David Hinds <dhinds@zen.stanford.edu> writes:
David> 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.
David> Sure, but the version checking on modules requires this anyway, David> and doesn't distinguish between public and private interfaces. David> Because all driver references to sk_buff structures are through David> helper functions, we also have the option of arranging things David> so that even layout changes would not require driver David> recompiles. I think that's a good model to follow in designing David> robust API's.
Not entirely true, someone, for whatever reason, may do something silly like:
struct foo{ struct sk_buff a; struct sk_buff b; }
In their code, and boom.
David> Things like:
current-> state = TASK_INTERRUPTIBLE;
David> are fragile because they expose implementation details, while David> things like:
David> if (signal_pending(current)) ...
As long as we are dealing with inline macros, it won't save you anything in the binary compatibility area at least.
>> This was done deliberately and you know it, it was put in the >> middle to make sure people noticed it.
David> Well, no, I don't remember the history of it, and the David> consequence of my noticing it was just to add a NULL pointer to David> the initializers for a bunch of drivers (with a macro so I David> could still build for 2.0.*). Maybe the intent was for people David> to notice and take some other action, but in that case, it David> seems to have not achieved that purpose. I'm no expert on this David> side of the kernel and couldn't even tell you what this entry David> point is supposed to be for. It appears to be set to NULL for David> every device driver in the kernel tree.
I don't know exactly what it is for, however I do remember Linus changing this and you reacting to it, whereafter Linus explained that it was done exactly to make people notice. I can go dig it out of the archives if you wish.
David> The concept of deliberately implementing an API change so that David> it will break code, just so that people will notice it, with no David> other reason for the breakage, seems somewhat twisted to me.
Well we can only disagree on that, it's one of the things that does that Linux gets cleaned up, while commercial vendors keep dragging piles of backwards compatibility cruft around. However it is also a good point that shows why code should be in the public tree.
Jes
- 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/
| |