[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1AA30289-FE48-4E1E-90CF-8E567D8A1031@lurchi.franken.de>
Date: Wed, 9 Jul 2014 18:12:44 +0200
From: Michael Tuexen <Michael.Tuexen@...chi.franken.de>
To: David Laight <David.Laight@...LAB.COM>
Cc: Neil Horman <nhorman@...driver.com>,
Vlad Yasevich <vyasevich@...il.com>,
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
On 09 Jul 2014, at 18:02, David Laight <David.Laight@...LAB.COM> 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@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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