On Wed, Mar 20, 2013 at 08:07:12AM +0100, Jan Synacek wrote:
On 03/19/2013 06:15 PM, Karel Zak wrote:
> On Tue, Mar 19, 2013 at 10:38:16AM +0100, Jan Synacek wrote:
>> On 03/19/2013 09:30 AM, Jan Safranek wrote:
>>> On 03/18/2013 03:31 PM, Jan Synacek wrote:
>>>> [ Description (
>>>> "If not NULL, specifies a directory path where a part of
the original "
>>>> "file hierarchy is remounted. Also signifies use of a bind
mount." ) ]
>>>> string BindDir;
>>>
>>> Huh? What is 'original hierarchy'? Is it source directory of the
bind
>>> mount? Can we merge it with FileSystemType='bind' and
>>> FileSystemSpec='/bind/source'?
>>
>> Unfortunate wording, I admit. I'll try to fix that.
>>
>> I think that FileSystemType=bind makes no sense as bind is not a filesystem
>
> type is "none", "bind" is mount flag
Makes sense. Can there be any other case where the type can be 'none'?
Sure, MS_BIND, MS_MOVE, MS_REMOUNT and MS_PROPAGATION (slave, private, ...)
ignore filesystem type.
Note that the mount(2) syscall has exactly specified semantic for VFS operations
(move, bind, propagation flags, etc), BUT for everything else (filesystems
specific options) it is pretty liberal. For filesystem specific operations all
depends on filesystem driver - see for example variability of the mount source
string for fuse, nfs, cifs, ...
My understanding is that the information contained in /etc/mtab or
/proc/self/mountinfo will be exposed through the model (class instances).
Furthermore, we will allow manipulation of the information through some of the
methods. Our job is to keep the information synchronized correctly.
Cool. (BTW, /proc/self/{mounts,mountinfo} files are poll()-able, so
you can monitor all changes).
How do you plan to handle namespaces? I mean.. for example "get the list
of the mounted filesystems" is namespaces specific.
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com