> 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/