Menu
▾
▴
hyperic-hq-discuss
|
From: Doug M. <dma...@vm...> - 2011-03-02 22:19:50
|
Hi Adam,
Thanks for the patches!
I need to take a closer look, but wondering if we could change sigar_net_interface_config_get rather than change the return values of sigar_net_interface_list:
sigar_net_interface_config_get("ethX", &config);
Then either change the value of config.description to use FriendlyName, or even add a new field to sigar_net_interface_config_t?
Thanks,
-Doug
On Feb 28, 2011, at 7:48 AM, Adam Stokes wrote:
> Hi,
>
> I'm Adam, one of the developers for matahari project (http://github.com/matahari). We are attempting to provide some useful apis over a remote interface (qpid.apache.org) that is cross platform.
>
> The resources used for cross compilation is mingw32. The first patch is for allowing sigar to compile successfully under those requirements.
>
> Some of the routines in the api (specifically network) we expose the ability to start/stop network interfaces through Windows netsh application. With the current sigar implementation interfaces are listed as 'ethX' which is fine when doing read only within the realm of sigar. When attempting to branch out and use application such as netsh in conjunction with sigar this fails due to netsh requiring a Friendly Name of the network interface. The second patch allows us to capture the interfaces friendlyname and at worst its interface description.
>
>
> The pull request can be found here,
>
> https://github.com/hyperic/sigar/pull/5
>
> Thank you
> Adam
>
>
|
|
From: Adam S. <aj...@re...> - 2011-03-21 13:23:29
|
----- Original Message -----
> On Wed, Mar 2, 2011 at 10:54 PM, Doug MacEachern
> <dma...@vm...> wrote:
> > Hi Adam,
> >
> > Thanks for the patches!
> > I need to take a closer look, but wondering if we could change
> > sigar_net_interface_config_get rather than change the return values
> > of sigar_net_interface_list:
> > sigar_net_interface_config_get("ethX", &config);
>
> Until recently I probably would have agreed with you, however given
> the recent shift away from ethX even on Linux, I'm not convinced that
> it makes sense to continue using it on Windows where it has no real
> meaning. Worse, the number of ethX entries does not even match the
> number of physical devices (there are two additional "pseudo devices"
> for every physical one).
>
> The other issue is that anything wanting to present network
> information to users must do the translation - again, since ethX is
> meaningless on Windows.
>
> So I guess my answer here is, "yes we could and if you insist we will,
> but I really don't think we should" :-)
>
Hi Doug,
Just a quick ping to see what your thoughts were on the patch?
Thanks!
--
__ __
.-----.| |_.-----.| |--.-----.-----.
|__ --|| _| _ || <| -__|__ --|
|_____||____|_____||__|__|_____|_____|
.----------------------------------.
( aj...@re... || 919.754.4187 )
`----------------------------------'
|
|
From: Doug M. <dma...@vm...> - 2011-04-08 16:24:33
|
Hey Guys,
Apologies for the long delay..
On Mar 9, 2011, at 1:41 AM, Andrew Beekhof wrote:
> On Wed, Mar 2, 2011 at 10:54 PM, Doug MacEachern <dma...@vm...> wrote:
>> Hi Adam,
>>
>> Thanks for the patches!
>> I need to take a closer look, but wondering if we could change sigar_net_interface_config_get rather than change the return values of sigar_net_interface_list:
>> sigar_net_interface_config_get("ethX", &config);
>
> Until recently I probably would have agreed with you, however given
> the recent shift away from ethX even on Linux, I'm not convinced that
> it makes sense to continue using it on Windows where it has no real
> meaning. Worse, the number of ethX entries does not even match the
> number of physical devices (there are two additional "pseudo devices"
> for every physical one).
>
> The other issue is that anything wanting to present network
> information to users must do the translation - again, since ethX is
> meaningless on Windows.
>
> So I guess my answer here is, "yes we could and if you insist we will,
> but I really don't think we should" :-)
I think your change is the right way to go for the long term. I just had current users in mind where this change may have an unexpected impact. In Hyperic HQ for example, ethX is used a the service name, so I believe this change would end up creating a new set of services there and the old ethX ones would just be stale. But, that's something that can be worked out.. we can leave the 1.6 branch as is and apply your changes to master/1.7.
I'm just now trying out your patches, but it doesn't compile for me using VC 2005. I haven't looked into it yet, does it build for you with VC?
Thanks,
-Doug
>
>>
>> Then either change the value of config.description to use FriendlyName, or even add a new field to sigar_net_interface_config_t?
>>
>> Thanks,
>> -Doug
>>
>> On Feb 28, 2011, at 7:48 AM, Adam Stokes wrote:
>>
>>> Hi,
>>>
>>> I'm Adam, one of the developers for matahari project (http://github.com/matahari). We are attempting to provide some useful apis over a remote interface (qpid.apache.org) that is cross platform.
>>>
>>> The resources used for cross compilation is mingw32. The first patch is for allowing sigar to compile successfully under those requirements.
>>>
>>> Some of the routines in the api (specifically network) we expose the ability to start/stop network interfaces through Windows netsh application. With the current sigar implementation interfaces are listed as 'ethX' which is fine when doing read only within the realm of sigar. When attempting to branch out and use application such as netsh in conjunction with sigar this fails due to netsh requiring a Friendly Name of the network interface. The second patch allows us to capture the interfaces friendlyname and at worst its interface description.
>>>
>>>
>>> The pull request can be found here,
>>>
>>> https://github.com/hyperic/sigar/pull/5
>>>
>>> Thank you
>>> Adam
>>>
>>>
>>
>>
|
|
From: Andrew B. <abe...@re...> - 2011-04-11 20:20:48
|
On 04/08/2011 06:24 PM, Doug MacEachern wrote:
> Hey Guys,
>
> Apologies for the long delay..
>
> On Mar 9, 2011, at 1:41 AM, Andrew Beekhof wrote:
>
>> On Wed, Mar 2, 2011 at 10:54 PM, Doug MacEachern<dma...@vm...> wrote:
>>> Hi Adam,
>>>
>>> Thanks for the patches!
>>> I need to take a closer look, but wondering if we could change sigar_net_interface_config_get rather than change the return values of sigar_net_interface_list:
>>> sigar_net_interface_config_get("ethX",&config);
>>
>> Until recently I probably would have agreed with you, however given
>> the recent shift away from ethX even on Linux, I'm not convinced that
>> it makes sense to continue using it on Windows where it has no real
>> meaning. Worse, the number of ethX entries does not even match the
>> number of physical devices (there are two additional "pseudo devices"
>> for every physical one).
>>
>> The other issue is that anything wanting to present network
>> information to users must do the translation - again, since ethX is
>> meaningless on Windows.
>>
>> So I guess my answer here is, "yes we could and if you insist we will,
>> but I really don't think we should" :-)
>
> I think your change is the right way to go for the long term. I just had current users in mind where this change may have an unexpected impact. In Hyperic HQ for example, ethX is used a the service name, so I believe this change would end up creating a new set of services there and the old ethX ones would just be stale. But, that's something that can be worked out.. we can leave the 1.6 branch as is and apply your changes to master/1.7.
>
> I'm just now trying out your patches, but it doesn't compile for me using VC 2005. I haven't looked into it yet, does it build for you with VC?
We don't have access to VC, we've been using mingw32 instead.
But if you let us know what the errors are we'll do our best to fix them.
|
|
From: Doug M. <dma...@vm...> - 2011-04-11 21:11:11
|
Hi Andrew,
ok, no problem, I have it building with the ms compiler now.
sigar_net_interface_name_get is declared extern, do you need that outside of the sigar library or can I make it static?
+SIGAR_DECLARE(char *)
+sigar_net_interface_name_get(sigar_t *sigar, MIB_IFROW *ifr)
I'd also like to make PIP_ADAPTER_ADDRESSES an input to that function so we can avoid calling sigar_new each time.
-Doug
On Apr 11, 2011, at 4:44 AM, Andrew Beekhof wrote:
> On 04/08/2011 06:24 PM, Doug MacEachern wrote:
>> Hey Guys,
>>
>> Apologies for the long delay..
>>
>> On Mar 9, 2011, at 1:41 AM, Andrew Beekhof wrote:
>>
>>> On Wed, Mar 2, 2011 at 10:54 PM, Doug MacEachern<dma...@vm...> wrote:
>>>> Hi Adam,
>>>>
>>>> Thanks for the patches!
>>>> I need to take a closer look, but wondering if we could change sigar_net_interface_config_get rather than change the return values of sigar_net_interface_list:
>>>> sigar_net_interface_config_get("ethX",&config);
>>>
>>> Until recently I probably would have agreed with you, however given
>>> the recent shift away from ethX even on Linux, I'm not convinced that
>>> it makes sense to continue using it on Windows where it has no real
>>> meaning. Worse, the number of ethX entries does not even match the
>>> number of physical devices (there are two additional "pseudo devices"
>>> for every physical one).
>>>
>>> The other issue is that anything wanting to present network
>>> information to users must do the translation - again, since ethX is
>>> meaningless on Windows.
>>>
>>> So I guess my answer here is, "yes we could and if you insist we will,
>>> but I really don't think we should" :-)
>>
>> I think your change is the right way to go for the long term. I just had current users in mind where this change may have an unexpected impact. In Hyperic HQ for example, ethX is used a the service name, so I believe this change would end up creating a new set of services there and the old ethX ones would just be stale. But, that's something that can be worked out.. we can leave the 1.6 branch as is and apply your changes to master/1.7.
>>
>> I'm just now trying out your patches, but it doesn't compile for me using VC 2005. I haven't looked into it yet, does it build for you with VC?
>
> We don't have access to VC, we've been using mingw32 instead.
> But if you let us know what the errors are we'll do our best to fix them.
|
|
From: Andrew B. <abe...@re...> - 2011-04-12 08:07:57
|
On 04/11/2011 11:11 PM, Doug MacEachern wrote:
> Hi Andrew,
>
> ok, no problem, I have it building with the ms compiler now.
Great
> sigar_net_interface_name_get is declared extern, do you need that outside of the sigar library or can I make it static?
We're not using it explicitly, so static should be fine.
>
> +SIGAR_DECLARE(char *)
> +sigar_net_interface_name_get(sigar_t *sigar, MIB_IFROW *ifr)
>
> I'd also like to make PIP_ADAPTER_ADDRESSES an input to that function so we can avoid calling sigar_new each time.
Sure. That makes sense. Just be careful how ifconf_buf is used - that
had us guess for a bit.
Do you want us to work on this or have you got it under control?
> -Doug
>
> On Apr 11, 2011, at 4:44 AM, Andrew Beekhof wrote:
>
>> On 04/08/2011 06:24 PM, Doug MacEachern wrote:
>>> Hey Guys,
>>>
>>> Apologies for the long delay..
>>>
>>> On Mar 9, 2011, at 1:41 AM, Andrew Beekhof wrote:
>>>
>>>> On Wed, Mar 2, 2011 at 10:54 PM, Doug MacEachern<dma...@vm...> wrote:
>>>>> Hi Adam,
>>>>>
>>>>> Thanks for the patches!
>>>>> I need to take a closer look, but wondering if we could change sigar_net_interface_config_get rather than change the return values of sigar_net_interface_list:
>>>>> sigar_net_interface_config_get("ethX",&config);
>>>>
>>>> Until recently I probably would have agreed with you, however given
>>>> the recent shift away from ethX even on Linux, I'm not convinced that
>>>> it makes sense to continue using it on Windows where it has no real
>>>> meaning. Worse, the number of ethX entries does not even match the
>>>> number of physical devices (there are two additional "pseudo devices"
>>>> for every physical one).
>>>>
>>>> The other issue is that anything wanting to present network
>>>> information to users must do the translation - again, since ethX is
>>>> meaningless on Windows.
>>>>
>>>> So I guess my answer here is, "yes we could and if you insist we will,
>>>> but I really don't think we should" :-)
>>>
>>> I think your change is the right way to go for the long term. I just had current users in mind where this change may have an unexpected impact. In Hyperic HQ for example, ethX is used a the service name, so I believe this change would end up creating a new set of services there and the old ethX ones would just be stale. But, that's something that can be worked out.. we can leave the 1.6 branch as is and apply your changes to master/1.7.
>>>
>>> I'm just now trying out your patches, but it doesn't compile for me using VC 2005. I haven't looked into it yet, does it build for you with VC?
>>
>> We don't have access to VC, we've been using mingw32 instead.
>> But if you let us know what the errors are we'll do our best to fix them.
>
|
|
From: Doug M. <dma...@vm...> - 2011-04-12 21:16:57
|
On Apr 12, 2011, at 1:07 AM, Andrew Beekhof wrote:
> On 04/11/2011 11:11 PM, Doug MacEachern wrote:
>> Hi Andrew,
>>
>> ok, no problem, I have it building with the ms compiler now.
>
> Great
>
>> sigar_net_interface_name_get is declared extern, do you need that outside of the sigar library or can I make it static?
>
> We're not using it explicitly, so static should be fine.
ok, cool.
>
>>
>> +SIGAR_DECLARE(char *)
>> +sigar_net_interface_name_get(sigar_t *sigar, MIB_IFROW *ifr)
>>
>> I'd also like to make PIP_ADAPTER_ADDRESSES an input to that function so we can avoid calling sigar_new each time.
>
> Sure. That makes sense. Just be careful how ifconf_buf is used - that
> had us guess for a bit.
Yeah, a bit too much reuse of that scratch buffer.
>
> Do you want us to work on this or have you got it under control?
I got it for now. I want to spend a bit more time testing and get some mingw32 based CI builds hooked up, etc. Hopefully will be able to get that done soon.
-Doug
>
>> -Doug
>>
>> On Apr 11, 2011, at 4:44 AM, Andrew Beekhof wrote:
>>
>>> On 04/08/2011 06:24 PM, Doug MacEachern wrote:
>>>> Hey Guys,
>>>>
>>>> Apologies for the long delay..
>>>>
>>>> On Mar 9, 2011, at 1:41 AM, Andrew Beekhof wrote:
>>>>
>>>>> On Wed, Mar 2, 2011 at 10:54 PM, Doug MacEachern<dma...@vm...> wrote:
>>>>>> Hi Adam,
>>>>>>
>>>>>> Thanks for the patches!
>>>>>> I need to take a closer look, but wondering if we could change sigar_net_interface_config_get rather than change the return values of sigar_net_interface_list:
>>>>>> sigar_net_interface_config_get("ethX",&config);
>>>>>
>>>>> Until recently I probably would have agreed with you, however given
>>>>> the recent shift away from ethX even on Linux, I'm not convinced that
>>>>> it makes sense to continue using it on Windows where it has no real
>>>>> meaning. Worse, the number of ethX entries does not even match the
>>>>> number of physical devices (there are two additional "pseudo devices"
>>>>> for every physical one).
>>>>>
>>>>> The other issue is that anything wanting to present network
>>>>> information to users must do the translation - again, since ethX is
>>>>> meaningless on Windows.
>>>>>
>>>>> So I guess my answer here is, "yes we could and if you insist we will,
>>>>> but I really don't think we should" :-)
>>>>
>>>> I think your change is the right way to go for the long term. I just had current users in mind where this change may have an unexpected impact. In Hyperic HQ for example, ethX is used a the service name, so I believe this change would end up creating a new set of services there and the old ethX ones would just be stale. But, that's something that can be worked out.. we can leave the 1.6 branch as is and apply your changes to master/1.7.
>>>>
>>>> I'm just now trying out your patches, but it doesn't compile for me using VC 2005. I haven't looked into it yet, does it build for you with VC?
>>>
>>> We don't have access to VC, we've been using mingw32 instead.
>>> But if you let us know what the errors are we'll do our best to fix them.
>>
>
|
|
From: Andrew B. <an...@be...> - 2011-04-13 06:56:42
|
On Tue, Apr 12, 2011 at 11:16 PM, Doug MacEachern <dma...@vm...> wrote: > On Apr 12, 2011, at 1:07 AM, Andrew Beekhof wrote: > >> On 04/11/2011 11:11 PM, Doug MacEachern wrote: >>> Hi Andrew, >>> >>> ok, no problem, I have it building with the ms compiler now. >> >> Great >> >>> sigar_net_interface_name_get is declared extern, do you need that outside of the sigar library or can I make it static? >> >> We're not using it explicitly, so static should be fine. > > ok, cool. > >> >>> >>> +SIGAR_DECLARE(char *) >>> +sigar_net_interface_name_get(sigar_t *sigar, MIB_IFROW *ifr) >>> >>> I'd also like to make PIP_ADAPTER_ADDRESSES an input to that function so we can avoid calling sigar_new each time. >> >> Sure. That makes sense. Just be careful how ifconf_buf is used - that >> had us guess for a bit. > > Yeah, a bit too much reuse of that scratch buffer. > >> >> Do you want us to work on this or have you got it under control? > > I got it for now. I want to spend a bit more time testing and get some mingw32 based CI builds hooked up, etc. Hopefully will be able to get that done soon. Awesome. Happy to do some early testing too - just let us know. |
|
From: Doug M. <dma...@vm...> - 2011-04-21 17:22:52
|
Hi Andrew, I've made a few changes on top of yours, but it is the same functionally. The changes are merged to hyperic/sigar master now, let me know if everything looks good to you. Thanks again! -Doug On Apr 12, 2011, at 11:56 PM, Andrew Beekhof wrote: > On Tue, Apr 12, 2011 at 11:16 PM, Doug MacEachern > <dma...@vm...> wrote: >> On Apr 12, 2011, at 1:07 AM, Andrew Beekhof wrote: >> >>> On 04/11/2011 11:11 PM, Doug MacEachern wrote: >>>> Hi Andrew, >>>> >>>> ok, no problem, I have it building with the ms compiler now. >>> >>> Great >>> >>>> sigar_net_interface_name_get is declared extern, do you need that outside of the sigar library or can I make it static? >>> >>> We're not using it explicitly, so static should be fine. >> >> ok, cool. >> >>> >>>> >>>> +SIGAR_DECLARE(char *) >>>> +sigar_net_interface_name_get(sigar_t *sigar, MIB_IFROW *ifr) >>>> >>>> I'd also like to make PIP_ADAPTER_ADDRESSES an input to that function so we can avoid calling sigar_new each time. >>> >>> Sure. That makes sense. Just be careful how ifconf_buf is used - that >>> had us guess for a bit. >> >> Yeah, a bit too much reuse of that scratch buffer. >> >>> >>> Do you want us to work on this or have you got it under control? >> >> I got it for now. I want to spend a bit more time testing and get some mingw32 based CI builds hooked up, etc. Hopefully will be able to get that done soon. > > Awesome. > Happy to do some early testing too - just let us know. |
|
From: Andrew B. <an...@be...> - 2011-04-23 08:11:06
|
On Thu, Apr 21, 2011 at 7:22 PM, Doug MacEachern <dma...@vm...> wrote: > Hi Andrew, > > I've made a few changes on top of yours, but it is the same functionally. The changes are merged to hyperic/sigar master now, let me know if everything looks good to you. The changes look good to me. Adam: Can you build against these and confirm matahari still works? > Thanks again! Thank you :) > > -Doug > > On Apr 12, 2011, at 11:56 PM, Andrew Beekhof wrote: > >> On Tue, Apr 12, 2011 at 11:16 PM, Doug MacEachern >> <dma...@vm...> wrote: >>> On Apr 12, 2011, at 1:07 AM, Andrew Beekhof wrote: >>> >>>> On 04/11/2011 11:11 PM, Doug MacEachern wrote: >>>>> Hi Andrew, >>>>> >>>>> ok, no problem, I have it building with the ms compiler now. >>>> >>>> Great >>>> >>>>> sigar_net_interface_name_get is declared extern, do you need that outside of the sigar library or can I make it static? >>>> >>>> We're not using it explicitly, so static should be fine. >>> >>> ok, cool. >>> >>>> >>>>> >>>>> +SIGAR_DECLARE(char *) >>>>> +sigar_net_interface_name_get(sigar_t *sigar, MIB_IFROW *ifr) >>>>> >>>>> I'd also like to make PIP_ADAPTER_ADDRESSES an input to that function so we can avoid calling sigar_new each time. >>>> >>>> Sure. That makes sense. Just be careful how ifconf_buf is used - that >>>> had us guess for a bit. >>> >>> Yeah, a bit too much reuse of that scratch buffer. >>> >>>> >>>> Do you want us to work on this or have you got it under control? >>> >>> I got it for now. I want to spend a bit more time testing and get some mingw32 based CI builds hooked up, etc. Hopefully will be able to get that done soon. >> >> Awesome. >> Happy to do some early testing too - just let us know. > > |
|
From: Adam S. <aj...@re...> - 2011-04-25 14:50:45
|
----- Original Message -----
> On Thu, Apr 21, 2011 at 7:22 PM, Doug MacEachern
> <dma...@vm...> wrote:
> > Hi Andrew,
> >
> > I've made a few changes on top of yours, but it is the same
> > functionally. The changes are merged to hyperic/sigar master now,
> > let me know if everything looks good to you.
>
> The changes look good to me.
> Adam: Can you build against these and confirm matahari still works?
>
Hi Doug,
Quick question -- on the Windows system I don't seem to be seeing the long friendly names of the devices only the short names. I went as far as setting an environment variable for the SIGAR_NETIF_NAME_SHORT to attempt to force sigar to print the friendly names. Is there something I could be missing?
Thanks for all the work!
--
__ __
.-----.| |_.-----.| |--.-----.-----.
|__ --|| _| _ || <| -__|__ --|
|_____||____|_____||__|__|_____|_____|
.----------------------------------.
( aj...@re... || 919.754.4187 )
`----------------------------------'
|
|
From: Andrew B. <an...@be...> - 2011-03-09 09:41:25
|
On Wed, Mar 2, 2011 at 10:54 PM, Doug MacEachern <dma...@vm...> wrote:
> Hi Adam,
>
> Thanks for the patches!
> I need to take a closer look, but wondering if we could change sigar_net_interface_config_get rather than change the return values of sigar_net_interface_list:
> sigar_net_interface_config_get("ethX", &config);
Until recently I probably would have agreed with you, however given
the recent shift away from ethX even on Linux, I'm not convinced that
it makes sense to continue using it on Windows where it has no real
meaning. Worse, the number of ethX entries does not even match the
number of physical devices (there are two additional "pseudo devices"
for every physical one).
The other issue is that anything wanting to present network
information to users must do the translation - again, since ethX is
meaningless on Windows.
So I guess my answer here is, "yes we could and if you insist we will,
but I really don't think we should" :-)
>
> Then either change the value of config.description to use FriendlyName, or even add a new field to sigar_net_interface_config_t?
>
> Thanks,
> -Doug
>
> On Feb 28, 2011, at 7:48 AM, Adam Stokes wrote:
>
>> Hi,
>>
>> I'm Adam, one of the developers for matahari project (http://github.com/matahari). We are attempting to provide some useful apis over a remote interface (qpid.apache.org) that is cross platform.
>>
>> The resources used for cross compilation is mingw32. The first patch is for allowing sigar to compile successfully under those requirements.
>>
>> Some of the routines in the api (specifically network) we expose the ability to start/stop network interfaces through Windows netsh application. With the current sigar implementation interfaces are listed as 'ethX' which is fine when doing read only within the realm of sigar. When attempting to branch out and use application such as netsh in conjunction with sigar this fails due to netsh requiring a Friendly Name of the network interface. The second patch allows us to capture the interfaces friendlyname and at worst its interface description.
>>
>>
>> The pull request can be found here,
>>
>> https://github.com/hyperic/sigar/pull/5
>>
>> Thank you
>> Adam
>>
>>
>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X