[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090803190231.GA22313@redhat.com>
Date: Mon, 3 Aug 2009 21:02:31 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Andrew Morton <akpm@...ux-foundation.org>, eranian@...il.com,
mingo@...e.hu, linux-kernel@...r.kernel.org, tglx@...utronix.de,
robert.richter@....com, paulus@...ba.org, andi@...stfloor.org,
mpjohn@...ibm.com, cel@...ibm.com, cjashfor@...ibm.com,
mucci@...s.utk.edu, terpstra@...s.utk.edu,
perfmon2-devel@...ts.sourceforge.net, mtk.manpages@...glemail.com,
roland@...hat.com
Subject: Re: [PATCH 3/2] fcntl: F_[SG]ETOWN_TID
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists