Re: Interface for communicating from kernel to user mode

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I am trying to implement user<->kernel communication with
> socketpair() in user space and then passing one of descriptors to
> kernel.

> I am investigating socket.h and socketvar.h
> There are functions working with sockets in kernel space, they [use]
> struct socket in their parameters and user space functions uses int
> like socket descriptor.

Right.

> How to retrieve pointer struct socket from socket descriptor (int)
> passed from user mode ?

> Or if it is used in your repository where can I find it ?

It is.  The API my code implements takes an int file descriptor from
userland and then takes over the socket that descriptor refers to, so
it _must_ have code to locate the socket from the descriptor.

It also is present in some form in every call that takes a file
descriptor which refers to a socket (eg, getsockname) or, in some
cases, which can refer to a socket (eg, write), and then manipulates
that socket.

For my code, see pfs-vfsops.c:

static int pfs_mount(struct mount *mp, const char *path, void *data, struct nameidata *ndp, struct proc *p)
{
[...]
 err = copyin(data,&args,sizeof(args));
[...]
 err = copyin(args.pfsa_data,&args_1_3,sizeof(args_1_3));
[...]
 /* getsock() will use the descriptor for us */
 err = getsock(p->p_fd,args_1_3.pfsa_socket,&fp);
[...]
 if (fp->f_type != DTYPE_SOCKET)
  { [...]
  }
 so = fp->f_data;

My API calls for the userland descriptor to get closed, so, later in
pfs_mount(), after more error checking and setup,

 fdrelease(p,args_1_3.pfsa_socket);

which you may or may not want depending on the API you want to present
to userland.

Of course, unless you're working in the same kernel, the details will
likely differ in the kernel you're using.  But, if you start with a
socket-only syscall such as getsockname() and drill down, there's got
to be code _somewhere_ in there that converts the userland-suplied file
descriptor int into something internal, like a struct socket.

In the case of the 1.4T code my pfs pstuff went into, this happens very
early in sys_getosckname:

        /* getsock() will use the descriptor for us */
        if ((error = getsock(p->p_fd, SCARG(uap, fdes), &fp)) != 0)
                return (error);
[...]
        so = (struct socket *)fp->f_data;

In 5.2, the newest version I use routinely, the code is even simpler:

int
sys_getsockname(struct lwp *l, const struct sys_getsockname_args *uap, register_t *retval)
{
[...]
	error = do_sys_getsockname(l, SCARG(uap, fdes), PRU_SOCKADDR, &m);
[...]
}

and

int
do_sys_getsockname(struct lwp *l, int fd, int which, struct mbuf **nam)
{
	struct socket	*so;
[...]
	if ((error = fd_getsock(fd, &so)) != 0)
		return error;

It would make the most sense, I would say, for you to look at what the
kernel you care about does in such calls when it wants to map a
userland-provided socket fd to its internal data structure.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B