On Thu, Dec 6, 2018 at 4:23 PM John Baldwin <j...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"