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 > > 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
