Re: fun (not so much) with funopen

[David Young <dyoung%pobox.com@localhost>]

On Fri, Mar 16, 2012 at 09:42:35AM -0700, Bruce Korb wrote:
> On 03/16/12 09:07, Christos Zoulas wrote:
> >Hello,
> >
> >As some of you might have noted, recently we changed the API/ABI of 
> >funopen(3)
> >from:
> >
> >     FILE    *funopen(const void *cookie,
> >         int (*readf)(void *cookie, char *buf, int len),
> >         int (*writef)(void *cookie, const char *buf, int len),
> >         fpos_t (*seekf)(void *cookie, fpos_t offs, int whence),
> >
> >to:
> >
> >     FILE    *funopen(const void *cookie,
> >         int (*readf)(void *cookie, char *buf, int len),
> >         int (*writef)(void *cookie, const char *buf, int len),
> >         off_t (*seekf)(void *cookie, off_t offs, int whence),
> >         int (*closef)(void *cookie));
> >         int (*closef)(void *cookie));
> >
> >This change broke both binary and source compatibility with the previous
> 
> Bad idea.  funopen() needs to be a wrapper around something with the
> new functionality.  And, as long as you are doing that, it
> makes *MUCH* more sense to go with an interface that takes
> a ops structure:
> 
> struct user_io_ops {
>    int (*readf)(void *, char *, int);
>    ...
> };
> 
> extern FILE * uio_fopen(void * cookie, struct user_io_ops*);
*snip snip*
> If you're going to break something, then go whole hog and fix it so
> you won't have to break the API ever again. :)

You can avoid breaking the ABI compatibility of uio_fopen(), too, by
using presence bits to tell which function pointers are (not) available
like I have in bus_space_tag_create(9).

(I'm grateful to Matt Thomas for pointing out that an ops structure
alone wouldn't provide ABI compatibility.)

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981