On Wed, May 3, 2017 at 6:04 PM, David Howells wrote:
>
> Here are a set of patches to create a mount context prior to setting up a
> new mount, populating it with the parsed options/binary data and then
> effecting the mount.
>
> This allows namespaces and other information
On Wed, May 3, 2017 at 6:04 PM, David Howells wrote:
>
> Here are a set of patches to create a mount context prior to setting up a
> new mount, populating it with the parsed options/binary data and then
> effecting the mount.
>
> This allows namespaces and other information to be conveyed through
On Mon, May 8, 2017 at 10:35 AM, David Howells wrote:
>> Further, once you've created a superblock, what are you going to do with it
>> other than mount it? I suppose you could statfs it and we could add other
>> superblock manipulation functions, but this is normally done
On Mon, May 8, 2017 at 10:35 AM, David Howells wrote:
>> Further, once you've created a superblock, what are you going to do with it
>> other than mount it? I suppose you could statfs it and we could add other
>> superblock manipulation functions, but this is normally done by opening the
>>
David Howells wrote:
> > This patchset achieves this partly, but the separation is far from
> > crisp clear... First of all why is fsopen() creating a "mount
> > context"? It's suppsed to create a "superblock creation context".
>
> I've no particular objection to renaming
David Howells wrote:
> > This patchset achieves this partly, but the separation is far from
> > crisp clear... First of all why is fsopen() creating a "mount
> > context"? It's suppsed to create a "superblock creation context".
>
> I've no particular objection to renaming struct mount_context
On Fri, May 5, 2017 at 5:47 PM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> I'd argue with some design decisions here. One of the motivations for
>> doing the mount API overhaul is to create clear distinction between
>> separate functions like:
>>
On Fri, May 5, 2017 at 5:47 PM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> I'd argue with some design decisions here. One of the motivations for
>> doing the mount API overhaul is to create clear distinction between
>> separate functions like:
>>
>> - creating filesystem instance (aka
Miklos Szeredi wrote:
> I'd argue with some design decisions here. One of the motivations for
> doing the mount API overhaul is to create clear distinction between
> separate functions like:
>
> - creating filesystem instance (aka superblock)
>
> - attaching filesystem
Miklos Szeredi wrote:
> I'd argue with some design decisions here. One of the motivations for
> doing the mount API overhaul is to create clear distinction between
> separate functions like:
>
> - creating filesystem instance (aka superblock)
>
> - attaching filesystem instance into mount
On Wed, May 3, 2017 at 6:04 PM, David Howells wrote:
>
> Here are a set of patches to create a mount context prior to setting up a
> new mount, populating it with the parsed options/binary data and then
> effecting the mount.
Great work, thanks for taking this on.
I'd argue
On Wed, May 3, 2017 at 6:04 PM, David Howells wrote:
>
> Here are a set of patches to create a mount context prior to setting up a
> new mount, populating it with the parsed options/binary data and then
> effecting the mount.
Great work, thanks for taking this on.
I'd argue with some design
On Wed, 2017-05-03 at 17:50 +0100, David Howells wrote:
> Jeff Layton wrote:
>
> > > (*) Move the walk-from-root stuff that nfs has to generic code so that
> > > you
> > > can do something akin to:
> > >
> > > mount /dev/sda1:/foo/bar /mnt
> > >
> > > See
On Wed, 2017-05-03 at 17:50 +0100, David Howells wrote:
> Jeff Layton wrote:
>
> > > (*) Move the walk-from-root stuff that nfs has to generic code so that
> > > you
> > > can do something akin to:
> > >
> > > mount /dev/sda1:/foo/bar /mnt
> > >
> > > See nfs_follow_remote_path()
Jeff Layton wrote:
> > (*) Move the walk-from-root stuff that nfs has to generic code so that you
> > can do something akin to:
> >
> > mount /dev/sda1:/foo/bar /mnt
> >
> > See nfs_follow_remote_path() and mount_subtree(). This is slightly
> >
Jeff Layton wrote:
> > (*) Move the walk-from-root stuff that nfs has to generic code so that you
> > can do something akin to:
> >
> > mount /dev/sda1:/foo/bar /mnt
> >
> > See nfs_follow_remote_path() and mount_subtree(). This is slightly
> > tricky in NFS as we have to
On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote:
> Here are a set of patches to create a mount context prior to setting up a
> new mount, populating it with the parsed options/binary data and then
> effecting the mount.
>
> This allows namespaces and other information to be conveyed
On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote:
> Here are a set of patches to create a mount context prior to setting up a
> new mount, populating it with the parsed options/binary data and then
> effecting the mount.
>
> This allows namespaces and other information to be conveyed
Here are a set of patches to create a mount context prior to setting up a
new mount, populating it with the parsed options/binary data and then
effecting the mount.
This allows namespaces and other information to be conveyed through the
mount procedure. It also allows extra error information to
Here are a set of patches to create a mount context prior to setting up a
new mount, populating it with the parsed options/binary data and then
effecting the mount.
This allows namespaces and other information to be conveyed through the
mount procedure. It also allows extra error information to
20 matches
Mail list logo