Messages in this thread | | | Subject | Re: Binary drivers | From | Andi Kleen <> | Date | 09 Dec 1999 19:38:23 +0100 |
| |
Bret Indrelee <bindrele@sbs.com> writes:
> > > > My point was that a recompile is fine. Breaking the *source* > > interface is > > problematic. (For those who fear that source compatibility > > can lead to > > binary compatibility and dislike the latter: you can make > > source-compatible > > changes that break binary conpatibility, the most obvious > > being rearranging > > structure elements.) > > Which breaks source compatibility as well. If you have something like: > > struct vmoperations_struct btp_vm_ops = { > bt_vmopen, bt_vmclose, NULL, NULL, NULL, NULL, bt_vmnopage, NULL, NULL, > NULL };
gcc has an handy extension to handle that.
struct foobar_op my_ops { open: my_open, close: my_close, nopage: my_nopage };
The rest is simply filled with NULL. If you look closely it is already used successfully in lots of kernel modules.
C99 has a similar extension, unfortunately incompatible ( .field = instead of field: ). I guess adopting the gcc syntax that was in the field for years would have been too easy.
Sometimes we want to break the source though. When the semantics of the interface change then a human should look at it. A lot of people didn't get this e.g. from 2.0 -> 2.2, mindlessly doing a global search-replace from memcpy_fromfs to copy_from_user, although this was not correct because it needed to be fixed to check for the return value too.
-Andi
- 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/
| |