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
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 having a
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.
On Thu, May 14, 2020 at 11:11:34AM +, David Laight wrote:
> 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.
> > >
> > > Wha
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
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 having a
19 matches
Mail list logo
