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

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_at_ 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_at_ 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_at_ 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.

-- 
wbr,
pluknet