-
Notifications
You must be signed in to change notification settings - Fork 105
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
feat(gstd, backend): Introduce gr_env_vars sys-call #3403
Conversation
@ark0f re-review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting changes due to gas_to_value converter
to avoid using enums you can hack the system by assuming multiplier as u128 where last 64bits are u64, first - just defining byte :/
And one more thing about naming: does "settings" fit well? Maybe "params"? like env_params... to be considered
Otherwise LveryGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome.
So how do you feel about renaming: gr_exec_settings into gr_env_parameters, or even maybe gr_env_vars ? Cause it most likely variable env params rather than settings of some standalone execution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that we need to generate gr_exec_settings
from wasm-gen for loader and fuzzer. What about adjusting wasm-gen configs for those test tools accordingly?
Introduce
gr_env_vars
sys-call providing user space with various system settings. The settings are supposed to be extandable via versioning so old clients can still obtain the settings w/o any issues when backend introduces new versions