On 09 Jul 2014, at 18:02, David Laight <David.Laight@xxxxxxxxxx> wrote: > From: Neil Horman > ... >>> The problem here is deprecation of ancillary data and that's is a lot tougher >>> then socket options. In this particular case (SCTP_SNDRCVINFO vs SCTP_RCVINFO), >>> I don't think there is any way to deprecate the SCTP_SNDRCVINFO since the event >>> enabling it is the same as the one for SCTP_RCVINFO. This was a mistake in the I don't think this is true: To request SCTP_SNDRCVINFO you use the SCTP_EVENTS option. See http://tools.ietf.org/html/rfc6458#section-6.2.1 To request the SCTP_RCVINFO you use the SCTP_RECVRCVINFO option. See http://tools.ietf.org/html/rfc6458#section-8.1.29 So the user does different things and the kernel can provide the requested information. Best regards Michael >>> spec. Ancillary data should not have been enabled using even notification api, >>> as it is not an event, but we now have to live with it. >>> >> Ugh I didn't even consider cmsg type overlap. Thats probably it then, we can't >> deprecate it. Though that does call the question up as to how to differentiate >> expectations of the data format for each cmsg, if they use the same type. Does >> the SCTP_RCVINFO data struct overlay the SNDRCVINFO struct exactly? (sorry I've >> not checked myself yet). > > Not from what I remember from when I read that RFC. > I think the lengths are different enough to determine which is which. > > That RFC (I've forgotten the number) looks like an entire bag of poo > that should be ignored... > > David > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
