Questions about struct task_struct
I am new to kernel programming and have a lot questions about this structure. Also if after you guys reply I have a few \ questions for Greg Kroah Hartman about usb development and stable trees. I am very excited about learning this properly now and if anyone notices something wrong in my understanding please let me known :). Thanks So Much, Nick Questions about task_struct 1.volatile long state; Is this line like jiffies for timers with regards to the keyword volatile? 2.void *stack; Is this a pointer to the kernel stack for the process related to the process that the structure is keeping data for and is void to make it an opaque data type? Is this normally an int or some other data type when called with most processes? 3.unsigned int flags; /* per process flags, defined below */, My only question about this is what flags are there and are these the ifdef statements in the struct? 4.Why are we making the usage count atomic?(pretty obvious but real world reasons would be great) 5.I assume int ptrace is for ptrace or debugged processes? If I wrong please let me known too. 6. What is wakkee_flips and wakkee_flips_decay used for? 7.This is probably a stupid question but are these the scheduler cases for CFS? 1240 int on_rq; 1241 1242 int prio, static_prio, normal_prio; 1243 unsigned int rt_priority; 1244 const struct sched_class *sched_class; 1245 struct sched_entity se; 1246 struct sched_rt_entity rt; 1247 #ifdef CONFIG_CGROUP_SCHED 1248 struct task_group *sched_task_group; 1249 #endif 1250 struct sched_dl_entity dl; 8.What are preempt notifiers and what are they for?(another stupid question) 9. Are these lines for the policy used and to block certain processes to only a few processors? 1261 unsigned int policy; 1262 int nr_cpus_allowed; 1263 cpumask_t cpus_allowed; 8.What are the options like CONFIG_PREEMPT_RCU used for in terms of workloads or locking as I heard a lot about them on the threads on the lkml? P.S. Sorry about some many questions,. Answer then whenever you guys have time and if there stupid and easily found somewhere let me known.
On 08/06/2014 03:11 PM, Nick Krause wrote:
I am new to kernel programming and have a lot questions about this structure. Also if after you guys reply I have a few \ questions for Greg Kroah Hartman about usb development and stable trees. I am very excited about learning this properly now and if anyone notices something wrong in my understanding please let me known :). Thanks So Much, Nick Questions about task_struct 1.volatile long state; Is this line like jiffies for timers with regards to the keyword volatile? 2.void *stack; Is this a pointer to the kernel stack for the process related to the process that the structure is keeping data for and is void to make it an opaque data type? Is this normally an int or some other data type when called with most processes? 3.unsigned int flags; /* per process flags, defined below */, My only question about this is what flags are there and are these the ifdef statements in the struct? 4.Why are we making the usage count atomic?(pretty obvious but real world reasons would be great) 5.I assume int ptrace is for ptrace or debugged processes? If I wrong please let me known too. 6. What is wakkee_flips and wakkee_flips_decay used for? 7.This is probably a stupid question but are these the scheduler cases for CFS? 1240 int on_rq; 1241 1242 int prio, static_prio, normal_prio; 1243 unsigned int rt_priority; 1244 const struct sched_class *sched_class; 1245 struct sched_entity se; 1246 struct sched_rt_entity rt; 1247 #ifdef CONFIG_CGROUP_SCHED 1248 struct task_group *sched_task_group; 1249 #endif 1250 struct sched_dl_entity dl; 8.What are preempt notifiers and what are they for?(another stupid question) 9. Are these lines for the policy used and to block certain processes to only a few processors? 1261 unsigned int policy; 1262 int nr_cpus_allowed; 1263 cpumask_t cpus_allowed; 8.What are the options like CONFIG_PREEMPT_RCU used for in terms of workloads or locking as I heard a lot about them on the threads on the lkml?
Go learn C first. BTW, We all know that you were here on the mailing list before with the name "James Bond". Now, its Nick Krause. You have irritated many guys before this. Unfortunately, changing the name wont change the attitude. I am pretty sure you will come back with a different name now. Dude, seriously. Stop it.!
P.S. Sorry about some many questions,. Answer then whenever you guys have time and if there stupid and easily found somewhere let me known.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Wed, Aug 6, 2014 at 6:23 PM, Venkatram Tummala <venkatram867@gmail.com> wrote:
On 08/06/2014 03:11 PM, Nick Krause wrote:
I am new to kernel programming and have a lot questions about this structure. Also if after you guys reply I have a few \ questions for Greg Kroah Hartman about usb development and stable trees. I am very excited about learning this properly now and if anyone notices something wrong in my understanding please let me known :). Thanks So Much, Nick Questions about task_struct 1.volatile long state; Is this line like jiffies for timers with regards to the keyword volatile? 2.void *stack; Is this a pointer to the kernel stack for the process related to the process that the structure is keeping data for and is void to make it an opaque data type? Is this normally an int or some other data type when called with most processes? 3.unsigned int flags; /* per process flags, defined below */, My only question about this is what flags are there and are these the ifdef statements in the struct? 4.Why are we making the usage count atomic?(pretty obvious but real world reasons would be great) 5.I assume int ptrace is for ptrace or debugged processes? If I wrong please let me known too. 6. What is wakkee_flips and wakkee_flips_decay used for? 7.This is probably a stupid question but are these the scheduler cases for CFS? 1240 int on_rq; 1241 1242 int prio, static_prio, normal_prio; 1243 unsigned int rt_priority; 1244 const struct sched_class *sched_class; 1245 struct sched_entity se; 1246 struct sched_rt_entity rt; 1247 #ifdef CONFIG_CGROUP_SCHED 1248 struct task_group *sched_task_group; 1249 #endif 1250 struct sched_dl_entity dl; 8.What are preempt notifiers and what are they for?(another stupid question) 9. Are these lines for the policy used and to block certain processes to only a few processors? 1261 unsigned int policy; 1262 int nr_cpus_allowed; 1263 cpumask_t cpus_allowed; 8.What are the options like CONFIG_PREEMPT_RCU used for in terms of workloads or locking as I heard a lot about them on the threads on the lkml?
Go learn C first.
BTW, We all know that you were here on the mailing list before with the name "James Bond". Now, its Nick Krause. You have irritated many guys before this. Unfortunately, changing the name wont change the attitude.
I am pretty sure you will come back with a different name now.
Dude, seriously. Stop it.!
P.S. Sorry about some many questions,. Answer then whenever you guys have time and if there stupid and easily found somewhere let me known.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
No I not coming back with another name, I would like my questions answered first. Nick
On Wed, Aug 6, 2014 at 6:23 PM, Venkatram Tummala <venkatram867@gmail.com> wrote:
Go learn C first.
I don't think you need to flame him like this. Atlast he asked a relevant question. Answer it if you have the patience or ignore him.
BTW, We all know that you were here on the mailing list before with the name "James Bond". Now, its Nick Krause. You have irritated many guys before this. Unfortunately, changing the name wont change the attitude.
If he is actually doing this, there is no point in replying to his emails. That is only giving him attention. Ignore and let him be (or ban him, which I think is not warranted _yet_). -- Andev
On Wed, Aug 6, 2014 at 8:26 PM, Andev <debiandev@gmail.com> wrote:
On Wed, Aug 6, 2014 at 6:23 PM, Venkatram Tummala <venkatram867@gmail.com> wrote:
Go learn C first.
I don't think you need to flame him like this. Atlast he asked a relevant question. Answer it if you have the patience or ignore him.
BTW, We all know that you were here on the mailing list before with the name "James Bond". Now, its Nick Krause. You have irritated many guys before this. Unfortunately, changing the name wont change the attitude.
If he is actually doing this, there is no point in replying to his emails. That is only giving him attention. Ignore and let him be (or ban him, which I think is not warranted _yet_).
-- Andev
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Andev, I want to thank you for standing up to me here and out I am not changing my email at all since I have started posting to the list so I am not trying to spam you guys. On the other hand due to waste of developer time I am banned from LKML, which is due to me not listening and I so deserve it for now. On the other hand I would like to work my way back up to being on the list again and helping out. Cheers Nick
On Wed, 06 Aug 2014 18:11:30 -0400, Nick Krause said:
1.volatile long state; Is this line like jiffies for timers with regards to the keyword volatile?
Why should it be any different?
2.void *stack; Is this a pointer to the kernel stack for the process related to the process that the structure is keeping data for and is void to make it an opaque data type? Is this normally an int or some other data type when called with most processes?
Under what conditions would it be an int? Think a bit.
3.unsigned int flags; /* per process flags, defined below */, My only question about this is what flags are there and are these the ifdef statements in the struct?
You explain what "ifdef statements in the struct" means, and maybe we'll be able to explain that to you..
4.Why are we making the usage count atomic?(pretty obvious but real world reasons would be great)
If you don't understand why usage and reference counts need to be atomic, you've got a *lot* to learn about race conditions.
8.What are the options like CONFIG_PREEMPT_RCU used for in terms of workloads or locking as I heard a lot about them on the threads on the lkml?
Start looking at Kconfig files. Most of them are documented.
On Thu, Aug 7, 2014 at 4:05 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 06 Aug 2014 18:11:30 -0400, Nick Krause said:
1.volatile long state; Is this line like jiffies for timers with regards to the keyword volatile?
Why should it be any different?
2.void *stack; Is this a pointer to the kernel stack for the process related to the process that the structure is keeping data for and is void to make it an opaque data type? Is this normally an int or some other data type when called with most processes?
Under what conditions would it be an int? Think a bit.
3.unsigned int flags; /* per process flags, defined below */, My only question about this is what flags are there and are these the ifdef statements in the struct?
You explain what "ifdef statements in the struct" means, and maybe we'll be able to explain that to you..
4.Why are we making the usage count atomic?(pretty obvious but real world reasons would be great)
If you don't understand why usage and reference counts need to be atomic, you've got a *lot* to learn about race conditions.
8.What are the options like CONFIG_PREEMPT_RCU used for in terms of workloads or locking as I heard a lot about them on the threads on the lkml?
Start looking at Kconfig files. Most of them are documented. Thanks Valdis, I was just curious if I was correct in my understanding of task struct, seems I am so far and yes I do known why we have reference counting, I was more curious about how to trace issues with this for debugging. Regards Nick
participants (4)
-
Andev -
Nick Krause -
Valdis.Kletnieks＠vt.edu -
Venkatram Tummala