Re: Interface for communicating from kernel to user mode

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

> [...reached the point of having the struct socket *...]

> What I cannot resolve is which function to use for receiving data
> sent from user mode on retrieved file_fd in kernel module.  When I
> tried soo_read(file_fd,...) then OS freezes and need to reboot.  I
> call soo_read() in kernel thread.

Could you break into ddb?  A stack trace of the freeze might be useful.
If you're using screen-and-keyboard console and can't get into ddb, I'd
suggest switching to serial console (or vice versa, though I consider
that less likely); I've had one work when the other fails often enough.

> Should it be functional or am I doing something wrong ?

I'm not sure; I don't even know which kernel version you're using, much
less know the details of that kernel (unless you're using 1.4T, 4.0.1,
or 5.2, each of which I consider unlikely).

My impression, at a quick glance, is that soo_read is appropriate for
reading data from a socket to *userland*.  Looking at the pfs code, I
started with pfs_call and drilled down, finding pfs_sorecv() in
particular, which calls the socket's so_receive method with a struct
uio whose uio_segflg is UIO_SYSSPACE.

I am not confident this is correct for you unless you are working in
the same 1.4T kernel pfs is designed for.  But you should be able to
find the correct call to use by looking at the implementatino of
syscalls that read data from a socket, such as recvfrom().  Looking at
5.2, I see that sys_recvfrom() calls do_sys_recvmsg which ends up
calling the socket's so_receive method.  I'd recommend looking at the
source for the kernel you're using to see how syscalls such as
recvfrom() perform the data transfer, then adapt that, probably
something like changing the iuo_segflg to UIO_SYSSPACE.

In general, when you want to know how to do something, a useful tactic
is often to look for code that does something closely releated and then
adapt that.  In this case, for the previous question, about finding the
struct socket from the file descriptor, I wrote my code by looking for
existing code that did that; various of the socket syscalls had to do
that in some form, so I looked at them.  For transferring data, I
looked at existing code which transferred data out of a socket.  There
are, as you discovered, various calls for doing that; since soo_read
didn't work for you, you'd need to either take its internals and adapt
them to your purpose or look at some other example.  soo_read is the
socket implementation of the generic file-descriptor `read' method, so
its internals may be worth looking at - and, looking at 5.2's soo_read,
I see that it just is a very thin wrapper around the socket's
so_receive method.  Looking at socket-specific calls, recvfrom in
particular, I again see the implementation calling the socket's
so_receive method to do the work.  When I wrote pfs, I ended up doing
the same thing myself.  I do not now recall what other attempts (if
any) I made before settling on the so_receive method as the appropriate
interface for my purposes.

The "adapt" part, in this case, refers to things such as changing the
uio_segflg to UIO_SYSSPACE.  As for knowing that that is the particular
change you need, well, at first, you don't - and, indeed, under 5.2
there is no uio_segflg; if I were trying to do something like this in
5.2 I'd have to go digging to figure out where 5.2 records the
difference between userland and kernel when doing I/O.

/~\ 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