Re: [Fwd: Re: Advice on child process reading parent's process flags]

Thanks to both of you for the jump start.

> 
> -------- Original Message --------
> Subject: Re: [SSI-devel] Advice on child process reading parent's
> process flags
> Date: Tue, 18 Sep 2007 12:08:02 -0700
> From: Laura Ramirez <[email protected]>
> To: Roger Tsang <[email protected]>
> References: <[email protected]>
> <[email protected]>
> 
> Recalling from memory since I haven't worked on this for a while.
> There are VPOPS operations, that are used to find a remote process.
> VPOP_GETATTR() gets certain attributes of a process, however it may
> not return what you need, so you may need to modify it. I believe
> there was some correlation between the process flags and the 
> pvp_flags,
> it depends what particular process flag that you want to see and what
> it would mean in vprocs.

I found VPOP_GETATTR() although it did not get the p->flags I was looking
for; pvp_flags look promising.

> 
> Also just to clarify, a vproc -> pvproc -> pproc (base 
> task_struct) for
> a local process.
> For a remote process, a vproc -> pvproc -> NULL, use the vproc for the
> VPOP operation to get to a remote process.

Thanks for clarifying this.

> 
> laura
> 
> Roger Tsang wrote:
> > dvp_rfork()
> > 
> > Roger
> > 
> > On 9/17/07, Stan <[email protected]> wrote:
> >>
> >> Hello,
> >>   Could someone kindly explain how to, or point me towards 
> code examples
> >> which illuminate how to _correctly_/safely read a parent's 
> process flags
> >> (p->flags)?
> >> 'current' is the child, which needs to read it's parents 
> process flags.
> >> current->ppid I assume is the parent's processID, if it's 
> local then no
> >> problem (conceptually ppid->vproc->task_struct?), if 
> remote then things get
> >> interesting.
> >>
> >> TIA,
> >>
> >> Stan.
> >> 
> --------------------------------------------------------------
> -----------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2005.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> ssic-linux-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel
> >>
> >>
> > 
> > 
> --------------------------------------------------------------
> -----------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > ssic-linux-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel
> > 
> > 
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> ssic-linux-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel
> 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/