Date: Thu, 6 Dec 2018 16:39:43 -0700 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r341657 - in head: etc/mtree sbin/nvmecontrol share/man/man7 Message-ID: <CANCZdfr5kvGeQjuZiC7FBpJfo2c7S1HmMVSSAqXLYo0UoihHRA@mail.gmail.com> In-Reply-To: <0b90e8e4-ce69-9caf-21f2-bb76bdfd2635@FreeBSD.org> References: <201812062258.wB6MwQKb026274@repo.freebsd.org> <0b90e8e4-ce69-9caf-21f2-bb76bdfd2635@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 6, 2018 at 4:23 PM John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr5kvGeQjuZiC7FBpJfo2c7S1HmMVSSAqXLYo0UoihHRA>