Messages in this thread | | | Date | Mon, 3 Aug 2009 20:06:02 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 3/2] fcntl: F_[SG]ETOWN_TID |
| |
On 08/03, Peter Zijlstra wrote: > > On Mon, 2009-08-03 at 19:16 +0200, Oleg Nesterov wrote: > > > Hmm, OK. so fcntl(F_SETOWN_TID, -666) <=> fcntl(F_SETOWN, +666). > > > > Not that I disagree, but I think this should be discussed. Perhaps > > F_SETOWN_TID can just reject who < 0. > > Yeah, I considered that. Opinions?
Yes, please ;)
> > but the caller of F_GETOWN can't know what the returned value actually > > means if F_GETOWN_TID was used. > > Ah, I made GETOWN_TID deal with !PID but forgot the TID case in GETOWN. > Yeah, icky, esp since there is no room for errors in the return value :/ > I guess I could make it return 0.
Yes, this is confusing too, but probably better.
> > Perhaps we can just add > > > > #define F_PIDTYPE_THREAD PIDTYPE_MAX > > > > into fcntl.c ? Then, > > > Right, I considered adding PIDTYPE_TID, but then I'd have to go through > the kernel and make everything consistent, which is where I gave up ;-)
Note! we don't add the new PIDTYPE_TID actually. This F_PIDTYPE_THREAD is not visible outsie of fcntl.c, we just re-use ->pid_type. Instead we could add a bit, but using the impossible PIDTYPE_MAX is simpler.
> dunno if people will go for it though..
Yes, I am not sure people will like it.
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.
I dunno.
Oleg.
| |