[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53BD1211.4080504@redhat.com>
Date: Wed, 09 Jul 2014 11:57:37 +0200
From: Daniel Borkmann <dborkman@...hat.com>
To: Neil Horman <nhorman@...driver.com>
CC: davem@...emloft.net, geirola@...il.com, netdev@...r.kernel.org,
linux-sctp@...r.kernel.org
Subject: Re: [PATCH net-next 0/5] SCTP updates
On 07/08/2014 04:41 PM, Neil Horman wrote:
> On Tue, Jul 08, 2014 at 04:05:26PM +0200, Daniel Borkmann wrote:
>> On 07/08/2014 01:14 PM, Neil Horman wrote:
>> ...
>>> since you're adding cmsg's from rfc6458, do you also want to add some
>>> deprecation warnings around the use of SCTP_SNDRCVINFO too, so we can start to
>>> schedule its eventual removal?
>>
>> Sure, we can do that. Do you want me to include it into the set?
>
> If you're plan is to implement 6458, then yes, I think that would be good.
Looking a bit closer at it, all our pr_warn_ratelimited(DEPRECATED ...)
warnings in SCTP are being done in 'slowpath' {set,get}sockopt(2) operations
only, which is fine. What you're suggesting is to place similar ratelimited
warnings (due to different possible pids on the machine) into the 'fastpath'
where we get and set cmsg message headers.
While that may be fine for {set,get}sockopt(2) that's called once or very few
times, I'm not sure this is a good idea in SCTP_SNDRCVINFO as it will yield
to unnecessary spamming the klog since up to now this is the only way our
users can set or receive this info. I'm not sure we want to annoy users like
that ...
In how many years do you plan a removal ... I think we're stuck with uapi
basically forever as we don't want to break old binaries, no? ;/
--
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