TLDR: Several Rust library APIs will return kernel objects directly without wrapping them in a Result, including fidl::endpoints::create_endpoints(). Please reply to this thread if you have a use case for keeping fallible APIs around after the migration.
Zircon channels, events, eventpairs, ports, and timers all have syscalls for creating them which can only fail if:
in/out pointers are invalid
this is prevented by construction in the Rust kernel bindings
the kernel is out of memory
the kernel docs say userspace should not try to handle this
job policy disallows creating those objects for a given process
the process' or the kernel's handle table is full
Forcing userspace code to handle (1) and (2) is fairly clearly wasteful. It's slightly more likely for someone to write code that needs to handle (3) or (4), but I'm not aware of any existing code which needs to do so.
While fallible APIs for these libraries might make it easier to write higher-reliability resource-intensive software in the future, we pay an ergonomic tax today without having any current use cases I can find.
After discussion with the Rust on Fuchsia WG and the FIDL team I'm going to migrate several APIs to infallible versions in the coming weeks:
Note that the fidl crate's other endpoint APIs have additional failure modes beyond object creation so those functions will stay the same for now.
Each of these migrations will require adding a try_ variant for each function to soft-migrate petal repositories. My current plan is to mark these fallible variants as deprecated when landing them and to delete them after completing the migration of existing callers. If you have a use case that would benefit from keeping fallible variants around long-term, please reply to this thread!
Thanks,
Adam Perry
Each of these migrations will require adding a try_ variant for each function to soft-migrate petal repositories. [...]
On Wed, Nov 30, 2022 at 11:14 AM Adam Perry <adam...@google.com> wrote:Each of these migrations will require adding a try_ variant for each function to soft-migrate petal repositories. [...]
Thank you for simplifying the API.
Perhaps a naive question, if we find that we do need `try_` variants after they have been removed in this migration, can I assume that we can grow them back?
F