-
Notifications
You must be signed in to change notification settings - Fork 49
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
[prefactor] new engine_data
and error
ffi modules
#537
Conversation
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.
Couple nits, but they apply to the original code as well so your call whether to address them here.
/// # Safety | ||
/// `data_handle` must be a valid pointer to a kernel allocated `ExclusiveEngineData` | ||
#[no_mangle] | ||
pub unsafe extern "C" fn engine_data_length(data: &mut Handle<ExclusiveEngineData>) -> usize { |
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.
aside: This is a somewhat odd API... presumably engine provided this engine data instance to kernel in the first place, so presumably engine should already know how to get the length if it wants it?
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.
Actually... pretty much everything in this file feels weird/unsafe/incomplete (check out all those TODO comments). I guess eventually we'll need to clean all this up.
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.
yeah, this file is/was mostly a quick hack to allow the example program to actually read data. do note that if you're using the default engine this stuff is relevant and useful, but just that we haven't figured out all the ownership details quite yet
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.
yea I think this calls for a follow up issue
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.
feel free to chime in there: #538
ffi/src/error.rs
Outdated
pub type AllocateErrorFn = | ||
extern "C" fn(etype: KernelError, msg: KernelStringSlice) -> *mut EngineError; | ||
|
||
// NOTE: We can't "just" impl From<DeltaResult<T>> because we require an error allocator. |
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.
This comment seems misplaced? Maybe it belongs with the IntoExternResult
trait below?
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.
seems reasonable - moved!
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.
Looks good thanks. This is a useful reorg. I do think we should go all the way and not bring all the error stuff into the root scope though.
ffi/src/lib.rs
Outdated
pub mod engine_funcs; | ||
pub mod error; | ||
pub use error::*; |
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.
Is there a reason to bring all the error stuff into the root scope? It's a breaking change if we don't, but also, I think we do want things to live in error
? It's also consistent with the kernel
crate where we don't bring everything from error
into the root.
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.
ok sounds good - I was thinking it would be 'better' to have this not change the APIs but I do agree it probably just makes sense to have them be exposed inside of mod error
- ill do that!
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #537 +/- ##
==========================================
- Coverage 81.04% 81.03% -0.01%
==========================================
Files 65 67 +2
Lines 14099 14099
Branches 14099 14099
==========================================
- Hits 11426 11425 -1
- Misses 2091 2093 +2
+ Partials 582 581 -1 ☔ View full report in Codecov by Sentry. |
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.
lgtm thanks!
(no-change code movement PR)
ffi/src/lib.rs
was getting pretty long and included pieces from various things like error handling, etc. which are nicely-grouped as a standalone module. Secondly,ffi/src/scan.rs
included some engine data utilities that could be moved out and likely shared in the future (nothing scan-specific). This PR just moves out some of these easily-grouped items into separate modules:mod engine_data
: thepub fn
's moved intomod engine_data
will need to be prefixed withengine_data
now to resolvemod error
: i've donepub use error::*
so error types will be exposed the same.