You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While the new API makes error management much nicer, some users might just want to get raw errnos.
We can very easily switch to returning raw errnos from a type perspective, but it's a little unclear what we should do for errors that don't have an underlying errno. We can just copy the kernel and just use -EINVAL 😅, or we could use an errno that the kernel rarely returns like -ENOANO, never returns like -ENOPARAM, or a large negative number that doesn't map to any errno (INT_MIN if we want to be safe, I guess?).
This requires us getting a nice config API first (#21).
ESERVERFAULT (errno 526, a kernel-internal errno from the NFSv3 protocol) semantically makes sense (the error description is An untranslatable error occurred) and is an errno userspace should never see returned from the kernel so we're safe remapping errors to it without causing confusion.
We can also switch away from using Mutex<HashMap<...>> to one of these lockless alternatives:
https://github.com/hawkw/sharded-slab (has the benefit of having generation numbers, which reduces the risk of a user double-getting the same ID and clearing another thread's error by accident.)
https://github.com/loyd/idr-ebr is similar, but it isn't optimised for insert/remove (which is our usecase!) so sharded-slab is probably better.
While the new API makes error management much nicer, some users might just want to get raw errnos.
We can very easily switch to returning raw errnos from a type perspective, but it's a little unclear what we should do for errors that don't have an underlying errno. We can just copy the kernel and just use
-EINVAL
😅, or we could use an errno that the kernel rarely returns like-ENOANO
, never returns like-ENOPARAM
, or a large negative number that doesn't map to any errno (INT_MIN
if we want to be safe, I guess?).This requires us getting a nice config API first (#21).
(Suggested by @brauner.)
The text was updated successfully, but these errors were encountered: