On Thu, Mar 14, 2024 at 8:23 PM Andreas Hindborg <[email protected]> wrote:
>
> The way the current code compiles, <kernel::block::mq::Request as
> kernel::types::AlwaysRefCounted>::dec_ref` is inlined into the `rnull`
> module. A relocation for `rust_helper_blk_mq_free_request_internal`
> appears in `rnull_mod.ko`. I didn't test it yet, but if
> `__blk_mq_free_request` (or the helper) is not exported, I don't think
> this would be possible?
Yeah, something needs to be exported since there is a generic
involved, but even if you want to go the route of exporting only a
different symbol, you would still want to put it in the C header so
that you don't get the C missing declaration warning and so that we
don't have to write the declaration manually in the helper.
In any case, if we really want to avoid exporting the original symbol
(perhaps so that "only Rust" can use it -- or someone trying hard to
bypass things on purpose), then we could still avoid the helper and
instead write a non-generic `kernel`-private Rust function instead.
Cheers,
Miguel
On Thu, Mar 14, 2024 at 8:41 PM Miguel Ojeda
<[email protected]> wrote:
>
> In any case, if we really want to avoid exporting the original symbol
> (perhaps so that "only Rust" can use it -- or someone trying hard to
> bypass things on purpose), then we could still avoid the helper and
> instead write a non-generic `kernel`-private Rust function instead.
The advantages would be that we get the export done automatically and
that we could write in Rust, e.g. with restricted visibility.
But we could need `#[inline(never)]` (or ideally `#[used]` if it could
go on functions) or `#[no_mangle]` (but we would lose the mangling).
Anyway, the simplest is to export the original symbol, but we could
consider to provide support one way or another for this kind of
"helpers" (i.e. leaving the current helpers as those for macros and
inline functions), so that it is clear what symbols are only exported
for Rust use (and not other C code).
Cheers,
Miguel
Miguel Ojeda <[email protected]> writes:
> On Thu, Mar 14, 2024 at 8:23 PM Andreas Hindborg <[email protected]> wrote:
>>
>> The way the current code compiles, <kernel::block::mq::Request as
>> kernel::types::AlwaysRefCounted>::dec_ref` is inlined into the `rnull`
>> module. A relocation for `rust_helper_blk_mq_free_request_internal`
>> appears in `rnull_mod.ko`. I didn't test it yet, but if
>> `__blk_mq_free_request` (or the helper) is not exported, I don't think
>> this would be possible?
>
> Yeah, something needs to be exported since there is a generic
> involved, but even if you want to go the route of exporting only a
> different symbol, you would still want to put it in the C header so
> that you don't get the C missing declaration warning and so that we
> don't have to write the declaration manually in the helper.
That is what I did:
@@ -703,6 +703,7 @@ int blk_mq_alloc_sq_tag_set(struct blk_mq_tag_set *set,
unsigned int set_flags);
void blk_mq_free_tag_set(struct blk_mq_tag_set *set);
+void __blk_mq_free_request(struct request *rq);
void blk_mq_free_request(struct request *rq);
int blk_rq_poll(struct request *rq, struct io_comp_batch *iob,
unsigned int poll_flags);
> In any case, if we really want to avoid exporting the original symbol
> (perhaps so that "only Rust" can use it -- or someone trying hard to
> bypass things on purpose), then we could still avoid the helper and
> instead write a non-generic `kernel`-private Rust function instead.
Let's see what the block layer experts say first. Perhaps it is OK to
expose this symbol like this or maybe it can be made more generic
somehow.
Jens, Ming, Keith, do you have any comments?
Best regards,
Andreas