A useful VFS change ...
Volker.Lendecke at SerNet.DE
Fri Mar 14 03:40:06 MDT 2014
On Thu, Mar 13, 2014 at 11:11:56PM -0400, Dustin Oprea wrote:
> On Wed, Feb 26, 2014 at 1:30 PM, 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 ?
> > Jeremy.
> It seems like this all just got dropped. Did we commit to make any changes
> that might make a light transparent module not so painful to implement?
Don't we still have examples/VFS/skel_opaque.c that does
exactly what Jeremy suggested?
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de
More information about the samba-technical