On Mon, Oct 7, 2024 at 1:16 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Mon, 7 Oct 2024 at 13:02, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> > What I see after my patch is that ->private_data points to a singly
> > linked list of length 1 to 2 of backing files.
>
> Well, yeah.
>
> Still, it's adding (arguably minimal) data and code to backing_file,
> that is overlay specific. If you show how this is relevant to fuse's
> use of backing files, then that's a much stronger argument in favor.
>
> > Well, this is not any worth that current ->private_data, but I could
> > also make it, if you like it better:
> >
> > struct backing_file {
> > struct file file;
> > struct path user_path;
> > + struct file *next;
> > };
> >
> > +struct file **backing_file_private_ptr(struct file *f)
> > +{
> > + return &backing_file(f)->next;
> > +}
> > +EXPORT_SYMBOL_GPL(backing_file_next_ptr);
>
> Yeah, that would solve type safety, but would make the infrastructure
> less generic.
>
> > Again, I am not terribly opposed to allocating struct ovl_file as we do
> > with directory - it is certainly more straight forward to read, so that
> > is a good enough argument in itself, and "personal dislike" is also a fair
> > argument, just arguing for the sake of argument so you understand my POV.
>
> I think readability is more important here than savings on memory or CPU.
>
Will do.
Thanks,
Amir.
