lkml.org 
[lkml]   [1999]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Binary drivers
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.049 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site