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>