Find the answer to your Linux question:
Results 1 to 7 of 7
select() and shutdown() and SOCK_NOBLOCK don't compile in a kernel module build. Are they renamed?...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jan 2010
    Location
    The Sillicon Valley, California
    Posts
    28

    networking functions not in kernel


    select() and shutdown() and SOCK_NOBLOCK
    don't compile in a kernel module build.

    Are they renamed?

  2. #2
    Linux Guru coopstah13's Avatar
    Join Date
    Nov 2007
    Location
    NH, USA
    Posts
    3,149
    did you include sys/select.h?

  3. #3
    Just Joined!
    Join Date
    Jan 2010
    Location
    The Sillicon Valley, California
    Posts
    28
    There's no 'sys/select.h' in the kernel.
    And, there's no 'sys/<anything>'.

    There is 'linux/poll.h' and 'linux/socket.h' etc

  4. $spacer_open
    $spacer_close
  5. #4
    Just Joined!
    Join Date
    Jul 2009
    Posts
    49

    No select or etc... functions available

    You are trying to use user space function calls in a kernel module? I just looked through the kernel source and there is no defined function called "select()" or "socket()" which is what I expected. Remember there is no library linking while compiling a linux kernel.

    You have mentioned before that you are under the gun for delivering some s/w but I think you may have a rather serious design flaw in your approach. You are trying to use the typical UNIX Network approach to your kernel module. Unfortunately the kernel does not have that kind of API.

    You are going to have to write your own version of socket() and select() to fake out that layer but I have no idea if that would work either. Good Luck.

    Cheers!!

  6. #5
    Just Joined!
    Join Date
    Jan 2010
    Location
    The Sillicon Valley, California
    Posts
    28
    Actually, the kernel has networking, but the names are changed to allow linking.
    create_sock() replaces socket() and I have this working perfectly.

    But, I need to get it to allow re-connection if the far end drops the connection, but later reconnects. The far end is a Windows GUI. The embedded powers up first, then the GUI connects (and this works perfectly), but then the GUI will close, and later re-open, so the embedded kernel module needs to allow the GUI to reconnect.

    When the far end closes the connection, what happens to the embedded connection socket started with accept()? Do I have to do another accept()?

  7. #6
    Just Joined!
    Join Date
    Jul 2009
    Posts
    49

    You are correct in everything but name... lol

    Actually I found it here as "sock_create()". It does look like the same function but I'm obviously out of my depth here. I presume you are using the "kernel_accept() function (I have the source code up for linux 2.6.24).

    I would think that the implication here is that the standard UNIX networking model does apply then but since my Network book is not available I can't look it up. Sorry I can't help you here.

    Good Luck.

    Cheers!!

  8. #7
    Just Joined!
    Join Date
    Jan 2010
    Location
    The Sillicon Valley, California
    Posts
    28
    Whoops, sorry, sock_create() of course (pre-coffee dislexia, I should think).

    kernel_accept() ? Hmm. I've been using opt->accept.

    I believe I need to get SO_REUSEADDR working to allow re-connectivity.

    And, I need O_NONBLOCK to allow accept() to return if no pending connection.
    Should O_NONBLOCK be used in both the service socket for bind() and listen()
    and also in the connection socket for the accept() and recv() ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •