A useful VFS change ...

[Jeremy Allison]

On Wed, Feb 26, 2014 at 10:40:43AM -0800, Richard Sharpe wrote:
> On Wed, Feb 26, 2014 at 10:36 AM, Jeremy Allison <jra at samba.org> wrote:
> > On Wed, Feb 26, 2014 at 10:32:13AM -0800, Richard Sharpe wrote:
> >> On Wed, Feb 26, 2014 at 10:30 AM, Jeremy Allison <jra at samba.org> wrote:
> >> > On Wed, Feb 26, 2014 at 10:28:37AM -0800, Richard Sharpe wrote:
> >> >> Hi folks,
> >> >>
> >> >> In discussions with Dustin an idea was proposed for a way to make VFS
> >> >> writing easier for those who are accessing user-space file systems (of
> >> >> which we are seeing more and more these days.)
> >> >>
> >> >> One of the problems is that a user-space file system cannot, in
> >> >> general, fall through to vfs_defaults, because, except in limited
> >> >> cases, these call into the kernel via syscalls with FDs that make no
> >> >> sense to the kernel.
> >> >>
> >> >> This requires that the VFS write write code for every VFS function
> >> >> with many of them simply returning ENOTSUP.
> >> >>
> >> >> By adding a set of flags to the structure we could simplify things.
> >> >> Perhaps we should go back to the old idea of OPAQUE vs TRANSPARENT VFS
> >> >> modules. The default is TRANSPARENT, but if the writer sets the OPAQUE
> >> >> bit, the infrastructure will return ENOTSUP if a call is made to a VFS
> >> >> function that is not implemented.
> >> >
> >> > Rather than complicating the structure, shouldn't we
> >> > just create a new 'defaults' module that always returns
> >> > ENOTSUP for every call, that OEMs can then stack their
> >> > user-space filesystem modules on top of ?
> >>
> >> That would do the job as well.
> >
> > Might be a bit easier, we just copy the skel_opaque.c
> > module and change the returns..
> 
> Indeed, but we also have to make waf work correctly for the
> examples/VFS directory as well :-)

Yeah, that's s different problem though :-).