svn commit: r341657 - in head: etc/mtree sbin/nvmecontrol share/man/man7
Warner Losh
imp at bsdimp.com
Thu Dec 6 23:39:55 UTC 2018
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
More information about the svn-src-head
mailing list