RE: [PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length

[David Laight <David.Laight@ACULAB.COM>]

From: 'Marcelo Ricardo Leitner'
> Sent: 07 February 2019 17:47
...
> > > Maybe what we want(ed) here then is explicit versioning, to have the 3
> > > definitions available. Then the application is able to use, say struct
> > > sctp_event_subscribe, and be happy with it, while there is struct
> > > sctp_event_subscribe_v2 and struct sctp_event_subscribe_v3 there too.
> > >
> > > But it's too late for that now because that would break applications
> > > already using the new fields in sctp_event_subscribe.
> >
> > It is probably better to break the recompilation of the few programs
> > that use the new fields (and have them not work on old kernels)
> > than to stop recompilations of old programs stop working on old
> > kernels or have requested new options silently ignored.
> 
> I got confused here, not sure what you mean. Seems there is one "stop"
> word too many.

More confusing than I intended...

With the current kernel and headers a 'new program' (one that
needs the new options) will fail to run on an old kernel - which is good.
However a recompilation of an 'old program' (that doesn't use
the new options) will also fail to run on an old kernel - which is bad.

Changing the kernel to ignore extra events flags breaks the 'new'
program.

Versioning the structure now (even though it should have been done
earlier) won't change the behaviour of existing binaries.

However a recompilation of an 'old' program would use the 'old'
structure and work on old kernels.
Attempts to recompile a 'new' program will fail - until the structure
name (or some #define to enable the extra fields) is changed.

Breaking compilations is much better than unexpected run-time
behaviour.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)