Hi,
I am implementing a sockets interface to a existing driver that
exchanges a proprietary protocol with an intelligent sync card, the existing
driver is a char driver. I have used the Kernel X.25 driver's sockets
interface as a template. I have several issues at the moment, so here are
some questions:
1) It seems that the only way you can tell if the socket is blocking or
non-blocking is to looks at the flags or msghdr->flags on each function
call. Is this the case? When the socket is set to non-blocking and a call
to the system recv() function is made, my recvmsg() function is called but
neither the flags parameter nor the flags in the msghdr structure have any
indication that the socket is non-blocking. What am I missing here?
2) My second question is also a non-blocking issue. When I set the socket
to non-blocking and call the system accept() function, my accept() function
is called with O_NONBLOCK in the flags parameter. If there isn't a call
pending, I return -EWOULDBLOCK. However this causes my release() function
to be called immediately with NULL in sock->sk.
Looking at socket.c, it looks as though a new socket structure is allocated
before the call to my accept(), and then when I return the error, release()
is called with the newly allocated socket structure that at this point is
not valid. Is this a bug or should I be doing something else?
3) When releasing socket resources, sk_free() is called. There is a pointer
to my structure in sk, is it correct that sk_free() will free my structure
and I therefore don't need to call kfree() myself?
4) I seem to have a resilience problem where some of my tests seems to cause
oops's in other seemingly non related processes (x for example). I am
thinking that this could be a double deallocation or perhaps a stack
problem. What is the best way for tracking down such problems?
Thanks in advance
Kevin
Hi,
On Mon, 8 Jul 2002, Kevin Curtis wrote:
> 1) It seems that the only way you can tell if the socket is blocking or
> non-blocking is to looks at the flags or msghdr->flags on each function
> call. Is this the case? When the socket is set to non-blocking and a call
> to the system recv() function is made, my recvmsg() function is called but
> neither the flags parameter nor the flags in the msghdr structure have any
> indication that the socket is non-blocking. What am I missing here?
non-blocking is a matter of behavior. It easily doesn't block.
The man page says
O_NONBLOCK or O_NDELAY
When possible, the file is opened in non-blocking
mode. Neither the open nor any subsequent opera-
tions on the file descriptor which is returned will
cause the calling process to wait. For the han-
dling of FIFOs (named pipes), see also fifo(4).
This mode need not have any effect on files other
than FIFOs.
So it shouldn't work outside FIFOs. However, have a look at net/ipv4/tcp.c
for more details.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
Hi,
thanks for the reply. From an application point of view, when a
socket is created it is non-blocking by default. If the application uses
ioctl or fcntl to set the socket to non-blocking mode, then all I was saying
was I don't see any indication in flags or msghdr->flags as to whether the
user wants to wait for the recv to complete or not. How is my recvmsg()
function in my implementation of the new address family supposed to
differentiate. I cannot see any reference to O_NONBLOCK or MSG_DONTWAIT in
the tcp_recvmsg() function.
Kevin
-----Original Message-----
From: Thunder from the hill [mailto:[email protected]]
Sent: 08 July 2002 13:16
To: Kevin Curtis
Cc: [email protected]
Subject: Re: Implementing a sockets address family
Hi,
On Mon, 8 Jul 2002, Kevin Curtis wrote:
> 1) It seems that the only way you can tell if the socket is blocking or
> non-blocking is to looks at the flags or msghdr->flags on each function
> call. Is this the case? When the socket is set to non-blocking and a
call
> to the system recv() function is made, my recvmsg() function is called but
> neither the flags parameter nor the flags in the msghdr structure have any
> indication that the socket is non-blocking. What am I missing here?
non-blocking is a matter of behavior. It easily doesn't block.
The man page says
O_NONBLOCK or O_NDELAY
When possible, the file is opened in non-blocking
mode. Neither the open nor any subsequent opera-
tions on the file descriptor which is returned will
cause the calling process to wait. For the han-
dling of FIFOs (named pipes), see also fifo(4).
This mode need not have any effect on files other
than FIFOs.
So it shouldn't work outside FIFOs. However, have a look at net/ipv4/tcp.c
for more details.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
> Hi,
> thanks for the reply. From an application point of view, when a
> socket is created it is non-blocking by default. If the application uses
> ioctl or fcntl to set the socket to non-blocking mode, then all I was
saying
> was I don't see any indication in flags or msghdr->flags as to whether
the
> user wants to wait for the recv to complete or not. How is my recvmsg()
> function in my implementation of the new address family supposed to
> differentiate. I cannot see any reference to O_NONBLOCK or
> MSG_DONTWAIT in the tcp_recvmsg() function.
If its non blocking, nonblock is 1, and the function sock_rcvtimeo()
sets timeo to 0. If there isnt any data to read, copied is set to -EAGAIN,
we break out of the big do loop, pretty much fall through the rest of the
function and return copied.
thanks,
Nivedita