[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1726F39D@AcuExch.aculab.com>
Date: Wed, 9 Jul 2014 16:02:01 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Neil Horman' <nhorman@...driver.com>,
Vlad Yasevich <vyasevich@...il.com>
CC: Daniel Borkmann <dborkman@...hat.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"geirola@...il.com" <geirola@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: RE: [PATCH net-next 0/5] SCTP updates
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists