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/