Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Feb 2013 19:17:56 +0300
From:      Sergey Kandaurov <pluknet@gmail.com>
To:        Craig Rodrigues <rodrigc@crodrigues.org>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: [patch] Proposal: move getmntopts(3) into libutil
Message-ID:  <CAE-mSOJQKK-Ox%2BLYgV%2B=kcCnnK3-cMattAGCTqQnC=cNAnHJ6g@mail.gmail.com>
In-Reply-To: <CAG=rPVcFak3D_Qn0gt7XhDEsBcPtyUbp1-2afUuMVbRVD7kv4Q@mail.gmail.com>
References:  <CAE-mSO%2B_JCAtzDbMfts8Ttgs32T7zNFZkYbGJ610v85=H-U=OA@mail.gmail.com> <CAG=rPVcFak3D_Qn0gt7XhDEsBcPtyUbp1-2afUuMVbRVD7kv4Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 26 February 2013 23:11, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
> On Tue, Feb 26, 2013 at 3:39 AM, Sergey Kandaurov <pluknet@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.

-- 
wbr,
pluknet



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-mSOJQKK-Ox%2BLYgV%2B=kcCnnK3-cMattAGCTqQnC=cNAnHJ6g>