Message-ID: <7C078C66B7752B438B88E11E5E20E72E0EF423@GENERAL.farsite.co.uk>
From: Kevin Curtis <kevin.curtis@farsite.co.uk>
To: linux-kernel@vger.kernel.org
Subject: Implementing a sockets address family
Date: Mon, 8 Jul 2002 09:50:39 +0100 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2146
Lines: 42

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/