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

From: 'Marcelo Ricardo Leitner'

Sent: 07 February 2019 17:47

...

quoted

quoted

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)