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
>> 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
Received on Fri Nov 30 17:26:53 2007