public inbox for util-linux@vger.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Werner Baumann <werner.baumann@onlinehome.de>
Cc: util-linux@vger.kernel.org
Subject: Re: Bug: libmount essentially undocumented
Date: Fri, 28 Mar 2014 09:52:00 +0100	[thread overview]
Message-ID: <20140328085200.GE23464@x2.net.home> (raw)
In-Reply-To: <20140327194912.33d74236@ginster.fritz.box>

On Thu, Mar 27, 2014 at 07:49:12PM +0100, Werner Baumann wrote:
> * mnt_context_prepare_mount ()
> "int mnt_context_prepare_mount (struct libmnt_context *cxt);
>  Prepare context for mounting, unnecessary for mnt_context_mount().
>  cxt : context
>  Returns : negative number on error, zero on success"
> Is this all I have to do. How does this function know which file system
> I want to mount?

I'm not sure that we need this kind of babysitting, it's obvious that
there is probably a function to specify a filesystem.

> More confusing: A inline comment in the nfs mount program (maintained
> by the maintainer of libmount) says:

I'm author not maintainer of the helper.

> "The libmount strictly uses only options from fstab if running in restricted mode (suid, non-root user). This is done in mnt_context_prepare_mount() by default."
> Why is this not mentioned in the documentation of
> mnt_context_prepare_mount? And how does the library know whether it
> is in "restricted mode"? mnt_context_apply_fstab too has no
> information on this.

See mnt_context_is_restricted() ...

> * mnt_context_set_options ()
> "int mnt_context_set_options (struct libmnt_context *cxt, const char
> *optstr);
>  cxt : mount context
>  optstr : comma delimited mount options
>  Returns : 0 on success, negative number in case of error."
> What will happen when this function is applied a second time? Will the
> new options replace the old ones, or will the new options be merged
> into the old ones? Naming the function "*_set_*" indicates replacement,

mnt_context_set_options()
mnt_context_append_options()

> for merging I would expect a name with "_add_". But looking at the nfs
> code it seems to add the new optons and not replace the old ones.

it replaces old one, read the code again

> * By chance I noticed a new file on my system: "/var/run/mount/utab".
>   Not worth mentioning? Funnily comments in the nfs code mention
>   "/dev/.mount/utab" which I can't find on my system. Maybe udev will
>   create it on occasion or is it just the same moved to another
>   location?

well, the comment in NFS ode is obsolete, it's "/var/run/mount/utab".

> I will stop the examples here. It's the same with almost all functions
> in libmount. From the documentation you can't know what a function will
> do, leave alone what preconditions must be met before applying a
> function on the mount context.
> 
> I consider this bug serious because it renders the library unusable.

I'm absolutely agree that the documentation is really not perfect,
unfortunately now I have another priorities than improve the
documentation. 

Anyway it's open source, you can send patches, the docs is generated
from source code comments.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2014-03-28  8:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 18:49 Bug: libmount essentially undocumented Werner Baumann
2014-03-28  8:52 ` Karel Zak [this message]
2014-03-28 16:32   ` Dale R. Worley
2014-03-28 23:59     ` Sami Kerola
2014-04-03 23:52       ` Phillip Susi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140328085200.GE23464@x2.net.home \
    --to=kzak@redhat.com \
    --cc=util-linux@vger.kernel.org \
    --cc=werner.baumann@onlinehome.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox