Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Some kernel object creation APIs are becoming infallible

19 views
Skip to first unread message

Adam Perry

unread,
Nov 30, 2022, 2:14:07 PM11/30/22
to rust-...@fuchsia.dev

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:


  1. in/out pointers are invalid

    1. this is prevented by construction in the Rust kernel bindings

  2. the kernel is out of memory

    1. the kernel docs say userspace should not try to handle this

  3. job policy disallows creating those objects for a given process

  4. 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

Filip Filmar

unread,
Nov 30, 2022, 2:17:56 PM11/30/22
to Adam Perry, rust-...@fuchsia.dev
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
 

Adam Perry

unread,
Nov 30, 2022, 2:20:17 PM11/30/22
to Filip Filmar, rust-...@fuchsia.dev
On Wed, Nov 30, 2022 at 11:17 AM Filip Filmar <fm...@google.com> wrote:
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.

:D
 

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?

Yeah, I think it would be straightforward to add them back, although we'd also need to bubble try_ variants up through any intermediate libraries we build in the meantime. I think that's probably a reasonable price to pay if we eventually discover use cases for handling e.g. handle table exhaustion.
 

F
 


--
Adam Perry

Adam Perry

unread,
Dec 22, 2022, 3:58:16 PM12/22/22
to rust-...@fuchsia.dev
The bulk of the fuchsia_zircon changes landed last night and seem to have stuck, I'll be cleaning those up and moving onto fuchsia_async and the fidl crate next.
--
Adam Perry
Reply all
Reply to author
Forward
0 new messages