On Wed, May 20, 2020 at 09:54:36PM +0200, Christoph Hellwig wrote:
> Hi Dave,
>
> this series removes the kernel_setsockopt and kernel_getsockopt
> functions, and instead switches their users to small functions that
> implement setting (or in one case getting) a sockopt directly using
> a normal k
From: 'Christoph Hellwig'
> Sent: 21 May 2020 10:12
...
> > I worried about whether getsockopt() should read the entire
> > user buffer first. SCTP needs the some of it often (including a
> > sockaddr_storage in one case), TCP needs it once.
> > However the cost of reading a few words is small, and
On Thu, May 21, 2020 at 08:01:33AM +, David Laight wrote:
> How much does this increase the kernel code by?
44 files changed, 660 insertions(+), 843 deletions(-)
> You are also replicating a lot of code making it more
> difficult to maintain.
No, I specifically don't.
> I don't think the
From: Christoph Hellwig
> Sent: 20 May 2020 20:55
>
> this series removes the kernel_setsockopt and kernel_getsockopt
> functions, and instead switches their users to small functions that
> implement setting (or in one case getting) a sockopt directly using
> a normal kernel function call with typ
Looking at __sys_setsockopt() I noticed that the BPF intercept
can also cause set_fs(KERNEL_DS) be set in order to pass a
modified buffer into the actual setsockopt() code.
If that functionality is to be kept then the underlying
protocol specific code needs changing to accept a kernel buffer.
The
From: David Laight
Date: Thu, 14 May 2020 10:26:41 +
> I doubt we are the one company with out-of-tree drivers
> that use the kernel_socket interface.
Not our problem.
From: David Laight
Date: Thu, 14 May 2020 08:29:30 +
> You need to export functions that do most of the socket options
> for all protocols.
If all in-tree users of this stuff are converted, there is no argument
for keeping these routines.
You seemed to be concerned about out of tree stuff.
From: 'Christoph Hellwig'
> Sent: 14 May 2020 11:35
> On Thu, May 14, 2020 at 10:26:41AM +, David Laight wrote:
> > From: Christoph Hellwig
> > > Only for those were we have users, and all those are covered.
> >
> > What do we tell all our users when our kernel SCTP code
> > no longer works?
>
On Thu, May 14, 2020 at 10:26:41AM +, David Laight wrote:
> From: Christoph Hellwig
> > Only for those were we have users, and all those are covered.
>
> What do we tell all our users when our kernel SCTP code
> no longer works?
We only care about in-tree modules, just like for every other in
From: Christoph Hellwig
> Only for those were we have users, and all those are covered.
What do we tell all our users when our kernel SCTP code
no longer works?
It uses SO_REUSADDR, SCTP_EVENTS, SCTP_NODELAY,
SCTP_STATUS, SCTP_INITMSG, IPV6_ONLY, SCTP_SOCKOPT_BINDX_ADD
and SO_LINGER.
We should pr
On Thu, May 14, 2020 at 08:29:30AM +, David Laight wrote:
> You need to export functions that do most of the socket options
> for all protocols.
Only for those were we have users, and all those are covered.
From: Joe Perches
> Sent: 13 May 2020 18:39
> On Wed, 2020-05-13 at 08:26 +0200, Christoph Hellwig wrote:
> > this series removes the kernel_setsockopt and kernel_getsockopt
> > functions, and instead switches their users to small functions that
> > implement setting (or in one case getting) a sock
On Wed, May 13, 2020 at 10:38:59AM -0700, Joe Perches wrote:
> It might be useful to show overall object size change.
>
> More EXPORT_SYMBOL uses increase object size a little.
>
> And not sure it matters much except it reduces overall object
> size, but these patches remove (unnecessary) logging
From: Christoph Hellwig
Date: Wed, 13 May 2020 08:26:15 +0200
> Hi Dave,
>
> this series removes the kernel_setsockopt and kernel_getsockopt
> functions, and instead switches their users to small functions that
> implement setting (or in one case getting) a sockopt directly using
> a normal kern
Hi Dave,
this series removes the kernel_setsockopt and kernel_getsockopt
functions, and instead switches their users to small functions that
implement setting (or in one case getting) a sockopt directly using
a normal kernel function call with type safety and all the other
benefits of not havi
On Wed, 2020-05-13 at 08:26 +0200, Christoph Hellwig wrote:
> this series removes the kernel_setsockopt and kernel_getsockopt
> functions, and instead switches their users to small functions that
> implement setting (or in one case getting) a sockopt directly using
> a normal kernel function call w
16 matches
Mail list logo
