Eric Keller wrote: > Thanks for the reply. More below. > > >>> What I'm trying to do is to run a kernel thread, but have it associated >>> with a particular user's context. The reason is this - I want to run >>> Click in the kernel, but allow each user to provide their own click >>> graph. The root context will manage the whole process, performing >>> checks, then merging the various click graphs into a single click >>> graph, >>> and installing that in the kernel. Each user graph would be run within >>> their own kernel thread. >>> >> >> Why would it need to be associated with the context? How would it be >> started? >> > There is a single kernel module that gets installed with insmod, it > starts up N kernel threads (one for each user context). I do this in > the root context. The user gets to partially define the functionality > of the thread, so I want the CPU cycles, etc, to be charged to that > context (so they are still limited to what the configuration of vserver > specifies). So what is creating the kernel thread when a context is created? Note that running a kernel thread in a context requires you to make sure it exits when the context is supposed to die, or make it possible to kill it. I'm not sure what sort of life-span we're talking about. >>> I've looked through the vserver code and before I start doing any >>> modifications, I wanted to post to the group to see if anyone has any >>> guidance. It appears that include/linux/vs_context.h provides all of >>> the functionality I'd need. So I would start the kernel thread as >>> usual, then I would transfer it (by changing vx_info and xid, from >>> task_struct) from the kernel's vx_info to a particular user context's >>> vx_info (I would get the vx_info with lookup_vx_info(xid)). >>> >> >> All those values are inherited from the parent, so this kind of depends >> on >> the answer to my second question above. >> >> Note that there are more values to consider. vx_migrate_task handles all >> this for you, so you might want to look at using that... >> > > Thanks, I think vx_migrate_task may indeed be what I'm looking for. > Based on what I responded above, do you agree? The kernel thread would > start under the root context, then I would get the vx_info of the user > context that I'm interested in, then call vx_migrate_task and I should > be set. Seems like it. -- Daniel Hokka Zakrisson