Re: SUJ and "mount" reporting

On Mon, May 31, 2010 at 04:44:07AM -0600, Scott Long wrote:
> MNT_* flags need to be deprecated, and the attributes passed in both directions as key-value pairs.  I don't know if anyone else has thought about this and what it means for backwards compatibility.
> 
> Scott


Hi,

I've thought about it. :)

For new code, we really don't need to pass MNT_* flags from
userland to kernel.  I think most of the mount_* binaries
and fsck_* binaries have been converted to nmount() and do not
need to pass MNT_* flags from userland to kernel.  (They may still do so, but it is not entirely
necessary that they do so. :)

People introduce new MNT_* flags (such as MNT_GJOURNAL) used in userland for one main purpose now:
   mount -p

The implementation of the "-p" option to mount uses the flags
on a mounted file system to print out the human-readable list of mount options.


I would like to see the following:

(1)  In the kernel, we need a new API, callable via nmount().
     For example, if a user passes an iovec with something like:

     nmount("/dev/ad1sb", "get mount options");

     when the nmount() call returns, the iovec passed into the call
     should be populated with the stringified mount options.

     This can be done similarly to how I populate the "errmsg" error string
     if an nmount() call fails.

     By reusing nmount(), we do not introduce any new kernel interfaces.

(2)  In the mount(8) binary, we can
     rewrite the "mount -p" implementation to use  nmount(......, "get mount options");
     instead of checking the MNT_ flags on the file system.


If we did this, we would be able to do things like
identify if an NFS mount has been mounted via TCP or UDP,
just by using "mount -p".

I've been meaning to work on this for quite a while, but
haven't had the time.

If someone wants to help out on this, let me know.

-- 
Craig Rodrigues
rodrigc_at_crodrigues.org