Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

derive context settings from configuration file #12432

Merged
merged 8 commits into from
Nov 26, 2023

Conversation

maloel
Copy link
Collaborator

@maloel maloel commented Nov 20, 2023

Continuation (2/3) of previous PR for persistent DDS settings.

  • Move the filename for our config file (the one the Viewer uses) into rs.h as RS2_CONFIG_FILENAME
  • The configuration file (JSON) implementation in common/rs-config now can read non-string JSON values
  • Contexts now take their settings from:
    • The global configuration file context key, merged with:
    • Application-specific context key, merged with:
    • Context-specific settings as handed to the context
  • Context settings can disable the above with "inherit":false

E.g.:

{
  "context": {
    "dds": {
      "enabled": false,
      "domain": 5
    }
  },
  "realsense-viewer": {
    "context": {
      "dds": {
        "enabled": true,
        "device": {
          "metadata": { "reliability": "best-effort" }
        }
      }
    }
  },
  ...
}
  • would disable DDS by default, except in the viewer
  • would default to domain 5 when enabled

Tracked on [LRS-963]

@maloel maloel requested a review from OhadMeir November 20, 2023 12:38
auto it = _values.find(key);
return it != _values.end();
auto it = _j.find(key);
return it != _j.end() && it->is_string();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why check for string? Don't we support other values?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because, at least in rs-config, and in this PR, I didn't want to change any existing functionality: tools will keep behaving the same.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My main goal was to make rs-config compatible with raw json -- before, it couldn't even load -- and able to keep non-string content intact.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So in the next PR this is about to change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I'm not touching it again without a good reason.

std::map<std::string, std::string> _defaults;
std::string _filename;
nlohmann::json _j;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_j does not imply the member meaning, just the type. _config?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the underlying json object. I can name it _json, but I don't know if that adds much...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name should not change if we decide to switch from JSON to XML or other.
The meaning of this variable is to hold the configuration in memory.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_data? _map? _key_value? Anything you pick is meaningless. :)
Let's be realistic. It's a file with an extension of .json.

std::map<std::string, std::string> _defaults;
std::string _filename;
nlohmann::json _j;
};
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Newline needed?

src/context.cpp Outdated
namespace librealsense {


static nlohmann::json load_config()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might be useful to have a load/save_json( filename ) utility. I know that Noa has a task concerning saving and parsing json content.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not quite sure why, it's very straightforward as you see...

src/context.cpp Outdated
// Take the global 'context' settings out of the configuration
nlohmann::json settings;
if( auto global_context = rsutils::json::nested( config, "context" ) )
merge_settings( settings, global_context, "global config-file/context" );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that the parameter order should be switched.
As I understand specified context_settings should override executable settings that in turn override global setting

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly what it does
Here it take empty settings and "merges" the global, so we get global.

if( only_sw_arg.getValue() )
{
settings["dds"]["enabled"] = true; // override global dds:false or dds/enabled:false, if any
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be true only if BUILD_WITH_DDS is set

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't hurt, but OK.
Do you think it makes sense to enable DDS automatically if we see "sw-only" device-mask (i.e., override enabled=false if device-mask is sw-only)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, could be playback or future type devices. If settings set to disable then leave disabled

@@ -58,10 +60,67 @@ topics::device_info rs2_device_to_info( rs2::device const & dev )
}


static nlohmann::json load_config()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes my point about a utility stronger :-)

The 3 static functions should probably all be in rsutils

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two. I thought the same but I don't think it belongs in rsutils.
Load config shouldn't know about RS2_CONFIG_FILENAME. It can get the filename. But then what're we adding? The exception handling? The error would be different, I could make it "failed to load json file: ..." but then I just don't feel the function adds much.
Same with merge_settings: it's just a wrapper around merge_patch with error handling.
In the end I decided to just keep as is. You think I should make rsutils::json::load_file() and rsutils::json::merge?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

load_file in rsutils makes less and less sense to me (no filename generation; if would have to return bool to denote if the file was there, so you'd have to handle it in the caller). I prefer to just embed directly in load_settings.

merge_patch is a weird name and I can see introducing rsutils::json::merge() or json::patch with maybe an optional name for error handling.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway:

  • added rsutils::json::patch()
  • added rsutils::json::load_settings that does the basic global+app merge

Copy link
Contributor

@OhadMeir OhadMeir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@maloel maloel merged commit e9541bb into IntelRealSense:development Nov 26, 2023
16 of 17 checks passed
@maloel maloel deleted the config-file branch November 26, 2023 09:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants