[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: too many warning messages from gnumach

From: Samuel Thibault
Subject: Re: too many warning messages from gnumach
Date: Wed, 17 Mar 2010 13:51:42 +0100
User-agent: Mutt/1.5.12-2006-07-14

Da Zheng, le Wed 17 Mar 2010 20:45:39 +0800, a écrit :
> On 10-3-17 下午8:39, Samuel Thibault wrote:
> > Da Zheng, le Wed 17 Mar 2010 20:00:11 +0800, a écrit :
> >> On 10-3-17 下午6:31, Samuel Thibault wrote:
> >>>> After I get pid from ps, how do I map it to task ID in kdb?
> >>>
> >>> You can't, only the proc server knows that. But for the initial tasks,
> >>> you know in which order they get started, and thus their task number.
> >> so in many cases (the warning is triggered by ordinary programs), kdb 
> >> cannot
> >> help us find the process that triggers the warning as task ID cannot tell 
> >> us
> >> much information
> > 
> > Yes, that's unfortunate that the very design of the Hurd makes it hard:
> > exec knows the binary name, proc knows the pid. Nobody knows it all. A
> > solution could be to have gnumach find out in the proc memory space
> > where the task/pid association is. Or you modify the proc server to dump
> > the task/pid association on each process spawn.
> You confuse me again. What the proc server has is task ports. I thought you
> agreed a task port isn't a task ID in kdb. If it isn't, what is the task/pid
> association we can dump?

You can then make the kernel dump the task ID / task port for proc
association, and eventually get the result.

Anyway, usually I could just get the command line by avoiding swap,
that's much simpler :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]