Re: Doubt Regarding Floating Point Arithmetic
On Wed, Jul 23, 2014 at 08:45:54AM +0530, me storage wrote: > Hi > I am reading LDD .In that i didn't understand one point .In Chapter 2(Building > and Running Modules) they mentioned that > " Kernel code cannot do floating point arithmetic" > .My doubt is which code is used for floating point arithmetic that means at > low > level? I don't understand, what do you mean by this? You should not do any floating point math instructions within kernel code. That's all that is saying. Hope you like the book, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Doubt Regarding Floating Point Arithmetic
Hi I am reading LDD .In that i didn't understand one point .In Chapter 2(Building and Running Modules) they mentioned that " Kernel code cannot do floating point arithmetic" .My doubt is which code is used for floating point arithmetic that means at low level? Thank you ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: wait_event_* and wake_up_*
You may find this useful - http://www.makelinux.net/ldd3/chp-6-sect-2 -- Thanks, -Meraj On Wed, Jul 23, 2014 at 8:12 AM, Pranith Kumar wrote: > Hello, > > Could someone point me to good documentation about the wait_event_* > and wake_up_* event family APIs? > > I tried searching and nothing concrete shows up. > > In particular: > > When do we use wake_up_interruptible()? Does wake_up(wq) wake up all > the threads which are waiting on that work queue? Is the waking up of > threads sequential? > > That should suffice for now I guess :) > > Regards, > -- > Pranith > > ___ > 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
wait_event_* and wake_up_*
Hello, Could someone point me to good documentation about the wait_event_* and wake_up_* event family APIs? I tried searching and nothing concrete shows up. In particular: When do we use wake_up_interruptible()? Does wake_up(wq) wake up all the threads which are waiting on that work queue? Is the waking up of threads sequential? That should suffice for now I guess :) Regards, -- Pranith ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: usb serial programming
> Raspberry PI is not having a dedicated serial port but GPIO14 and > GPIO15 are the Rx and Tx pins , so you can just connect a max3232 to > have a serial port . I believe that requires some capacitors and possibly some electronics, so I ordered one ready-made from China for $3 including shipping. It's on its way. Slowly. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: usb serial programming
>> In fact, the dmesg above was with the ftdi modules loaded. > > You should get some kernel log messages when a new USB device is plugged > in, no matter what type it is. The fact that you are not is a problem. > > greg k-h Do you suppose this would work? http://www.amazon.com/gp/product/B006PIU2KO/ref=ox_sc_act_title_1?ie=UTF8&psc=1&smid=A3CTCSJRE9G6AY ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: question about kref API
On Tue, Jul 22, 2014 at 05:25:03PM +, Jeff Haran wrote:
> > -Original Message-
> > From: Greg KH [mailto:g...@kroah.com]
> > Sent: Monday, July 21, 2014 7:18 PM
> > To: Jeff Haran
> > Cc: kernelnewbies@kernelnewbies.org
> > Subject: Re: question about kref API
> >
> > On Tue, Jul 22, 2014 at 12:27:20AM +, Jeff Haran wrote:
> > > Hi,
> > >
> > > I've been reading Documentation/kref.txt in order to understand the
> > > usage of this API. There is part of this documentation that I am
> > > having difficulty understanding and was hoping somebody on this list
> > > could clarify this. One of my assumptions in reading this is that the
> > > expected usage of this API is that for a given object embedding a
> > > kref, once the object has been initialized the number of calls to
> > > "put" a given instance of an object should never exceed the number of
> > > calls to "get" that same instance.
> >
> > If it does, the object will be cleaned up and deleted from the system,
> > so you no longer have a valid pointer.
> >
> > > Maybe that's the root of my misunderstanding, but my assumption is
> > > that calls to kref_get() and kref_put() are expected to be made in
> > > pairs for a given instance of struct kref. If this is wrong, please
> > > let me know.
> >
> > "pairs" in that the same number must be called in order for things to
> > work properly.
> >
> > > Kref.txt includes some sample code that discusses using a mutex to
> > > serialize the execution of its get_entry() and put_entry() functions:
> > >
> > > 146 static DEFINE_MUTEX(mutex);
> > > 147 static LIST_HEAD(q);
> > > 148 struct my_data
> > > 149 {
> > > 150 struct kref refcount;
> > > 151 struct list_head link;
> > > 152 };
> > > 153
> > > 154 static struct my_data *get_entry()
> > > 155 {
> > > 156 struct my_data *entry = NULL;
> > > 157 mutex_lock(&mutex);
> > > 158 if (!list_empty(&q)) {
> > > 159 entry = container_of(q.next, struct my_data, link);
> > > 160 kref_get(&entry->refcount);
> > > 161 }
> > > 162 mutex_unlock(&mutex);
> > > 163 return entry;
> > > 164 }
> > > 165
> > > 166 static void release_entry(struct kref *ref)
> > > 167 {
> > > 168 struct my_data *entry = container_of(ref, struct my_data,
> > > refcount);
> > > 169
> > > 170 list_del(&entry->link);
> > > 171 kfree(entry);
> > > 172 }
> > > 173
> > > 174 static void put_entry(struct my_data *entry)
> > > 175 {
> > > 176 mutex_lock(&mutex);
> > > 177 kref_put(&entry->refcount, release_entry);
> > > 178 mutex_unlock(&mutex);
> > > 179 }
> > >
> > > The sample code does not show the creation of the link list headed by
> > > q,
> >
> > That is done there in the static initializer.
[meta comment, please properly wrap your lines...]
> You are referring to line 147 here, right? That creates an empty list
> if I am following the code correctly.
Yes.
> What I meant was that the sample code doesn't show how instances of
> struct my_data get initialized and inserted into the list at q. Makes
> sense to leave that out for brevity I suppose and you've made it clear
> below that for this to work right a call to kref_init() must have been
> made on the refcount fields of any struct my_data instances that got
> put into the list headed by q. Thanks.
Yes, that code is left as an exercise for the reader. Or you can just
look at the kernel where it is used in many places directly :)
> At this point it's rule (3) that I am still struggling with a bit:
>
> 50 3) If the code attempts to gain a reference to a kref-ed structure
> 51without already holding a valid pointer, it must serialize access
> 52where a kref_put() cannot occur during the kref_get(), and the
> 53structure must remain valid during the kref_get().
>
> In this example, every call to put_entry() results in locking and
> unlocking the mutex. But if I am following this right, that is only
> because the entry at the head of the list is removed from the list
> when and only when the last reference to it is released.
It has nothing to do with a list, don't get hung up on a list with a
kref, it's not needed, just used as an example here.
> If the list_del() happened for some other cause (say a timer expired
> or user space sent a message to delete the entry), then the taking of
> the mutex in put_entry() wouldn't be necessary, right?
No, it still would be.
> For instance, this would be valid, wouldn't it?
>
> static void release_entry(struct kref *ref)
> {
> struct my_data *entry = container_of(ref, struct my_data, refcount);
>
> kfree(entry);
> }
>
> static void put_entry(struct my_data *entry)
> {
> kref_put(&entry->refcount, release_entry);
> }
>
> static void del_entry(struct my_data *entry)
> {
> mutex_lock(&mutex);
> list_del(&entry->link);
> mutex_unlock(&mutex);
> put_entry(entry);
> }
Nope. Don't
Re: Path of network packet in kernel
Hi Anil, I had written TCP client (tcpc.c) and TCP server (tcps.c) programs for demo and testing purpose. Note : "./tcpc" is the application running under trace-cmd record command. If you want to record the kernel flow for application you can use # trace-cmd record -e all command. # trace-cmd report /* to see the output. */ See the man page of trace-cmd record for example for more details. Please find below link for more details how to filter the output. http://elinux.org/images/3/35/Kernelshark-tut-elc-2011.pdf -Anand Moon On Tuesday, July 22, 2014 4:51 PM, Anil Joshi wrote: Hi Anand, I did what you said but i am getting a strange output [root@machine0 Desktop]#ls cli trace.dat.cpu11 trace.dat.cpu2 trace.dat.cpu7 client.c trace.dat.cpu12 trace.dat.cpu3 trace.dat.cpu8 trace.dat.cpu0 trace.dat.cpu13 trace.dat.cpu4 trace.dat.cpu9 trace.dat.cpu1 trace.dat.cpu14 trace.dat.cpu5 trace.dat.cpu10 trace.dat.cpu15 trace.dat.cpu6 [root@hwcentos10 Desktop]# cat trace.dat.cpu cat: trace.dat.cpu: No such file or directory [root@machine0 Desktop]# cat trace.dat.cpu0 [root@machine0 Desktop]# tcpc client.c trace.dat.cpu1 -bash: tcpc: command not found why am i getting so much trace.dat.cpu files and tcpc command not found can you please help me out cli is the executable file for client ---Anil On Wed, Jul 16, 2014 at 12:27 AM, Anand Moon wrote: Hi Anil, > >You need to use "trace-cmd record" command and run you client. For example. > >I chose to write a tcp simple client server application. >Server running on remote machine listening on some port >I executed below command to connect to the server using trace-cmd record >Below command records all the event and function trace in the kernel, > >You can filter these function by passing "-e net:*" >this command will generate a report of all the function that kernel executed. >You can read the report afterwords. using trace-cmd report. > >#sudo trace-cmd record -e all ./tcpc 10.0.0.28 >#ls >#tcpc tcpc.c trace.dat >#trace-cmd report > >You can also user perf command to trace the kernel functions. > >#sudo perf record -e probe:tcp_sendmsg > >#perf report > >perf examples can be found below. > >http://www.brendangregg.com/perf.html > >-Anand Moon > > > > > > >On Tuesday, July 15, 2014 10:34 PM, Jeff Haran wrote: > > > >This helps me to see the forest for the trees. And it’s pretty current: > >http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg > >Jeff Haran > > >From:kernelnewbies-boun...@kernelnewbies.org >[mailto:kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Anil Joshi >Sent: Tuesday, July 15, 2014 7:38 AM >To: kernelnewbies >Subject: Path of network packet in kernel > >Hi All, > >I am just new to all this,just wanted to trace the path of the packet since it >enter the system(inside the kernel (functions and system calls)) and reaches >the destination application. > >How to do that. > > >Regards > > > >___ >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___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: question about kref API
> -Original Message-
> From: Greg KH [mailto:g...@kroah.com]
> Sent: Monday, July 21, 2014 7:18 PM
> To: Jeff Haran
> Cc: kernelnewbies@kernelnewbies.org
> Subject: Re: question about kref API
>
> On Tue, Jul 22, 2014 at 12:27:20AM +, Jeff Haran wrote:
> > Hi,
> >
> > I've been reading Documentation/kref.txt in order to understand the
> > usage of this API. There is part of this documentation that I am
> > having difficulty understanding and was hoping somebody on this list
> > could clarify this. One of my assumptions in reading this is that the
> > expected usage of this API is that for a given object embedding a
> > kref, once the object has been initialized the number of calls to
> > "put" a given instance of an object should never exceed the number of
> > calls to "get" that same instance.
>
> If it does, the object will be cleaned up and deleted from the system,
> so you no longer have a valid pointer.
>
> > Maybe that's the root of my misunderstanding, but my assumption is
> > that calls to kref_get() and kref_put() are expected to be made in
> > pairs for a given instance of struct kref. If this is wrong, please
> > let me know.
>
> "pairs" in that the same number must be called in order for things to
> work properly.
>
> > Kref.txt includes some sample code that discusses using a mutex to
> > serialize the execution of its get_entry() and put_entry() functions:
> >
> > 146 static DEFINE_MUTEX(mutex);
> > 147 static LIST_HEAD(q);
> > 148 struct my_data
> > 149 {
> > 150 struct kref refcount;
> > 151 struct list_head link;
> > 152 };
> > 153
> > 154 static struct my_data *get_entry()
> > 155 {
> > 156 struct my_data *entry = NULL;
> > 157 mutex_lock(&mutex);
> > 158 if (!list_empty(&q)) {
> > 159 entry = container_of(q.next, struct my_data, link);
> > 160 kref_get(&entry->refcount);
> > 161 }
> > 162 mutex_unlock(&mutex);
> > 163 return entry;
> > 164 }
> > 165
> > 166 static void release_entry(struct kref *ref)
> > 167 {
> > 168 struct my_data *entry = container_of(ref, struct my_data,
> > refcount);
> > 169
> > 170 list_del(&entry->link);
> > 171 kfree(entry);
> > 172 }
> > 173
> > 174 static void put_entry(struct my_data *entry)
> > 175 {
> > 176 mutex_lock(&mutex);
> > 177 kref_put(&entry->refcount, release_entry);
> > 178 mutex_unlock(&mutex);
> > 179 }
> >
> > The sample code does not show the creation of the link list headed by
> > q,
>
> That is done there in the static initializer.
You are referring to line 147 here, right? That creates an empty list if I am
following the code correctly. What I meant was that the sample code doesn't
show how instances of struct my_data get initialized and inserted into the list
at q. Makes sense to leave that out for brevity I suppose and you've made it
clear below that for this to work right a call to kref_init() must have been
made on the refcount fields of any struct my_data instances that got put into
the list headed by q. Thanks.
> > so it is unclear to me what the value of the reference counts in
> > these my_data structures are at the time they are enqueued to the
> > list. Put another way, it's not clear to me from reading this whether
> > kref_init(&(entry->refcount)) was called before the instances of
> > struct my_data were put into the list.
>
> Yes it was.
>
> > So I have two interpretations of what is being illustrated with this
> > sample code and neither makes much sense to me.
> >
> > 1) The krefs are initialized before they go into the list.
>
> Yes.
>
> > If the krefs in the instances of struct my_data are initialized by
> > kref_init() before they go into the list and thus start off with a 1,
> > then it would seem to me that the mutex would not be necessary so long
> > as the number of calls to put_entry() never exceeds the number of
> > calls to get_entry().
>
> The mutex is needed as multiple threads could be calling kref_put at the
> same time if you don't have that.
>
> Best thing is, don't use the "raw" kref_put() calls, use the
> kref_put_mutex() or kref_put_spinlock_irqsave() call instead. It's much
> easier that way and arguably, I should have done that when I created the
> API over a decade ago.
>
At this point it's rule (3) that I am still struggling with a bit:
50 3) If the code attempts to gain a reference to a kref-ed structure
51without already holding a valid pointer, it must serialize access
52where a kref_put() cannot occur during the kref_get(), and the
53structure must remain valid during the kref_get().
In this example, every call to put_entry() results in locking and unlocking the
mutex. But if I am following this right, that is only because the entry at the
head of the list is removed from the list when and only when the last reference
to it is released. If the list_del() happened for some other cause (say a time
Re: Confused by function names cpuidle_install_idle_handler/cpuidle_uninstall_idle_handler
Hi Meraj,
Look at the condition where they are called,
If they justify the meaning of the functions
it's ok to keep the name as it is.
Other wise if you have alternate name for these functions,
just send a patch to the maintainers of the code changes.
-Anand Moon
On Tuesday, July 22, 2014 8:38 PM, Mohammad Merajul Islam Molla
wrote:
Hi Anand,
Thanks for your reply. I looked up the patch.
Question:
Should these functions be renamed now that they don't
do what they used to do earlier?
--
Thanks,
-Meraj
On Tue, Jul 22, 2014 at 8:43 PM, Anand Moon wrote:
> Hi Meraj,
>
> Please look at the following commit this will help clear you confusion
>
> git commit id : a0bfa1373859e9d11dc92561a8667588803e42d8
>
>
> patch :0001-cpuidle-stop-depending-on-pm_idle.patch
>
> To generate following patch:
>
> #git format-patch -1 a0bfa1373859e9d11dc92561a8667588803e42d8
>
> 0001-cpuidle-stop-depending-on-pm_idle.patch
>
>
> -Anand Moon
>
>
> On Tuesday, July 22, 2014 7:28 PM, Mohammad Merajul Islam Molla
> wrote:
> Hello,
>
> As mentioned, the code excerpt was from kernel version 3.0.
>
> In recent kernel (version 3.16.0-rc4), the code for the two mentioned
> functions looks as below -
>
> /**
> * cpuidle_install_idle_handler - installs the cpuidle idle loop handler
> */
> void cpuidle_install_idle_handler(void)
> {
> if (enabled_devices) {
> /* Make sure all changes finished before we switch to
> new idle */
> smp_wmb();
> initialized = 1;
> }
> }
>
> /**
> * cpuidle_uninstall_idle_handler - uninstalls the cpuidle idle loop
> handler
> */
> void cpuidle_uninstall_idle_handler(void)
> {
> if (enabled_devices) {
> initialized = 0;
> kick_all_cpus_sync();
> }
> }
>
>
> That is the source of confusion. There is no pm_idle handler installed
> (or uninstalled) anymore.
>
> --
> Thanks,
> -Meraj
>
>
>
>
>
>
> On Tue, Jul 22, 2014 at 4:54 PM, Mulyadi Santosa
> wrote:
>> On Fri, Jul 18, 2014 at 11:07 PM, Mohammad Merajul Islam Molla
>> wrote:
>>> Hello,
>>>
>>> In drivers/cpuidle/cpuidle.c, there are two functions
>>> cpuidle_install_idle_handler & cpuidle_uninstall_idle_handler. The
>>> names seem confusing to me as they don't install any handler, rather
>>> set 'initialized' variable to 1/0.
>>>
>>> In v3.0 kernel, these functions used to look as below where they
>>> installed and uninstalled some handler function -
>>>
>>> void cpuidle_install_idle_handler(void)
>>> 123 {
>>> 124 if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
>>> 125 /* Make sure all changes finished before we switch
>>> to new idle */
>>> 126 smp_wmb();
>>> 127 pm_idle = cpuidle_idle_call;
>> ^
>> pm_idle is the callback handler, and it is assigned to
>> cpuidle_idle_call. I think this what it means by "install"
>>
>>
>> --
>> regards,
>>
>> Mulyadi Santosa
>> Freelance Linux trainer and consultant
>>
>> blog: the-hydra.blogspot.com
>> training: mulyaditraining.blogspot.com
>
> ___
> 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
Re: Confused by function names cpuidle_install_idle_handler/cpuidle_uninstall_idle_handler
Hi Anand,
Thanks for your reply. I looked up the patch.
Question:
Should these functions be renamed now that they don't
do what they used to do earlier?
--
Thanks,
-Meraj
On Tue, Jul 22, 2014 at 8:43 PM, Anand Moon wrote:
> Hi Meraj,
>
> Please look at the following commit this will help clear you confusion
>
> git commit id : a0bfa1373859e9d11dc92561a8667588803e42d8
>
>
> patch :0001-cpuidle-stop-depending-on-pm_idle.patch
>
> To generate following patch:
>
> #git format-patch -1 a0bfa1373859e9d11dc92561a8667588803e42d8
>
> 0001-cpuidle-stop-depending-on-pm_idle.patch
>
>
> -Anand Moon
>
>
> On Tuesday, July 22, 2014 7:28 PM, Mohammad Merajul Islam Molla
> wrote:
> Hello,
>
> As mentioned, the code excerpt was from kernel version 3.0.
>
> In recent kernel (version 3.16.0-rc4), the code for the two mentioned
> functions looks as below -
>
> /**
> * cpuidle_install_idle_handler - installs the cpuidle idle loop handler
> */
> void cpuidle_install_idle_handler(void)
> {
> if (enabled_devices) {
> /* Make sure all changes finished before we switch to
> new idle */
> smp_wmb();
> initialized = 1;
> }
> }
>
> /**
> * cpuidle_uninstall_idle_handler - uninstalls the cpuidle idle loop
> handler
> */
> void cpuidle_uninstall_idle_handler(void)
> {
> if (enabled_devices) {
> initialized = 0;
> kick_all_cpus_sync();
> }
> }
>
>
> That is the source of confusion. There is no pm_idle handler installed
> (or uninstalled) anymore.
>
> --
> Thanks,
> -Meraj
>
>
>
>
>
>
> On Tue, Jul 22, 2014 at 4:54 PM, Mulyadi Santosa
> wrote:
>> On Fri, Jul 18, 2014 at 11:07 PM, Mohammad Merajul Islam Molla
>> wrote:
>>> Hello,
>>>
>>> In drivers/cpuidle/cpuidle.c, there are two functions
>>> cpuidle_install_idle_handler & cpuidle_uninstall_idle_handler. The
>>> names seem confusing to me as they don't install any handler, rather
>>> set 'initialized' variable to 1/0.
>>>
>>> In v3.0 kernel, these functions used to look as below where they
>>> installed and uninstalled some handler function -
>>>
>>> void cpuidle_install_idle_handler(void)
>>> 123 {
>>> 124 if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
>>> 125 /* Make sure all changes finished before we switch
>>> to new idle */
>>> 126 smp_wmb();
>>> 127 pm_idle = cpuidle_idle_call;
>> ^
>> pm_idle is the callback handler, and it is assigned to
>> cpuidle_idle_call. I think this what it means by "install"
>>
>>
>> --
>> regards,
>>
>> Mulyadi Santosa
>> Freelance Linux trainer and consultant
>>
>> blog: the-hydra.blogspot.com
>> training: mulyaditraining.blogspot.com
>
> ___
> 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
Re: Confused by function names cpuidle_install_idle_handler/cpuidle_uninstall_idle_handler
Hi Meraj,
Please look at the following commit this will help clear you confusion
git commit id : a0bfa1373859e9d11dc92561a8667588803e42d8
patch :0001-cpuidle-stop-depending-on-pm_idle.patch
To generate following patch:
#git format-patch -1 a0bfa1373859e9d11dc92561a8667588803e42d8
0001-cpuidle-stop-depending-on-pm_idle.patch
-Anand Moon
On Tuesday, July 22, 2014 7:28 PM, Mohammad Merajul Islam Molla
wrote:
Hello,
As mentioned, the code excerpt was from kernel version 3.0.
In recent kernel (version 3.16.0-rc4), the code for the two mentioned
functions looks as below -
/**
* cpuidle_install_idle_handler - installs the cpuidle idle loop handler
*/
void cpuidle_install_idle_handler(void)
{
if (enabled_devices) {
/* Make sure all changes finished before we switch to
new idle */
smp_wmb();
initialized = 1;
}
}
/**
* cpuidle_uninstall_idle_handler - uninstalls the cpuidle idle loop
handler
*/
void cpuidle_uninstall_idle_handler(void)
{
if (enabled_devices) {
initialized = 0;
kick_all_cpus_sync();
}
}
That is the source of confusion. There is no pm_idle handler installed
(or uninstalled) anymore.
--
Thanks,
-Meraj
On Tue, Jul 22, 2014 at 4:54 PM, Mulyadi Santosa
wrote:
> On Fri, Jul 18, 2014 at 11:07 PM, Mohammad Merajul Islam Molla
> wrote:
>> Hello,
>>
>> In drivers/cpuidle/cpuidle.c, there are two functions
>> cpuidle_install_idle_handler & cpuidle_uninstall_idle_handler. The
>> names seem confusing to me as they don't install any handler, rather
>> set 'initialized' variable to 1/0.
>>
>> In v3.0 kernel, these functions used to look as below where they
>> installed and uninstalled some handler function -
>>
>> void cpuidle_install_idle_handler(void)
>> 123 {
>> 124 if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
>> 125 /* Make sure all changes finished before we switch
>> to new idle */
>> 126 smp_wmb();
>> 127 pm_idle = cpuidle_idle_call;
> ^
> pm_idle is the callback handler, and it is assigned to
> cpuidle_idle_call. I think this what it means by "install"
>
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
___
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
Re: Confused by function names cpuidle_install_idle_handler/cpuidle_uninstall_idle_handler
Hello,
As mentioned, the code excerpt was from kernel version 3.0.
In recent kernel (version 3.16.0-rc4), the code for the two mentioned
functions looks as below -
/**
* cpuidle_install_idle_handler - installs the cpuidle idle loop handler
*/
void cpuidle_install_idle_handler(void)
{
if (enabled_devices) {
/* Make sure all changes finished before we switch to
new idle */
smp_wmb();
initialized = 1;
}
}
/**
* cpuidle_uninstall_idle_handler - uninstalls the cpuidle idle loop
handler
*/
void cpuidle_uninstall_idle_handler(void)
{
if (enabled_devices) {
initialized = 0;
kick_all_cpus_sync();
}
}
That is the source of confusion. There is no pm_idle handler installed
(or uninstalled) anymore.
--
Thanks,
-Meraj
On Tue, Jul 22, 2014 at 4:54 PM, Mulyadi Santosa
wrote:
> On Fri, Jul 18, 2014 at 11:07 PM, Mohammad Merajul Islam Molla
> wrote:
>> Hello,
>>
>> In drivers/cpuidle/cpuidle.c, there are two functions
>> cpuidle_install_idle_handler & cpuidle_uninstall_idle_handler. The
>> names seem confusing to me as they don't install any handler, rather
>> set 'initialized' variable to 1/0.
>>
>> In v3.0 kernel, these functions used to look as below where they
>> installed and uninstalled some handler function -
>>
>> void cpuidle_install_idle_handler(void)
>> 123 {
>> 124 if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
>> 125 /* Make sure all changes finished before we switch
>> to new idle */
>> 126 smp_wmb();
>> 127 pm_idle = cpuidle_idle_call;
> ^
> pm_idle is the callback handler, and it is assigned to
> cpuidle_idle_call. I think this what it means by "install"
>
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Path of network packet in kernel
Hi Anand, I did what you said but i am getting a strange output [root@machine0 Desktop]#ls cli trace.dat.cpu11 trace.dat.cpu2 trace.dat.cpu7 client.c trace.dat.cpu12 trace.dat.cpu3 trace.dat.cpu8 trace.dat.cpu0 trace.dat.cpu13 trace.dat.cpu4 trace.dat.cpu9 trace.dat.cpu1 trace.dat.cpu14 trace.dat.cpu5 trace.dat.cpu10 trace.dat.cpu15 trace.dat.cpu6 [root@hwcentos10 Desktop]# cat trace.dat.cpu cat: trace.dat.cpu: No such file or directory [root@machine0 Desktop]# cat trace.dat.cpu0 [root@machine0 Desktop]# tcpc client.c trace.dat.cpu1 -bash: tcpc: command not found why am i getting so much trace.dat.cpu files and tcpc command not found can you please help me out cli is the executable file for client ---Anil On Wed, Jul 16, 2014 at 12:27 AM, Anand Moon wrote: > Hi Anil, > > You need to use "trace-cmd record" command and run you client. For example. > > I chose to write a tcp simple client server application. > Server running on remote machine listening on some port > I executed below command to connect to the server using trace-cmd record > Below command records all the event and function trace in the kernel, > > You can filter these function by passing "-e net:*" > this command will generate a report of all the function that kernel > executed. > You can read the report afterwords. using trace-cmd report. > > #sudo trace-cmd record -e all ./tcpc 10.0.0.28 > #ls > #tcpc tcpc.c trace.dat > #trace-cmd report > > You can also user perf command to trace the kernel functions. > > #sudo perf record -e probe:tcp_sendmsg > > #perf report > > perf examples can be found below. > > http://www.brendangregg.com/perf.html > > -Anand Moon > > > > > > On Tuesday, July 15, 2014 10:34 PM, Jeff Haran > wrote: > > > > This helps me to see the forest for the trees. And it’s pretty current: > > > http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg > > Jeff Haran > > > From:kernelnewbies-boun...@kernelnewbies.org [mailto: > kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Anil Joshi > Sent: Tuesday, July 15, 2014 7:38 AM > To: kernelnewbies > Subject: Path of network packet in kernel > > Hi All, > > I am just new to all this,just wanted to trace the path of the packet > since it enter the system(inside the kernel (functions and system calls)) > and reaches the destination application. > > How to do that. > > > Regards > > > ___ > 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
Re: Confused by function names cpuidle_install_idle_handler/cpuidle_uninstall_idle_handler
On Fri, Jul 18, 2014 at 11:07 PM, Mohammad Merajul Islam Molla
wrote:
> Hello,
>
> In drivers/cpuidle/cpuidle.c, there are two functions
> cpuidle_install_idle_handler & cpuidle_uninstall_idle_handler. The
> names seem confusing to me as they don't install any handler, rather
> set 'initialized' variable to 1/0.
>
> In v3.0 kernel, these functions used to look as below where they
> installed and uninstalled some handler function -
>
> void cpuidle_install_idle_handler(void)
> 123 {
> 124 if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
> 125 /* Make sure all changes finished before we switch
> to new idle */
> 126 smp_wmb();
> 127 pm_idle = cpuidle_idle_call;
^
pm_idle is the callback handler, and it is assigned to
cpuidle_idle_call. I think this what it means by "install"
--
regards,
Mulyadi Santosa
Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
