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
next prev parent 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