[patch] Proposal: move getmntopts(3) into libutil

Sergey Kandaurov pluknet at gmail.com
Wed Feb 27 16:17:57 UTC 2013

On 26 February 2013 23:11, Craig Rodrigues <rodrigc at crodrigues.org> wrote:
> On Tue, Feb 26, 2013 at 3:39 AM, Sergey Kandaurov <pluknet at gmail.com> wrote:
>> Hi.
>> External mount-like utilities may also have difficulties with building
>> to get getmntopts.c source as this requires /usr/src presence which is
>> in sync with installed world. Look how mount_fusefs from ports compiles:
>> # mount_fusefs needs mntopts.h and getmntopts.c from src/sbin/mount/
> I have no object in moving getmntopts.c to libutil.
> I'll give some history to some of this stuff, to the best of my ability.
> A few years ago, phk@ made a big change by introducing the nmount() system
> call to replace mount().
> Look at all mount-related commits around this time:
> http://lists.freebsd.org/pipermail/cvs-src/2004-December/author.html#36373
> This required changing every file system, and for old file systems which
> supported the "classic mount" cmount(),
> in each file system, the cmount() call had to internally call the nmount()
> code.
> In addition, phk made a pass to clean up all the userland mount programs to
> use nmount().  There was a lot
> of duplicated ("copy and pasted") code in various mount programs.  I helped
> in the effort to clean up some of the userland mount() programs.
> pjd@ proposed to make the main /sbin/mount load a shared library for each
> specific file system,
> and each shared library would have file-system specific mount logic.  For
> example:
> mount -t newfoofs  /dev/blah /mnt
> would internally do something like:
> dlopen("libmount_newfoofs",.....);
> phk@ opposed this approach, saying that it could lead to ABI/API problems,
> library mismatches, etc.
> So we kept the existing approach.  I modified /sbin/mount to by default use
> nmount() and only
> for certain file systems, exec an external mount program.
> phk's ideas for getmntopts.c was always to keep it as a place where
> "library-like" functions for mounting
> file systems would be kept.  To avoid library mismatch problems, it was kept
> has a C file directly compiled
> into the mount programs.

Sure, keeping it directly compiled has its own benefits.
Reading your mail is very educational, thank you.

> I have no problems keeping getmntopts.c in a separate library.  libutil is
> fine, or even a separate libmntutil (or whatever).
> Just keep in mind the issues that could possibly come up if there is a
> mismatch between
> the userland mount programs, and the library which contains getmntopts.c
> Other than that, you proposal is quite reasonable, and I have no issue with
> it.

Although libutil is already used with such binaries like mount and mountd,
library mismatch is a real concern. I will need to think somewhat more.
Thanks for looking at this.


More information about the freebsd-current mailing list