[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71e3d64ae3d44e499f3fb9f876398ee4@AcuMS.aculab.com>
Date: Wed, 13 Feb 2019 16:17:41 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Marcelo Ricardo Leitner' <marcelo.leitner@...il.com>,
David Miller <davem@...emloft.net>
CC: "julien@...sta.com" <julien@...sta.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"nhorman@...driver.com" <nhorman@...driver.com>,
"vyasevich@...il.com" <vyasevich@...il.com>,
"lucien.xin@...il.com" <lucien.xin@...il.com>
Subject: RE: [PATCH net] sctp: make sctp_setsockopt_events() less strict about
the option length
From: Marcelo Ricardo Leitner
> Sent: 10 February 2019 20:16
...
> We have issues on read path too. 52ccb8e90c0a ("[SCTP]: Update
> SCTP_PEER_ADDR_PARAMS socket option to the latest api draft.")
> extended struct sctp_paddrparams and its getsockopt goes with:
The API shouldn't change like this at all.
Is this from the RFC or elsewhere??
If the structure changes the socket option name and value
should also change.
IMHO large chunks of the sctp rfc are just horrid.
In particular all the places where is states that API functions are
implemented using setsockopt() - that should be an implementation detail.
Also ISTR that some of the structures are defined to have holes in them...
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists