voipmonitor / sniffer

VoIPmonitor sniffer sources
226 stars 105 forks source link

Added option interrupts_counters_stats Default - yes #87

Closed konstantin-sancom closed 2 years ago

konstantin-sancom commented 2 years ago

Enable/disable interrupts stats, default yes On virtuozzo/openVZ containers is not possible and should be disabled - set to no

milon21 commented 2 years ago

Hello,

can you describe more precisely what's the problem with reading /proc/interrupts file in virtuozzo/openVZ containers ?

Thanks.

konstantin-sancom commented 2 years ago

Hello,

can you describe more precisely what's the problem with reading /proc/interrupts file in virtuozzo/openVZ containers ?

Thanks.

This part of /proc file system is not present inside of runing container.

milon21 commented 2 years ago

Okay, we will accept it. But please move the condition into get_interrupts_counters to be consistent if some other usage of this function happen. Or should I do it for you ?

konstantin-sancom commented 2 years ago

Okay, we will accept it. But please move the condition into get_interrupts_counters to be consistent if some other usage of this function happen. Or should I do it for you ?

It's Ok. I'll do it and commit.

konstantin-sancom commented 2 years ago

Okay, we will accept it. But please move the condition into get_interrupts_counters to be consistent if some other usage of this function happen. Or should I do it for you ?

Done. https://github.com/voipmonitor/sniffer/pull/87/commits/e56bdf3ded4ac80d485a4a228b3b4d9929d8a43b

milon21 commented 2 years ago

Okay, it's in our develop tree. I did rebase, adjusted the commit message a little and renamed the option name (our main dev wanted it).

konstantin-sancom commented 2 years ago

Okay, it's in our develop tree. I did rebase, adjusted the commit message a little and renamed the option name (our main dev wanted it).

Ok. Is there a "policy" how options should be named? We want to be under it and make things easier in future. Also, where is "develop" tree? Can I clone it to base all our future patch on it's code or "policy" is to always base patches on "master" branch?

milon21 commented 2 years ago

No, there is no policy for option naming. The develop tree is our internal development tree and is not accessible from the outside. We don't use github as development platform. We use it only as an export for reviews, etc. So it's fine to send patches based on master branch.

konstantin-sancom commented 2 years ago

No, there is no policy for option naming. The develop tree is our internal development tree and is not accessible from the outside. We don't use github as development platform. We use it only as an export for reviews, etc. So it's fine to send patches based on master branch.

Ok. I see now. Thanks! So, now I can simply close our pull requests(here a re two of them) or leave them opened and they will be merged in the future?

milon21 commented 2 years ago

You can close it. It's merged through our develop tree and you will see it in our next release.