Re: 2.6.18 -mm merge plans

Serge E. Hallyn
2006-06-10T01:24:13Z

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> If you want to help with the bare pid to struct pid conversion I
> >> don't have any outstanding patches, and getting that done kills
> >> some theoretical pid wrap around problems as well as laying the ground
> >> work for a simple pidspace implementation.
> >>
> >> Eric
> >
> > Is this the sort of thing you are looking for? Is this worthwhile for
> > kernel_threads, or only for userspace threads - i.e. do we expect kernel
> > threads to live?
>
> For kernel threads we should simply be able to use their task
> struct.
>
> In this instance we have hit upon a different problem. Anything
> using the kernel_thread API instead of the kthread api needs
> to be updated.
>
> The basic problem is that for kernel_threads can show up
> inside of containers.
>
> We can fix that by updating daemonize or we can simply
> universally use the kthread api. Since the kernel_thread
> api is deprecated because of these kinds of reasons
> what really makes sense is to work on the transition
> to the kthread api.

Egads, I apologize.

Apparently I was in a daze, as I'd forgotten that converting
all kernel_thread users to kthread was something else we wanted
to work towards, and which Christoph had explicitly asked for
help with.

> Ok a couple of comments.
>
> As I recall there are some pretty sane ways of going
> from struct pid to a task_struct and then we can use things
> like group_send_sig.

Oh, you mean instead of doing kill_proc(struct pid->nr), which
I guess was pretty braindead? :)

Ok, futile as this may have seemed overall, I think it's helped
me figure out what to actually do.

thanks,
-serge