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). > >> 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.