You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.
Describe the bug
The structure of the HS code includes hs_custom.h and hs_custom.c that imply that these contain user-defined functions. However the current code does not really allow for this. Notably -
The interface between "custom" and standard routines is not well defined
Unit tests directly use the hs_custom_internal.h data structures in non-custom tests (e.g. see HS_MonitorUtilization_Test_CPUHogging, among others)
Furthermore, the code is simply in the same src directory as the rest of HS, so any customizations mean creating a fork of HS and the user having to manage that fork.
To Reproduce
Attempt to change the contents of HS_CustomData_t - such as removing the UtilMult and and UtilDiv fields and replacing with some other logic. This will break seeming unrelated code that assumes these fields exist.
Expected behavior
If HS depends on a computation working a certain way, it shouldn't be labeled as custom. Conversely, if a section of code is truly intended to be customized by the user, the interface into that custom function needs to be well-defined and no other parts of the code should assume it works a certain way or has certain fields in its global data.
Code snips
Example of a place where unit test is directly accessing custom fields from a non-custom test:
Additional context
Could this custom logic potentially be refactored into a separate support library, so the user would not have to fork HS to customize these routines?
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered:
Checklist (Please check before submitting)
Describe the bug
The structure of the HS code includes
hs_custom.h
andhs_custom.c
that imply that these contain user-defined functions. However the current code does not really allow for this. Notably -HS_MonitorUtilization_Test_CPUHogging
, among others)Furthermore, the code is simply in the same src directory as the rest of HS, so any customizations mean creating a fork of HS and the user having to manage that fork.
To Reproduce
Attempt to change the contents of
HS_CustomData_t
- such as removing theUtilMult
and andUtilDiv
fields and replacing with some other logic. This will break seeming unrelated code that assumes these fields exist.Expected behavior
If HS depends on a computation working a certain way, it shouldn't be labeled as
custom
. Conversely, if a section of code is truly intended to be customized by the user, the interface into that custom function needs to be well-defined and no other parts of the code should assume it works a certain way or has certain fields in its global data.Code snips
Example of a place where unit test is directly accessing custom fields from a non-custom test:
HS/unit-test/hs_monitors_tests.c
Lines 1684 to 1688 in c976c6a
System observed on:
N/A
Additional context
Could this custom logic potentially be refactored into a separate support library, so the user would not have to fork HS to customize these routines?
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: