Re: [PATCH 12/26] fuse-bpf: Add support for fallocate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 27, 2022 at 3:07 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> As I browse through this series, I find this pattern unnecessarily
> verbose and it exposes way too much of the filtering mechanism to
> code that should not have to know anything about it.
>
> Wouldn't it be better to code this as:
>
>         error = fuse_filter_fallocate(file, mode, offset, length);
>         if (error < 0)
>                 return error;
>
>
> And then make this fuse_bpf_backing() call and all the indirect
> functions it uses internal (i.e. static) in fs/fuse/backing.c?
>
> That way the interface in fs/fuse/fuse_i.h can be much cleaner and
> handle the #ifdef CONFIG_FUSE_BPF directly by:
>
> #ifdef CONFIG_FUSE_BPF
> ....
> int fuse_filter_fallocate(file, mode, offset, length);
> ....
> #else /* !CONFIG_FUSE_BPF */
> ....
> static inline fuse_filter_fallocate(file, mode, offset, length)
> {
>         return 0;
> }
> ....
> #endif /* CONFIG_FUSE_BPF */
>
> This seems much cleaner to me than exposing fuse_bpf_backing()
> boiler plate all over the code...
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@xxxxxxxxxxx.
>

Thanks for the suggestion, that'll help clean things up a bit. It's
quite nice to have fresh eyes looking over the code.

-Daniel



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux