Re: File operations

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Sun, Dec 13, 2020 at 3:12 AM Wedson Almeida Filho
<wedsonaf@google.com> wrote:
>
> With this solution, `struct file_operations` is filled with pointers
> even for the functions that are not implemented by the client. The
> problem with this is that for some of the functions, the kernel
> behaviour changes depending on whether the function is null or
> non-null, so ideally we should only have non-null pointers in `struct
> file_operations` when clients actually implement them.

That is the part that sounds to me like we could go with a builder pattern.

> So I was in search of a way to determine, ideally at compile-time, if
> a function implementation was provided by the type or if it was the
> default one (provided by the trait itself). I couldn't find a way. So
> I thought about the macro to extract this information for us: it gets
> a list of functions that *are* implemented, then generates the
> implementation of another trait that is used to generate the correct
> `struct file_operations` at compile time.
>
> For example, the client would write something like:

Yeah, I was trying to understand if there could be a way around
generating that code to begin with, i.e. modifying how
`file_operations.rs` works.

For instance, could the user define a type with only the methods they
need and then construct the `file_operations` struct (perhaps
abstracted the builder pattern)? The codegen/performance should be OK,
since all the values would be known. The downside is that you need to
actually repeat your functions in the builder, but the positive side
is that the code is way more straightforward, no macros, etc.

> Then our vtable-generating code would use FileOperationsBools to
> determine what should be null and non-null. (Similarly to how it uses
> FileOperations with Some(_) to make the same determination today.)
>
> If the client forgets to add [#build_fileops] to their implementation,
> it will fail to compile because they won't implement
> FileOperationBools.

Sounds good to me!

> Apart from the non-trivial macro, it seems like a good solution to me.
> Do you know of a simpler way to figure out whether a function
> implementation is actually provided for a given type or if it's using
> the default one?

I don't think there is any either, but I'm not an expert.

> This also works. However, I think what I propose above seems less
> magical because it has the "impl FileOperations for XX", so the client
> knows that they're implementing a trait now, and with this knowledge
> they can find the definition of the trait and figure out which
> functions they are allowed to implement.

You're totally right, making users see the `impl` is better.

Cheers,
Miguel