Public ioctl api #132
Merged
Public ioctl api #132
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This can be rebased now. |
Instead, propagate the worker context from the testbed in the call to register the path with the IoctlBase handler.
benzea
force-pushed
the
benzea/public-ioctl-api
branch
2 times, most recently
from
54a7cb1 to
e0d069e
Compare
|
OK, did the API changes that I mentioned. I think this is good to go now. The only downside is that it means we commit to the whole API on how data is resolved. But, considering it works well enough for the current usecases, I think that is reasonable. |
This was referenced Jun 25, 2021
Open
martinpitt
requested changes
Jun 26, 2021
benzea
force-pushed
the
benzea/public-ioctl-api
branch
2 times, most recently
from
bfbdead to
495d404
Compare
|
OK, I think it is quite a bit nicer now from an API point of view. |
benzea
force-pushed
the
benzea/public-ioctl-api
branch
from
495d404 to
520de94
Compare
added 2 commits
June 28, 2021 15:28
Rather than requiring explict loads and dirty marking, do this implicitly. This means that clients only need to resolve pointers manually and everything else is happening implicitly. Data is only flushed back when it was modified locally. As such, this only results in a few more round-trips as e.g. read() data will be resolved automatically. If desired, this can be optimized at a later point by improving the emulation protocol.
Updating contained pointers automatically is neat, but it is not reliable in general. Require the API user to resolve data again explicitly as error handling would be a mess otherwise.
benzea
force-pushed
the
benzea/public-ioctl-api
branch
from
520de94 to
54e5b30
Compare
martinpitt
requested changes
Jun 29, 2021
benzea
force-pushed
the
benzea/public-ioctl-api
branch
from
54e5b30 to
7b73264
Compare
|
Thanks! Some explicit testing for the IoctlData stuff would be nice for reference, yes. I did add a single |
added 4 commits
June 29, 2021 18:34
Exposing this API means that users can implement full custom ioctl and read/write emulation. Closes: martinpitt#128
Doing this means that the vfunc is called by glib during signal emission. It is ugly to insert the C code like this, but it works well and it means that signal emission becomes much more well defined.
Aborting has the advantage that it will trigger a core-dump, simplifying debugging.
benzea
force-pushed
the
benzea/public-ioctl-api
branch
from
7b73264 to
cf5da5d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On top of #125 (sorry, but need fixes from there to make sense).
API is not optimal yet:
IoctlBaseinitialisation, then pass it when attaching the deviceBut, works nicely.