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
The ublk_wait_and_handle_ios function has a hard dependency on smol for its async runtime. Is this necessary or can libublk be implemented independently of any particular runtime? I'd like to use tokio or monoio for my runtime and would prefer to avoid bloating my binary.
The UblkQueue also can't be shared across threads. Is there guidance on how to build a multi-threaded ublk device? Or is that explicitly not supported for a reason?
The ublk_wait_and_handle_ios function has a hard dependency on smol for its async runtime. Is this necessary or can libublk be implemented independently of any particular runtime? I'd like to use tokio or monoio for my runtime and would prefer to avoid bloating my binary.
I think that is definitely reasonable to not let libublk not bind with
smol, and so far looks it is just for example code.
I will think a bit and try to move it into the rublk code.
The UblkQueue also can't be shared across threads. Is there guidance on how to build a multi-threaded ublk device? Or is that explicitly not supported for a reason?
So far, UblkQueue can't cross threads, that is also what the ublk driver is implemented.
But we are considering to try to relax this limit, please see the following
discussion:
The
ublk_wait_and_handle_ios
function has a hard dependency onsmol
for its async runtime. Is this necessary or canlibublk
be implemented independently of any particular runtime? I'd like to use tokio or monoio for my runtime and would prefer to avoid bloating my binary.The text was updated successfully, but these errors were encountered: