Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Arjan van de Ven]

> 99% of the time, the kernel can deal with the same old tsk->pid that
> it's always dealt with.  Generally, the only times the kernel has to
> worry about the virtualized one is where (as Eric noted) it cross the
> user<->kernel boundary.

that's fair enough. I don't see the need for the macro abstractions
though; a current->pid and current->user_pid (or visible_pid or any
other good name) split makes sense. no need for macro abstractions at
all, just add ->user_pid in patch 1, in patch 2 assign it default to
->pid as well and patch 3 converts the places where ->pid is now given
to userspace ;)

again the DRM layer needs an audit, I'm not entirely sure if it doesn't
get pids from userspace. THe rest of the kernel mostly ought to cope
just fine.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/