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

Handle time as a native type #42

Open
ZhikuiRen opened this issue Feb 18, 2020 · 6 comments
Open

Handle time as a native type #42

ZhikuiRen opened this issue Feb 18, 2020 · 6 comments

Comments

@ZhikuiRen
Copy link
Contributor

Define a type specifier for times.
There are various units of times (seconds through microseconds) in different interfaces and it is going to cause an issue

@wak-google
Copy link
Contributor

I actually have a commit for this somewhere to use chrono types for all the interfaces where durations are taken.

@williamspatrick
Copy link
Member

@wak-google can you post this code in gerrit even if it is WIP? I might be able to finish it up.

@wak-google
Copy link
Contributor

The commit I had was actually pretty trivial and doesn't keep the old function signatures which is probably not ideal for migration. This should probably be a 2 phase change.

https://gerrit.openbmc-project.xyz/c/openbmc/sdbusplus/+/18995

@williamspatrick
Copy link
Member

@wak-google Thank you, but I think this is different than what was asked for in the issue (I only know this because I was involved in the code review where this came up). What @ZhikuiRen wanted us to do was to support in the YAML interface files a type of 'time' so that the dbus interfaces were not having to guess at what kind of conversion was needed on an integer property that happened to represent a time-interval.

@wak-google
Copy link
Contributor

Oh right, yeah I haven't touched this at all. It would be nice if we could basically just implement a system that mirrors the c++, so signatures look like duration[uint64, micro] or time[uint32]

@williamspatrick
Copy link
Member

Yes. I was considering simplifying it to just always use int64_t and then either always do things in micros on the dbus or allow time[duration] to be specified.

Do you see a good reason to allow types other than int64_t?

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

No branches or pull requests

3 participants