Re: [PATCH v2 2/3] rust: block: add rnull, Rust null_blk implementation

Andreas Hindborg
2024-06-01T08:02:41Z

Benno Lossin <benno.lossin@proton.me> writes:

[...]

>>>> +
>>>> +fn add_disk(tagset: Arc<TagSet<NullBlkDevice>>) -> Result<GenDisk<NullBlkDevice, gen_disk::Added>> {
>>>
>>> Any reason that this is its own function and not in the
>>> `NullBlkModule::init` function?
>>
>> Would you embed it inside the `init` function? To what end? I don't
>> think that would read well.
>
> I just found it strange that you have this extracted into its own
> function, since I just expected it to be present in the init function.
> Does this look really that bad?:
>
> impl kernel::Module for NullBlkModule {
> fn init(_module: &'static ThisModule) -> Result<Self> {
> pr_info!("Rust null_blk loaded\n");
> let block_size: u16 = 4096;
> if block_size % 512 != 0 ||
> !(512..=4096).contains(&block_size) {
> return Err(kernel::error::code::EINVAL);
> }
>
> let disk = {
> let tagset = Arc::pin_init(TagSet::try_new(1, 256, 1),
> flags::GFP_KERNEL)?;
> let mut disk = gen_disk::try_new(tagset)?;
> disk.set_name(format_args!("rnullb{}", 0))?;
> disk.set_capacity_sectors(4096 << 11);
> disk.set_queue_logical_block_size(block_size.into());
> disk.set_queue_physical_block_size(block_size.into());
> disk.set_rotational(false);
> disk.add()
> };
> let disk = Box::pin_init(
> new_mutex!(disk, "nullb:disk"),
> flags::GFP_KERNEL,
> )?;
>
> Ok(Self { _disk: disk })
> }
> }

I don't mind either way. I guess we could combine it.

[...]

>>>> +#[vtable]
>>>> +impl Operations for NullBlkDevice {
>>>> + #[inline(always)]
>>>> + fn queue_rq(rq: ARef<mq::Request<Self>>, _is_last: bool) -> Result {
>>>> + mq::Request::end_ok(rq)
>>>> + .map_err(|_e| kernel::error::code::EIO)
>>>> + .expect("Failed to complete request");
>>>
>>> This error would only happen if `rq` is not the only ARef to that
>>> request, right?
>>
>> Yes, it should never happen. If it happens, something is seriously
>> broken and panic is adequate.
>>
>> Other drivers might want to retry later or something, but in this case
>> it should just work.
>
> In that case, I think the error message should reflect that and not just
> be a generic "failed to complete request" error.

Right, that is a good point.

Best regards,
Andreas