svn commit: r341657 - in head: etc/mtree sbin/nvmecontrol share/man/man7

[Warner Losh]

On Thu, Dec 6, 2018 at 4:23 PM John Baldwin <jhb at freebsd.org> wrote:

> On 12/6/18 2:58 PM, Warner Losh wrote:
> > Author: imp
> > Date: Thu Dec  6 22:58:26 2018
> > New Revision: 341657
> > URL: https://svnweb.freebsd.org/changeset/base/341657
> >
> > Log:
> >   Dynamically load .so modules to expand functionality
> >
> >   o Dynamically load all the .so files found in /libexec/nvmecontrol and
> >     /usr/local/libexec/nvmecontrol.
> >   o Link nvmecontrol -rdynamic so that its symbols are visible to the
> >     libraries we load.
> >   o Create concatinated linker sets that we dynamically expand.
> >   o Add the linked-in top and logpage linker sets to the mirrors for them
> >     and add those sets to the mirrors when we load a new .so.
> >   o Add some macros to help hide the names of the linker sets.
> >   o Update the man page.
> >
> >   Sponsored by: Netflix
> >   Differential Revision: https://reviews.freebsd.org/D18455
>
> While linker sets are cool and all (and I used them in mfiutil and mptutil
> to build the command tree), it seems like in this case where you want to
> deal
> with dynamic registration, etc. you would be better served by just using
> something like STL C++ containers to maintain the command tree.  New
> commands can be associated with a static object whose constructor invokes a
> "register_command" function or some such.  You could also do this in C via
> explicit ctor attributes, but just using static constructors in C++ seems
> like
> a less obscure way to do this.
>

I thought about doing it that way. I had it mostly coded up, but it turned
out to be a bigger pain and required more source changes between modules
and non-module builds.

I didn't want to make C++ anything. And the ctor stuff runs at 'random
times' that I didn't want to deal with.

And linker sets aren't that obscure.

So in the end, I went with linker sets because it seemed like the right
tool for the job.

Warner