On Mon, 2009-08-03 at 20:06 +0200, Oleg Nesterov wrote:
>
> As for F_XXXOWN/F_XXXWOWN_TID interaction. Another option, perhaps, is add
> F_{SET,GET}OWN_EX which accepts a use-visible
>
> struct f_setown_struct {
> int pid; // > 0
> int type; // enumerates PIDTYPE_PID,
> PIDTYPE_PGID, F_PIDTYPE_THREAD
> }
>
> pointer via arg. Instead of F_XXXOWN_TID + int who.
>
> This way at least the users of new api can't be confused.
This would expose PIDTYPE* to userspace, and also fixes the value of
F_PIDTYPE_THREAD.
I'm not sure we want to go there (unless of course, PIDTYPE_* is already
exposed somewhere).
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
