[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <479EE10C.5060101@openvz.org>
Date: Tue, 29 Jan 2008 11:17:16 +0300
From: Pavel Emelyanov <xemul@...nvz.org>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>,
vinay@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
libc-alpha@...rceware.org, drepper@...hat.com, wli@...omorphy.com,
sripathik@...ibm.com
Subject: Re: [RFC] Per-thread getrusage
Andrew Morton wrote:
> On Mon, 28 Jan 2008 13:43:02 -0700
> ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
>> Pavel Emelyanov <xemul@...nvz.org> writes:
>>>> ...
>>>> +asmlinkage long sys_thread_getrusage(int tid, struct rusage __user *ru)
>>>> +{
>>>> + struct task_struct *tsk;
>>>> + tsk = find_task_by_pid(tid);
>>>> + return getrusage(tsk, RUSAGE_THREAD, ru);
>>>> +}
>>> Well, the find_task_by_pid() is really wrong here.
>> And find_task_by_pid should probably just be removed.
>
> That's what I was thinking.
find_task_by_pid and find_pid are to be removed, but this task
heavily depends on others.
E.g. to drop the find_pid() we need to kill the kill_proc()
function, which in turn depends on turning the usbatm, nfs and
lockd code into kthread API. We're currently working on this.
>> No need to provide function with the gun firmly pointed at our feet....
>
> It still has a disturbingly large number of callers.
Yes, but unfortunately simple conversion from find_xxx_pid into
find_xxx_vpid is not possible - each case is special.
Thanks,
Pavel
--
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