> [...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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
