Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Feb 2013 19:08:35 +0300
From:      Sergey Kandaurov <pluknet@gmail.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: [patch] Proposal: move getmntopts(3) into libutil
Message-ID:  <CAE-mSOKAtLeCqVm5Ep%2B7T7H24bnp-MDFE2GCB8f_yt5K1dnrEg@mail.gmail.com>
In-Reply-To: <20130226122039.GN2454@kib.kiev.ua>
References:  <CAE-mSO%2B_JCAtzDbMfts8Ttgs32T7zNFZkYbGJ610v85=H-U=OA@mail.gmail.com> <20130226122039.GN2454@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 26 February 2013 16:20, Konstantin Belousov <kostikbel@gmail.com> wrote:
> On Tue, Feb 26, 2013 at 02:39:26PM +0300, Sergey Kandaurov wrote:
>> Hi.
>>
>> The functions from sbin/mount/getmntopts.c are used in a bunch of other
>> stuff like mount_* utilities which have to suck them in as their own
>> functions in quite a hackish way. getmntopts.c copies are compiled in to
>> an every utility-consumer instead of being present in one place.  Looks
>> like getmntopts.c was brought together with mount_ufs.c in 4.4BSD-Lite.
>> After that other mount_* were converted to use getmntopts().
> Yes, this is ugly. On the other hand, compiling the functions into
> mount binaries makes them not to depend on the yet another library.
> It cannot be an argument for rejecting your patch, only a point to
> consider.

I'm afraid this is the price for the change. No better thoughts.

>> The attached patch moves them to the IMHO architecturally more correct
>> place: a separate library -lutil.
>> sbin/mount/mntopts.h            -> include/mntopts.h
> I think the mntopts.h should be moved to lib/libutil then, and installed
> by libutil Makefile.

That's reasonable, thanks. Patch is updated with your correction.
I have put it on freefall for convenience.
http://people.freebsd.org/~pluknet/patches/getmntopts.2.patch

>
>> sbin/mount/getmntopts.[3c]      -> lib/libutil/getmntopts.[3c]
> I assume that the move is done by 'svn mv' to preserve the history.

Yes. Unfortunately svn stat cannot nicely represent 'svn mv' ops.

-- 
wbr,
pluknet



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-mSOKAtLeCqVm5Ep%2B7T7H24bnp-MDFE2GCB8f_yt5K1dnrEg>