proc_t for the active process
in [Solaris]
|
Prev: Warning: error writing VTOC Warning: no backup labels Write label failed
Next: Problem with Developer Releases - Drive offline
From: Casper H.S. Dik on 1 Nov 2009 04:45 nccc <strikosn(a)gmail.com> writes: >Anyway, if there is no way to find this information in the process >address space, where exactly can I find it in the kernel memory? Is >there a fixed position for the proc_t of the active process or for a >pointer to it? The CPU structure has a "thread" field and that is a thread from the current process. E.g., in mdb: > ::cpuinfo ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC 0 300014b4000 1b 0 0 49 no no t-0 300020fcae0 xterm 1 0000180c000 1b 0 0 59 no no t-0 300043a27c0 mdb > 0000180c000::print "cpu_t" cpu_thread[0].t_procp[0].p_user.u_comm cpu_thread[0].t_procp[0].p_user.u_comm = [ "mdb" ] Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
From: nccc on 1 Nov 2009 07:08 On Nov 1, 11:45 am, Casper H.S. Dik <Casper....(a)Sun.COM> wrote: > nccc <strik...(a)gmail.com> writes: > >Anyway, if there is no way to find this information in the process > >address space, where exactly can I find it in the kernel memory? Is > >there a fixed position for the proc_t of the active process or for a > >pointer to it? > > The CPU structure has a "thread" field and that is a thread from > the current process. > > E.g., in mdb: > > > ::cpuinfo > > ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC > 0 300014b4000 1b 0 0 49 no no t-0 300020fcae0 xterm > 1 0000180c000 1b 0 0 59 no no t-0 300043a27c0 mdb > > > 0000180c000::print "cpu_t" cpu_thread[0].t_procp[0].p_user.u_comm > > cpu_thread[0].t_procp[0].p_user.u_comm = [ "mdb" ] > > Casper > -- > Expressed in this posting are my opinions. They are in no way related > to opinions held by my employer, Sun Microsystems. > Statements on Sun products included here are not gospel and may > be fiction rather than truth. Ok, that's very fine.. Precisely what I need, thank you. But will I always find the first cpu_t structure in address 0x180c000 in kernel memory? The simulator breaks at every processor mode change, i.e. from user to supervisor mode and vice versa for any processor. Before it resumes, I have to decide which process owns the thread that is scheduled to run..
From: nccc on 1 Nov 2009 07:09 On Nov 1, 11:45 am, Casper H.S. Dik <Casper....(a)Sun.COM> wrote: > nccc <strik...(a)gmail.com> writes: > >Anyway, if there is no way to find this information in the process > >address space, where exactly can I find it in the kernel memory? Is > >there a fixed position for the proc_t of the active process or for a > >pointer to it? > > The CPU structure has a "thread" field and that is a thread from > the current process. > > E.g., in mdb: > > > ::cpuinfo > > ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC > 0 300014b4000 1b 0 0 49 no no t-0 300020fcae0 xterm > 1 0000180c000 1b 0 0 59 no no t-0 300043a27c0 mdb > > > 0000180c000::print "cpu_t" cpu_thread[0].t_procp[0].p_user.u_comm > > cpu_thread[0].t_procp[0].p_user.u_comm = [ "mdb" ] > > Casper > -- > Expressed in this posting are my opinions. They are in no way related > to opinions held by my employer, Sun Microsystems. > Statements on Sun products included here are not gospel and may > be fiction rather than truth. Ok, that's very fine.. Precisely what I need, thank you. But will I always find the first cpu_t structure in address 0x180c000 in kernel memory? The simulator breaks at every processor mode change, i.e. from user to supervisor mode and vice versa for any processor. Before it resumes, I have to decide which process owns the thread that is scheduled to run..
From: nccc on 1 Nov 2009 07:09 On Nov 1, 11:45 am, Casper H.S. Dik <Casper....(a)Sun.COM> wrote: > nccc <strik...(a)gmail.com> writes: > >Anyway, if there is no way to find this information in the process > >address space, where exactly can I find it in the kernel memory? Is > >there a fixed position for the proc_t of the active process or for a > >pointer to it? > > The CPU structure has a "thread" field and that is a thread from > the current process. > > E.g., in mdb: > > > ::cpuinfo > > ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC > 0 300014b4000 1b 0 0 49 no no t-0 300020fcae0 xterm > 1 0000180c000 1b 0 0 59 no no t-0 300043a27c0 mdb > > > 0000180c000::print "cpu_t" cpu_thread[0].t_procp[0].p_user.u_comm > > cpu_thread[0].t_procp[0].p_user.u_comm = [ "mdb" ] > > Casper > -- > Expressed in this posting are my opinions. They are in no way related > to opinions held by my employer, Sun Microsystems. > Statements on Sun products included here are not gospel and may > be fiction rather than truth. Ok, that's very fine.. Precisely what I need, thank you. But will I always find the first cpu_t structure in address 0x180c000 in kernel memory? The simulator breaks at every processor mode change, i.e. from user to supervisor mode and vice versa for any processor. Before it resumes, I have to decide which process owns the thread that is scheduled to run..
From: Casper H.S. Dik on 1 Nov 2009 08:17
nccc <strikosn(a)gmail.com> writes: >Ok, that's very fine.. Precisely what I need, thank you. But will I >always find the first cpu_t structure in address 0x180c000 in kernel >memory? No, it's all dynamic .... >The simulator breaks at every processor mode change, i.e. from user to >supervisor mode and vice versa for any processor. Before it resumes, I >have to decide which process owns the thread that is scheduled to run.. Ah, right. Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth. |