From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de> To: David Laight <David.Laight@ACULAB.COM> Cc: Neil Horman <nhorman@tuxdriver.com>, Vlad Yasevich <vyasevich@gmail.com>, Daniel Borkmann <dborkman@redhat.com>, "davem@davemloft.net" <davem@davemloft.net>, "geirola@gmail.com" <geirola@gmail.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org> Subject: Re: [PATCH net-next 0/5] SCTP updates Date: Wed, 9 Jul 2014 18:12:44 +0200 [thread overview] Message-ID: <1AA30289-FE48-4E1E-90CF-8E567D8A1031@lurchi.franken.de> (raw) In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1726F39D@AcuExch.aculab.com> On 09 Jul 2014, at 18:02, David Laight <David.Laight@ACULAB.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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
WARNING: multiple messages have this Message-ID (diff)
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de> To: David Laight <David.Laight@ACULAB.COM> Cc: Neil Horman <nhorman@tuxdriver.com>, Vlad Yasevich <vyasevich@gmail.com>, Daniel Borkmann <dborkman@redhat.com>, "davem@davemloft.net" <davem@davemloft.net>, "geirola@gmail.com" <geirola@gmail.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org> Subject: Re: [PATCH net-next 0/5] SCTP updates Date: Wed, 09 Jul 2014 16:12:44 +0000 [thread overview] Message-ID: <1AA30289-FE48-4E1E-90CF-8E567D8A1031@lurchi.franken.de> (raw) In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1726F39D@AcuExch.aculab.com> On 09 Jul 2014, at 18:02, David Laight <David.Laight@ACULAB.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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
next prev parent reply other threads:[~2014-07-09 16:12 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-04 21:05 [PATCH net-next 0/5] SCTP updates Daniel Borkmann 2014-07-04 21:05 ` Daniel Borkmann 2014-07-04 21:05 ` [PATCH net-next 1/5] net: sctp: fix information leaks in ulpevent layer Daniel Borkmann 2014-07-04 21:05 ` Daniel Borkmann 2014-07-04 21:05 ` [PATCH net-next 5/5] net: sctp: implement rfc6458, 8.1.31. SCTP_DEFAULT_SNDINFO support Daniel Borkmann 2014-07-04 21:05 ` Daniel Borkmann 2014-07-08 11:14 ` [PATCH net-next 0/5] SCTP updates Neil Horman 2014-07-08 11:14 ` Neil Horman 2014-07-08 14:05 ` Daniel Borkmann 2014-07-08 14:05 ` Daniel Borkmann 2014-07-08 14:41 ` Neil Horman 2014-07-08 14:41 ` Neil Horman 2014-07-09 9:57 ` Daniel Borkmann 2014-07-09 9:57 ` Daniel Borkmann 2014-07-09 10:49 ` Neil Horman 2014-07-09 10:49 ` Neil Horman 2014-07-09 11:12 ` David Laight 2014-07-09 11:12 ` David Laight 2014-07-09 13:28 ` Daniel Borkmann 2014-07-09 13:28 ` Daniel Borkmann 2014-07-09 15:13 ` Neil Horman 2014-07-09 15:13 ` Neil Horman 2014-07-09 15:25 ` Daniel Borkmann 2014-07-09 15:25 ` Daniel Borkmann 2014-07-09 15:41 ` Neil Horman 2014-07-09 15:41 ` Neil Horman 2014-07-09 15:36 ` Vlad Yasevich 2014-07-09 15:36 ` Vlad Yasevich 2014-07-09 15:44 ` Neil Horman 2014-07-09 15:44 ` Neil Horman 2014-07-09 16:02 ` David Laight 2014-07-09 16:02 ` David Laight 2014-07-09 16:12 ` Michael Tuexen [this message] 2014-07-09 16:12 ` Michael Tuexen 2014-07-09 16:30 ` Vlad Yasevich 2014-07-09 16:30 ` Vlad Yasevich 2014-07-09 16:32 ` Vlad Yasevich 2014-07-09 16:32 ` Vlad Yasevich 2014-07-09 18:35 ` Neil Horman 2014-07-09 18:35 ` Neil Horman 2014-07-10 9:02 ` David Laight 2014-07-10 9:37 ` Daniel Borkmann 2014-07-10 9:37 ` Daniel Borkmann 2014-07-10 10:57 ` Neil Horman 2014-07-10 10:57 ` Neil Horman 2014-07-10 19:04 ` Vlad Yasevich 2014-07-10 19:04 ` Vlad Yasevich 2014-07-10 10:55 ` Neil Horman 2014-07-10 10:55 ` Neil Horman 2014-07-09 16:10 ` Daniel Borkmann 2014-07-09 16:10 ` Daniel Borkmann 2014-07-08 21:40 ` David Miller 2014-07-08 21:40 ` David Miller 2014-07-09 7:59 ` Daniel Borkmann 2014-07-09 7:59 ` Daniel Borkmann -- strict thread matches above, loose matches on Subject: below -- 2008-12-20 1:47 [PATCH net-next 0/5]: " Vlad Yasevich 2008-12-20 1:47 ` Vlad Yasevich 2008-12-20 1:47 ` Vlad Yasevich 2008-12-20 1:47 ` Vlad Yasevich
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1AA30289-FE48-4E1E-90CF-8E567D8A1031@lurchi.franken.de \ --to=michael.tuexen@lurchi.franken.de \ --cc=David.Laight@ACULAB.COM \ --cc=davem@davemloft.net \ --cc=dborkman@redhat.com \ --cc=geirola@gmail.com \ --cc=linux-sctp@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=nhorman@tuxdriver.com \ --cc=vyasevich@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.