After playing with kgdb for an afternoon, I now finally understand
what is going on: I am sending a struct (of the simpleq variety)
over to the kernel via the ioctl, so what I am getting back is the
struct copied to userland.  The struct contains pointers to kernel
memory => I can't see the contents of what they point to. Fair
enough. So can the kernel grab user memory or must I find a way of
sending a pointer to some over? (I assume kernel can "only" do
malloc(9) not malloc(3), but somehow I need a uaddr for copyout..)

Anyone care to teach me?

Cheers,

Patrick


On Mon, Jan 22, 2001 at 07:41:15PM +0000, Ben Harris wrote:
> In article <20010122181104.A1301@quartz.newn.cam.ac.uk> you write:
> >I'm trying to get the kernel to fill in a SIMPLEQ, and reach it from userland
> >via an ioctl.
> >
> >- Is there something simpler than a SIMPLEQ? (new to sys/queue.h)
> 
> SLIST is simpler in that it doesn't have a tail pointer (so you shouldn't
> use it if you need a queue).  Alternatively, if you don't mind it being
> expensive to dynamically grow the data, you could use a straightforward
> array.  These are far easier to copy into user space.
> 
> >- Shouldn't I need a copyout or something? Don't see where though..
> 
> This is handled by sys_ioctl().  Look in sys/kern/sys_generic.c, and you'll
> find that it does:
> 
>                 error = (*fp->f_ops->fo_ioctl)(fp, com, data, p);
>                 if (error == 0 && (com&IOC_OUT) && size)
>                         error = copyout(data, SCARG(uap, data), size);
>                 break;
> 
> Thus, all you need to do is to copy the data to the pointer you're given by
> sys_ioctl(), and it will handle the copyout().
> 
> >Test userland prog works. With same function filling queue in kernel, I just
> >get back null pointer, then again it doesn't surprise me too much, as I put
> >a SIMPLEQ_HEAD in a header file, but what does a "global" variable mean when
> >it appears in both kernel and executable - not very global anymore...
> 
> Indeed.  It's only global within the kernel.  Even if you got the address of
> the structure into user space, this wouldn't help because user code can't
> see kernel memory.
> 
> -- 
> Ben Harris                                                   <bjh21@netbsd.org>
> Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>
> 
>