On 08/03, Peter Zijlstra wrote:
>
> 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,
No, no, we should not export them of course.
f_setown_struct->type could be 0,1,2 (or whatever), fcntl() maps them
to fown_struct->enum_type or ->enum_type + ->task_only.
To clarify, I am not really sure this interface is better. Just for
discussion. Because it will be very painful to change this api later.
It is better to at least consider all options now.
Oleg.
------------------------------------------------------------------------------
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
