netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* sock_getsockopt() not exported
@ 2012-10-18  9:11 David Laight
  2012-10-18  9:30 ` Eric Dumazet
  0 siblings, 1 reply; 7+ messages in thread
From: David Laight @ 2012-10-18  9:11 UTC (permalink / raw)
  To: netdev

I've noticed that net/core/sock.c contains an
    EXPORT_SYMBOL(sock_setsockopt)
but is missing the corresponding
    EXPORT_SYMBOL(sock_getsockopt)

In-kernel users of sockets probably manage without
needing to read SOL_SOCKET options.
(They do need to set SO_REUSADDR and SO_KEEPALIVE.)

	David

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sock_getsockopt() not exported
  2012-10-18  9:11 sock_getsockopt() not exported David Laight
@ 2012-10-18  9:30 ` Eric Dumazet
  2012-10-18 12:03   ` David Laight
  0 siblings, 1 reply; 7+ messages in thread
From: Eric Dumazet @ 2012-10-18  9:30 UTC (permalink / raw)
  To: David Laight; +Cc: netdev

On Thu, 2012-10-18 at 10:11 +0100, David Laight wrote:
> I've noticed that net/core/sock.c contains an
>     EXPORT_SYMBOL(sock_setsockopt)
> but is missing the corresponding
>     EXPORT_SYMBOL(sock_getsockopt)
> 
> In-kernel users of sockets probably manage without
> needing to read SOL_SOCKET options.
> (They do need to set SO_REUSADDR and SO_KEEPALIVE.)


sock_setsockopt() is exported because sunrpc needs it, and sunrpc can be
a module

sock_getsockopt() is not exported because no module needs it yet.

The day one user needs it, we'll add the EXPORT_SYMBOL()

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: sock_getsockopt() not exported
  2012-10-18  9:30 ` Eric Dumazet
@ 2012-10-18 12:03   ` David Laight
  2012-10-18 12:27     ` Eric Dumazet
  2012-10-18 19:04     ` David Miller
  0 siblings, 2 replies; 7+ messages in thread
From: David Laight @ 2012-10-18 12:03 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: netdev

> On Thu, 2012-10-18 at 10:11 +0100, David Laight wrote:
> > I've noticed that net/core/sock.c contains an
> >     EXPORT_SYMBOL(sock_setsockopt)
> > but is missing the corresponding
> >     EXPORT_SYMBOL(sock_getsockopt)
> >
> > In-kernel users of sockets probably manage without
> > needing to read SOL_SOCKET options.
> > (They do need to set SO_REUSADDR and SO_KEEPALIVE.)
> 
> sock_setsockopt() is exported because sunrpc needs it, and sunrpc can be
> a module
> 
> sock_getsockopt() is not exported because no module needs it yet.
> 
> The day one user needs it, we'll add the EXPORT_SYMBOL()

The problem is that it might be needed by an 'out of tree' driver.
We already have the function:

static int
do_getsockopt(struct socket *sock, int level, int name, void *val, int len)
{
    mm_segment_t prevfs = get_fs();
    int rval;

    set_fs(KERNEL_DS);

    if (level == SOL_SOCKET) {
        /* There is no EXPORT_SYMBOL(sock_getsockopt) in net/core/sock.c */
        rval = -EINVAL; // sock_getsockopt(sock, level, name, val, &len);
    } else {
        rval = sock->ops->getsockopt(sock, level, name, val, &len);
    }

    set_fs(prevfs);
    return rval;
}

We need to get options (for SCTP) fortunately they aren't
SOL_SOCKET ones.

	David


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: sock_getsockopt() not exported
  2012-10-18 12:03   ` David Laight
@ 2012-10-18 12:27     ` Eric Dumazet
  2012-10-19  9:26       ` David Laight
  2012-10-18 19:04     ` David Miller
  1 sibling, 1 reply; 7+ messages in thread
From: Eric Dumazet @ 2012-10-18 12:27 UTC (permalink / raw)
  To: David Laight; +Cc: netdev

On Thu, 2012-10-18 at 13:03 +0100, David Laight wrote:
> > On Thu, 2012-10-18 at 10:11 +0100, David Laight wrote:
> > > I've noticed that net/core/sock.c contains an
> > >     EXPORT_SYMBOL(sock_setsockopt)
> > > but is missing the corresponding
> > >     EXPORT_SYMBOL(sock_getsockopt)
> > >
> > > In-kernel users of sockets probably manage without
> > > needing to read SOL_SOCKET options.
> > > (They do need to set SO_REUSADDR and SO_KEEPALIVE.)
> > 
> > sock_setsockopt() is exported because sunrpc needs it, and sunrpc can be
> > a module
> > 
> > sock_getsockopt() is not exported because no module needs it yet.
> > 
> > The day one user needs it, we'll add the EXPORT_SYMBOL()
> 
> The problem is that it might be needed by an 'out of tree' driver.
> We already have the function:

We dont care of out of tree drivers.

Thats really simple.

Submit this driver, and add the EXPORT_SYMBOL() you need at that time.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sock_getsockopt() not exported
  2012-10-18 12:03   ` David Laight
  2012-10-18 12:27     ` Eric Dumazet
@ 2012-10-18 19:04     ` David Miller
  1 sibling, 0 replies; 7+ messages in thread
From: David Miller @ 2012-10-18 19:04 UTC (permalink / raw)
  To: David.Laight; +Cc: eric.dumazet, netdev

From: "David Laight" <David.Laight@ACULAB.COM>
Date: Thu, 18 Oct 2012 13:03:55 +0100

> The problem is that it might be needed by an 'out of tree' driver.

We don't care.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: sock_getsockopt() not exported
  2012-10-18 12:27     ` Eric Dumazet
@ 2012-10-19  9:26       ` David Laight
  2012-10-19 17:12         ` David Miller
  0 siblings, 1 reply; 7+ messages in thread
From: David Laight @ 2012-10-19  9:26 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: netdev

> > The problem is that it might be needed by an 'out of tree' driver.
> > We already have the function:
> 
> We dont care of out of tree drivers.
> 
> Thats really simple.
> 
> Submit this driver, and add the EXPORT_SYMBOL() you need at that time.

Even if management would release the source, you wouldn't
want 4MB of source for an ss7 protocol stack for a card
that isn't generally available, and that needs another
similar sized driver (and libraries etc) to be useful.

The Linux interface is all done with wrapper functions
that get compiled on the target system so we can ship
a big binary 'blob'.

	David


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sock_getsockopt() not exported
  2012-10-19  9:26       ` David Laight
@ 2012-10-19 17:12         ` David Miller
  0 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2012-10-19 17:12 UTC (permalink / raw)
  To: David.Laight; +Cc: eric.dumazet, netdev

From: "David Laight" <David.Laight@ACULAB.COM>
Date: Fri, 19 Oct 2012 10:26:52 +0100

> The Linux interface is all done with wrapper functions
> that get compiled on the target system so we can ship
> a big binary 'blob'.

Your maintainence problem, not our's.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-10-19 17:13 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-18  9:11 sock_getsockopt() not exported David Laight
2012-10-18  9:30 ` Eric Dumazet
2012-10-18 12:03   ` David Laight
2012-10-18 12:27     ` Eric Dumazet
2012-10-19  9:26       ` David Laight
2012-10-19 17:12         ` David Miller
2012-10-18 19:04     ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).