Re: [Review] Fixes to the VFS layer

[Francois Tigeot <ftigeot@xxxxxxxxxxxx>]

Thanks for the remarks Alex,

Alex Hornung wrote:
> as I said previously on IRC I disagree with this approach to statfs and
> hence to your first two patches. You should be using the statfs entry
> point and not inspect the statfs structure in the mount point.
>
> For that, you need to simply fix the right thing, which would be the
> VOP_STATFS entry of nullfs and make it populate the fields you need as
> you expect.

To be honest, I had forgotten about this conversation; I'll try to 
replace the direct struct mount accesses by the use of VOP_STATFS.

> That the stat field in the mount point is not populated as you would
> like it is *not* a bug and doesn't really need fixing, you should be
> using the right approach instead, one that is using the API instead of
> raw accesses.

When I tried to use the STATFS function API, it didn't work as expected 
and caused kernel panics.
I now see that this function was not completely implemented for tmpfs.

What is the rationale for not using the statfs information present in 
struct mount ? It was in a very convenient location...

> Regarding the other patch, please make sure that you don't break the
> initrd infrastructure in the process. Haven't looked in detail at your
> patch, but it looks relatively dangerous in assuming where the root
> mount is in the mount list.

This is the part where I'm the less sure of what I should be doing. The 
code was copied verbatim from the start_init() function; I assumed it 
was correct in the first place.
I didn't remove it from there; when I tried to I once again got problems 
with an unitialized namecache layer, but this time later in the boot 
process.

Best Regards,

> > While working on the vfs-quota branch, I found some problems in the existing
> > kernel VFS code.
> >
> > The attached patches correspond to local commits I have created to fix them.
> > I'm not too sure if what I've done is ideal, and I'd like these patches
> > to be reviewed before pushing them to master (or not).

--
Francois Tigeot