Tock 2.0: Deprecate SuccessWithValue #2252
Conversation
Removes all uses of ReturnCode::SUccessWithValue outside LegacyDriver::command(), and updates the porting guide to reflect that part of porting requires removing all uses of SuccessWithValue when moving to Driver. Given that SuccessWithValue is no longer a consideration, add a helper function to the kernel for converting a ReturnCode to a CommandResult. This change does require slight ABI changes to both the UDP driver and hd44780 driver, as they rely on functionality that does not exist in 2.0.
|
Awesome. I'll work on updating memop tomorrow. |
| } | ||
|
|
||
| use core::convert::TryFrom; | ||
| impl From<ReturnCode> for CommandResult { |
There was a problem hiding this comment.
I see the point in adding a helper method for the common case, and especially for the first transition from the old to the new system call ABI. However, this is not the only way to encode a ReturnCode (and later ErrorCode) as a CommandResult. I'd like to emphasize this fact, and I believe that the generic From trait -- although common -- is poorly suited because of its semantic meaning elsewhere in the Rust ecosystem.
If we add a helper, I'd appreciate a more explicitly method on CommandResult (even fn encode_return_code would do) to emphasize the fact that this is one particular way and helper to convert a ReturnCode to a CommandResult and by no means the only one (especially when other branches of a command would return other variants, given that each command is supposed to have only one success and failure variant).
There was a problem hiding this comment.
Once SuccessWithValue is removed, how else would a ReturnCode be converted to a CommandResult? Or do you just mean that there might be places in Tock like this:
fn command(...) -> CommandResult {
match command_num {
0 => {
let retcode = capsule_helper_func();
let mut some_u32 = 0;
if retcode == ReturnCode::SUCCESS {
some_u32 = other_helper_func();
}
match retcode {
ReturnCode::SUCCESS => CommandResult::success_u32(some_u32),
_ => CommandResult::failure(),
}
}
}
}where because you want to return additional information, you have to construct the CommandResult differently?
There was a problem hiding this comment.
Or is this a concern about ? automatically coercing when From is implemented? I don't think that can be an issue here either, because CommandResult is not actually a Result<> type?
|
bors r+ |
|
Already running a review |
2269: Tock 2.0 analog comparator: use `ErrorCode::From` r=phil-levis a=hudson-ayers ### Pull Request Overview Updates new analog comparator driver to use utilities added in #2252 . ### Testing Strategy This pull request was tested by compiling. ### TODO or Help Wanted N/A ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Hudson Ayers <[email protected]>
2252: Tock 2.0: Deprecate SuccessWithValue r=phil-levis a=hudson-ayers ### Pull Request Overview This PR removes all uses of `ReturnCode::SuccessWithValue` aside from those contained directly within an implementation of `LegacyDriver::command()`. It also updates the porting guide to reflect that part of porting requires removing all uses of `SuccessWithValue` when moving to Driver. This should make it extremely easy to remove `SuccessWithValue` entirely once all capsules have been ported. Given that `SuccessWithValue` is no longer a consideration, this PR also adds a helper function to the kernel for converting a `ReturnCode` to a `CommandResult`. There were 5 locations outside `LegacyDriver::command()` implementations that constructed `SuccessWithValue`: 1. UDP driver. I modified this code to ensure that SuccessWithValue is only constructed within `command()`, and not in any helper functions, by replacing its use with `Result`. 2. Hd44780 capsule returned `SuccessWithValue` from `allow()`, but allow() cannot return values in the case of success in the Tock 2.0 API. I modified it to just return Success, and made the previously returned value accessible via a new command. This will require userspace updates to work, but was a necessary change irrespective of deprecating `SuccessWithValue`. 3. IPC also returns `SuccessWithValue` from `allow()` -- I did not touch this, as I am told @alevy is working on porting IPC anyway, which will inevitably remove this use. 4. Memop liberally uses `SuccessWithValue`, but all of these will naturally be replaced as part of the switch to Tock 2.0 5. The analog comparator driver constructs `SuccessWithValue` in a helper function -- this has already been removed in tock#2245 , so I did not duplicate it here. ### Testing Strategy This pull request has not been tested. ### TODO or Help Wanted This pull request still needs thoughts on the `CommandResult::from(ReturnCode)` addition, and the changes to the porting guide. ### Documentation Updated - [x] Updated the porting doc, but other reference to SuccessWithValue may still exist ### Formatting - [x] Ran `make prepush`. Co-authored-by: Hudson Ayers <[email protected]>
2269: Tock 2.0 analog comparator: use `ErrorCode::From` r=phil-levis a=hudson-ayers ### Pull Request Overview Updates new analog comparator driver to use utilities added in tock#2252 . ### Testing Strategy This pull request was tested by compiling. ### TODO or Help Wanted N/A ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Hudson Ayers <[email protected]>
Pull Request Overview
This PR removes all uses of
ReturnCode::SuccessWithValueaside from those contained directly within an implementation ofLegacyDriver::command().It also updates the porting guide to reflect that part of porting requires removing all uses of
SuccessWithValuewhen moving to Driver.This should make it extremely easy to remove
SuccessWithValueentirely once all capsules have been ported.Given that
SuccessWithValueis no longer a consideration, this PR also adds a helper function to the kernel for converting aReturnCodeto aCommandResult.There were 5 locations outside
LegacyDriver::command()implementations that constructedSuccessWithValue:UDP driver. I modified this code to ensure that SuccessWithValue is only constructed within
command(), and not in any helper functions, by replacing its use withResult.Hd44780 capsule returned
SuccessWithValuefromallow(), but allow() cannot return values in the case of success in the Tock 2.0 API. I modified it to just return Success, and made the previously returned value accessible via a new command. This will require userspace updates to work, but was a necessary change irrespective of deprecatingSuccessWithValue.IPC also returns
SuccessWithValuefromallow()-- I did not touch this, as I am told @alevy is working on porting IPC anyway, which will inevitably remove this use.Memop liberally uses
SuccessWithValue, but all of these will naturally be replaced as part of the switch to Tock 2.0The analog comparator driver constructs
SuccessWithValuein a helper function -- this has already been removed in Update analog comparator to tock 2.0 syscalls #2245 , so I did not duplicate it here.Testing Strategy
This pull request has not been tested.
TODO or Help Wanted
This pull request still needs thoughts on the
CommandResult::from(ReturnCode)addition, and the changes to the porting guide.Documentation Updated
Formatting
make prepush.