Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> writes: > On Thu, Mar 14, 2024 at 8:23 PM Andreas Hindborg <nmi@xxxxxxxxxxxx> 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
