2018-02-04 03:22:01 +01:00
|
|
|
// Matrix Construct
|
|
|
|
//
|
|
|
|
// Copyright (C) Matrix Construct Developers, Authors & Contributors
|
|
|
|
// Copyright (C) 2016-2018 Jason Volk <jason@zemos.net>
|
|
|
|
//
|
|
|
|
// Permission to use, copy, modify, and/or distribute this software for any
|
|
|
|
// purpose with or without fee is hereby granted, provided that the above
|
|
|
|
// copyright notice and this permission notice is present in all copies. The
|
|
|
|
// full license for this software is available in the LICENSE file.
|
2007-01-25 07:40:21 +01:00
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
#include <boost/filesystem.hpp>
|
|
|
|
#include <boost/dll.hpp>
|
|
|
|
|
|
|
|
namespace filesystem = boost::filesystem;
|
|
|
|
namespace load_mode = boost::dll::load_mode;
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
#include <ircd/asio.h>
|
2018-04-24 10:21:05 +02:00
|
|
|
#include <ircd/mods/mapi.h> // Module's internal API
|
2018-02-09 08:35:42 +01:00
|
|
|
#include "mods.h"
|
2017-12-02 22:07:55 +01:00
|
|
|
|
2019-01-06 02:18:08 +01:00
|
|
|
ircd::log::log
|
|
|
|
ircd::mods::log
|
|
|
|
{
|
|
|
|
"modules", 'M'
|
|
|
|
};
|
|
|
|
|
2018-12-09 00:17:13 +01:00
|
|
|
decltype(ircd::mods::enable)
|
|
|
|
ircd::mods::enable
|
|
|
|
{
|
|
|
|
{ "name", "ircd.mods.enable" },
|
|
|
|
{ "default", true },
|
2018-12-09 01:15:22 +01:00
|
|
|
{ "persist", false },
|
2018-12-09 00:17:13 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
decltype(ircd::mods::autoload)
|
|
|
|
ircd::mods::autoload
|
|
|
|
{
|
|
|
|
{ "name", "ircd.mods.autoload" },
|
|
|
|
{ "default", true },
|
2018-12-09 01:15:22 +01:00
|
|
|
{ "persist", false },
|
2018-12-09 00:17:13 +01:00
|
|
|
};
|
|
|
|
|
2019-04-10 06:27:45 +02:00
|
|
|
//
|
|
|
|
// (internal) dlsym hooker
|
|
|
|
//
|
|
|
|
|
|
|
|
extern "C" void *
|
|
|
|
__libc_dlsym(void *, const char *);
|
|
|
|
|
2019-05-04 00:15:09 +02:00
|
|
|
#ifdef IRCD_MODS_HOOK_DLSYM
|
2019-04-10 06:27:45 +02:00
|
|
|
extern "C" void *
|
|
|
|
dlsym(void *const handle,
|
|
|
|
const char *const symbol)
|
|
|
|
{
|
2019-05-04 00:15:09 +02:00
|
|
|
#ifdef RB_DEBUG_MODS_HOOK_DLSYM
|
|
|
|
ircd::log::debug
|
|
|
|
{
|
|
|
|
ircd::mods::log, "handle:%p symbol lookup '%s'",
|
|
|
|
handle,
|
|
|
|
symbol
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
2019-04-10 06:27:45 +02:00
|
|
|
return __libc_dlsym(handle, symbol);
|
|
|
|
}
|
2019-05-04 00:15:09 +02:00
|
|
|
#endif
|
2019-04-10 06:27:45 +02:00
|
|
|
|
2018-10-24 21:15:42 +02:00
|
|
|
//
|
|
|
|
// mods::mod
|
|
|
|
//
|
|
|
|
|
|
|
|
decltype(ircd::mods::mod::loading)
|
|
|
|
ircd::mods::mod::loading
|
|
|
|
{};
|
|
|
|
|
|
|
|
decltype(ircd::mods::mod::unloading)
|
|
|
|
ircd::mods::mod::unloading
|
|
|
|
{};
|
|
|
|
|
|
|
|
decltype(ircd::mods::mod::loaded)
|
|
|
|
ircd::mods::mod::loaded
|
|
|
|
{};
|
|
|
|
|
|
|
|
// Allows module to communicate static destruction is taking place when mapi::header
|
|
|
|
// destructs. If dlclose() returns without this being set, dlclose() lied about really
|
|
|
|
// unloading the module. That is considered a "stuck" module.
|
|
|
|
bool
|
|
|
|
ircd::mapi::static_destruction;
|
|
|
|
|
2019-03-24 21:18:03 +01:00
|
|
|
const char *const
|
|
|
|
ircd::mapi::import_section_names[]
|
|
|
|
{
|
|
|
|
IRCD_MODULE_EXPORT_CODE_SECTION,
|
|
|
|
IRCD_MODULE_EXPORT_DATA_SECTION,
|
|
|
|
nullptr
|
|
|
|
};
|
|
|
|
|
2018-10-24 21:15:42 +02:00
|
|
|
//
|
|
|
|
// mods::mod::mod
|
|
|
|
//
|
|
|
|
|
2019-03-15 00:11:28 +01:00
|
|
|
static void (*their_terminate)();
|
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
ircd::mods::mod::mod(std::string path,
|
2018-10-24 21:15:42 +02:00
|
|
|
const load_mode::type &mode)
|
|
|
|
try
|
2019-02-08 05:51:38 +01:00
|
|
|
:path
|
|
|
|
{
|
|
|
|
std::move(path)
|
|
|
|
}
|
|
|
|
,mode
|
|
|
|
{
|
|
|
|
mode
|
|
|
|
}
|
2019-03-24 21:18:03 +01:00
|
|
|
,exports{[this]
|
2019-02-09 12:05:19 +01:00
|
|
|
{
|
2019-03-24 21:18:03 +01:00
|
|
|
std::map<std::string, std::string> ret;
|
|
|
|
for(auto section(mapi::import_section_names); *section; ++section)
|
|
|
|
ret.merge(mods::mangles(this->path, *section));
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}()}
|
2019-02-08 05:51:38 +01:00
|
|
|
,handle{[this]
|
2018-10-24 21:15:42 +02:00
|
|
|
{
|
2018-12-16 02:22:30 +01:00
|
|
|
// Can't interrupt this ctx during the dlopen() as long as exceptions
|
|
|
|
// coming out of static inits are trouble (which they are at this time).
|
|
|
|
// Note this device will throw any pending interrupts during construction
|
|
|
|
// and destruction but not during its lifetime.
|
|
|
|
const ctx::uninterruptible ui;
|
|
|
|
|
2019-03-15 00:11:28 +01:00
|
|
|
// The existing terminate handler is saved here for restoration.
|
|
|
|
their_terminate = std::get_terminate();
|
|
|
|
|
2018-12-16 02:29:31 +01:00
|
|
|
// This will be the terminate handler installed during the dlopen() and
|
|
|
|
// uninstalled after it completes.
|
2019-03-15 00:11:28 +01:00
|
|
|
const auto ours{[]
|
2018-10-24 21:15:42 +02:00
|
|
|
{
|
2019-03-15 00:11:28 +01:00
|
|
|
// Immediately go back to their terminate so if our terminate
|
2019-05-09 03:28:16 +02:00
|
|
|
// handler stack calls terminate it won't loop.
|
2019-03-15 00:11:28 +01:00
|
|
|
std::set_terminate(their_terminate);
|
2018-10-24 21:15:42 +02:00
|
|
|
log::critical
|
|
|
|
{
|
|
|
|
log, "Error during the static construction of module (fatal) :%s",
|
|
|
|
what(std::current_exception())
|
|
|
|
};
|
2019-03-15 00:11:28 +01:00
|
|
|
}};
|
2018-10-24 21:15:42 +02:00
|
|
|
|
2019-05-09 03:28:16 +02:00
|
|
|
// Reference this instance at the top of the loading stack. When this
|
|
|
|
// scope unwinds the module is loaded and static initialization has
|
|
|
|
// taken place; note that our user's init function is not executed
|
|
|
|
// until later after mods::mod constructs.
|
2018-12-16 02:29:31 +01:00
|
|
|
loading.emplace_front(this);
|
|
|
|
const unwind pop_loading{[this]
|
2018-10-24 21:15:42 +02:00
|
|
|
{
|
|
|
|
assert(loading.front() == this);
|
|
|
|
loading.pop_front();
|
|
|
|
}};
|
|
|
|
|
2018-12-16 02:29:31 +01:00
|
|
|
// Set the terminate handler for the duration of the dlopen().
|
2018-10-24 21:15:42 +02:00
|
|
|
std::set_terminate(ours);
|
2019-03-15 00:11:28 +01:00
|
|
|
const unwind pop_terminate{[]
|
2018-12-16 02:29:31 +01:00
|
|
|
{
|
2019-03-15 00:11:28 +01:00
|
|
|
std::set_terminate(their_terminate);
|
2018-12-16 02:29:31 +01:00
|
|
|
}};
|
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
return boost::dll::shared_library
|
|
|
|
{
|
|
|
|
this->path, this->mode
|
|
|
|
};
|
2018-10-24 21:15:42 +02:00
|
|
|
}()}
|
|
|
|
,_name
|
|
|
|
{
|
|
|
|
unpostfixed(handle.location().filename().string())
|
|
|
|
}
|
|
|
|
,_location
|
|
|
|
{
|
|
|
|
handle.location().string()
|
|
|
|
}
|
|
|
|
,header
|
|
|
|
{
|
|
|
|
&handle.get<mapi::header>(mapi::header_symbol_name)
|
|
|
|
}
|
|
|
|
{
|
|
|
|
log::debug
|
|
|
|
{
|
2019-01-06 02:18:08 +01:00
|
|
|
log, "Loaded static segment of '%s' @ `%s'",
|
2018-10-24 21:15:42 +02:00
|
|
|
name(),
|
|
|
|
location(),
|
|
|
|
};
|
|
|
|
|
|
|
|
if(unlikely(!header))
|
|
|
|
throw error
|
|
|
|
{
|
|
|
|
"Unexpected null header"
|
|
|
|
};
|
|
|
|
|
2018-10-25 22:03:07 +02:00
|
|
|
if(header->magic != IRCD_MAPI_MAGIC)
|
2018-10-24 21:15:42 +02:00
|
|
|
throw error
|
|
|
|
{
|
2019-05-02 02:39:17 +02:00
|
|
|
"Bad magic [%04X] need: [%04X]", header->magic, IRCD_MAPI_MAGIC
|
2018-10-24 21:15:42 +02:00
|
|
|
};
|
|
|
|
|
2019-04-19 01:53:47 +02:00
|
|
|
if(header->version != IRCD_MAPI_VERSION)
|
|
|
|
throw error
|
|
|
|
{
|
|
|
|
"Unknown MAPI version [%u] expecting: [%u]", header->version, IRCD_MAPI_VERSION
|
|
|
|
};
|
|
|
|
|
2019-04-19 01:54:23 +02:00
|
|
|
if(header->serial < IRCD_MAPI_SERIAL)
|
|
|
|
throw error
|
|
|
|
{
|
|
|
|
"Module '%s' serial=%u is expired; expecting serial >= %u. This module was probably removed"
|
|
|
|
" from the project and you should delete it from the installation directory.",
|
|
|
|
name(),
|
|
|
|
header->serial,
|
|
|
|
IRCD_MAPI_SERIAL
|
|
|
|
};
|
|
|
|
|
2018-10-24 21:15:42 +02:00
|
|
|
// Tell the module where to find us.
|
|
|
|
header->self = this;
|
|
|
|
|
|
|
|
// Set some basic metadata
|
2018-10-25 22:03:07 +02:00
|
|
|
(*this)["name"] = name();
|
|
|
|
(*this)["location"] = location();
|
2018-10-24 21:15:42 +02:00
|
|
|
|
|
|
|
if(!loading.empty())
|
|
|
|
{
|
|
|
|
const auto &m(mod::loading.front());
|
|
|
|
m->children.emplace_back(this);
|
|
|
|
log::debug
|
|
|
|
{
|
|
|
|
log, "Module '%s' recursively loaded by '%s'",
|
|
|
|
name(),
|
2019-02-08 05:51:38 +01:00
|
|
|
m->name()
|
2018-10-24 21:15:42 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
// Without init exception, the module is now considered loaded.
|
|
|
|
assert(!loaded.count(name()));
|
|
|
|
loaded.emplace(name(), this);
|
|
|
|
}
|
|
|
|
catch(const boost::system::system_error &e)
|
|
|
|
{
|
2019-04-04 02:37:09 +02:00
|
|
|
if(is(e.code(), std::errc::bad_file_descriptor))
|
|
|
|
handle_ebadf(e.what());
|
2018-10-24 21:15:42 +02:00
|
|
|
|
2018-11-09 06:18:39 +01:00
|
|
|
throw_system_error(e);
|
2018-10-24 21:15:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
ircd::mods::mod::~mod()
|
|
|
|
noexcept try
|
|
|
|
{
|
|
|
|
unload();
|
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
log::critical
|
|
|
|
{
|
|
|
|
log, "Module @%p unload: %s",
|
|
|
|
(const void *)this,
|
|
|
|
e.what()
|
|
|
|
};
|
|
|
|
|
|
|
|
if(!ircd::debugmode)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::mod::unload()
|
|
|
|
{
|
|
|
|
if(!handle.is_loaded())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if(mods::unloading(name()))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Mark this module in the unloading state.
|
|
|
|
unloading.emplace_front(this);
|
|
|
|
|
|
|
|
log::debug
|
|
|
|
{
|
|
|
|
log, "Attempting unload module '%s' @ `%s'",
|
|
|
|
name(),
|
|
|
|
location()
|
|
|
|
};
|
|
|
|
|
|
|
|
// Call the user's unloading function here.
|
2018-10-25 22:03:07 +02:00
|
|
|
assert(header);
|
|
|
|
assert(header->meta);
|
|
|
|
if(header->meta->fini)
|
|
|
|
header->meta->fini();
|
2018-10-24 21:15:42 +02:00
|
|
|
|
|
|
|
// Save the children! dlclose() does not like to be called recursively during static
|
|
|
|
// destruction of a module. The mod ctor recorded all of the modules loaded while this
|
|
|
|
// module was loading so we can reverse the record and unload them here.
|
|
|
|
// Note: If the user loaded more modules from inside their module they will have to dtor them
|
|
|
|
// before 'static destruction' does. They can also do that by adding them to this vector.
|
|
|
|
std::for_each(rbegin(this->children), rend(this->children), []
|
|
|
|
(mod *const &ptr)
|
|
|
|
{
|
|
|
|
// Only trigger an unload if there is one reference remaining to the module,
|
|
|
|
// in addition to the reference created by invoking shared_from() right here.
|
|
|
|
if(shared_from(*ptr).use_count() <= 2)
|
|
|
|
ptr->unload();
|
|
|
|
});
|
|
|
|
|
|
|
|
log::debug
|
|
|
|
{
|
|
|
|
log, "Attempting static unload for '%s' @ `%s'",
|
|
|
|
name(),
|
|
|
|
location()
|
|
|
|
};
|
|
|
|
|
|
|
|
mapi::static_destruction = false;
|
|
|
|
handle.unload();
|
|
|
|
assert(!handle.is_loaded());
|
|
|
|
loaded.erase(name());
|
|
|
|
unloading.remove(this);
|
|
|
|
if(!mapi::static_destruction)
|
|
|
|
{
|
|
|
|
log.critical("Module \"%s\" is stuck and failing to unload.", name());
|
|
|
|
log.critical("Module \"%s\" may result in undefined behavior if not fixed.", name());
|
|
|
|
}
|
|
|
|
else log::info
|
|
|
|
{
|
|
|
|
log, "Unloaded '%s'", name()
|
|
|
|
};
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-10-25 22:03:07 +02:00
|
|
|
ircd::string_view &
|
|
|
|
ircd::mods::mod::operator[](const string_view &key)
|
|
|
|
{
|
|
|
|
assert(header);
|
|
|
|
return header->operator[](key);
|
|
|
|
}
|
|
|
|
|
|
|
|
const ircd::string_view &
|
|
|
|
ircd::mods::mod::operator[](const string_view &key)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
assert(header);
|
|
|
|
return header->operator[](key);
|
|
|
|
}
|
|
|
|
|
2019-04-04 02:37:09 +02:00
|
|
|
void
|
|
|
|
ircd::mods::handle_ebadf(const string_view &what)
|
|
|
|
{
|
|
|
|
const auto pos(what.find("undefined symbol: "));
|
|
|
|
if(pos == std::string_view::npos)
|
|
|
|
return;
|
|
|
|
|
2019-05-01 23:53:27 +02:00
|
|
|
const auto msg(what.substr(pos));
|
|
|
|
const auto mangled(between(msg, ": ", ")"));
|
|
|
|
const auto demangled(demangle(mangled));
|
2019-04-04 02:37:09 +02:00
|
|
|
throw undefined_symbol
|
|
|
|
{
|
2019-05-01 23:53:27 +02:00
|
|
|
"undefined symbol '%s' (%s)",
|
|
|
|
demangled,
|
|
|
|
mangled
|
2019-04-04 02:37:09 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2018-10-25 22:03:07 +02:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
|
|
|
// mods/mapi.h
|
|
|
|
//
|
|
|
|
|
2019-04-19 02:15:17 +02:00
|
|
|
//
|
|
|
|
// metablock
|
|
|
|
//
|
|
|
|
|
|
|
|
ircd::mapi::metablock::metablock(const string_view &description,
|
|
|
|
init_func &&init_func,
|
|
|
|
fini_func &&fini_func)
|
|
|
|
:init{std::move(init_func)}
|
|
|
|
,fini{std::move(fini_func)}
|
|
|
|
,meta
|
2019-01-25 23:53:13 +01:00
|
|
|
{
|
2019-04-19 02:15:17 +02:00
|
|
|
{ "description", description }
|
2019-01-25 23:53:13 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2019-04-19 02:15:17 +02:00
|
|
|
//
|
|
|
|
// header
|
|
|
|
//
|
|
|
|
|
2019-01-25 23:53:13 +01:00
|
|
|
ircd::mapi::header::~header()
|
|
|
|
noexcept
|
|
|
|
{
|
|
|
|
static_destruction = true;
|
|
|
|
}
|
|
|
|
|
2018-10-25 22:03:07 +02:00
|
|
|
ircd::mapi::header::operator
|
|
|
|
mods::mod &()
|
|
|
|
{
|
|
|
|
assert(self);
|
|
|
|
return *self;
|
|
|
|
}
|
|
|
|
|
|
|
|
ircd::mapi::header::operator
|
|
|
|
const mods::mod &()
|
|
|
|
const
|
|
|
|
{
|
|
|
|
assert(self);
|
|
|
|
return *self;
|
|
|
|
}
|
|
|
|
|
|
|
|
ircd::string_view &
|
|
|
|
ircd::mapi::header::operator[](const string_view &key)
|
|
|
|
{
|
|
|
|
assert(meta);
|
|
|
|
return meta->meta[key];
|
|
|
|
}
|
|
|
|
|
|
|
|
const ircd::string_view &
|
|
|
|
ircd::mapi::header::operator[](const string_view &key)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
assert(meta);
|
|
|
|
return meta->meta.at(key);
|
|
|
|
}
|
|
|
|
|
2018-03-24 04:31:09 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
2018-02-09 08:35:42 +01:00
|
|
|
//
|
2018-03-24 05:40:20 +01:00
|
|
|
// mods/mods.h (misc util)
|
2018-03-24 04:31:09 +01:00
|
|
|
//
|
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
std::forward_list<std::string>
|
|
|
|
ircd::mods::available()
|
2018-03-24 04:31:09 +01:00
|
|
|
{
|
2018-03-24 05:40:20 +01:00
|
|
|
std::forward_list<std::string> ret;
|
|
|
|
for(const auto &dir : paths) try
|
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
for(const auto &filepath : fs::ls(dir))
|
|
|
|
{
|
|
|
|
if(!is_module(filepath, std::nothrow))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
std::string relpath
|
|
|
|
{
|
|
|
|
fs::relative(fs::path_scratch, dir, filepath)
|
|
|
|
};
|
|
|
|
|
|
|
|
ret.emplace_front(unpostfixed(std::move(relpath)));
|
|
|
|
}
|
2018-03-24 05:40:20 +01:00
|
|
|
}
|
|
|
|
catch(const filesystem::filesystem_error &e)
|
|
|
|
{
|
2018-08-31 05:56:03 +02:00
|
|
|
log::warning
|
|
|
|
{
|
|
|
|
log, "Module path [%s]: %s",
|
|
|
|
dir,
|
|
|
|
e.what()
|
|
|
|
};
|
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
continue;
|
|
|
|
}
|
2018-03-24 04:31:09 +01:00
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
return ret;
|
|
|
|
}
|
2018-02-09 08:35:42 +01:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
std::string
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::fullpath(const string_view &name)
|
2017-08-16 22:15:14 +02:00
|
|
|
{
|
2018-03-24 05:40:20 +01:00
|
|
|
std::vector<std::string> why;
|
2019-02-08 05:51:38 +01:00
|
|
|
const auto path
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
search(name, why)
|
|
|
|
};
|
2017-12-02 22:07:55 +01:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
if(likely(!path.empty()))
|
|
|
|
return path;
|
|
|
|
|
|
|
|
for(const auto &str : why)
|
|
|
|
log::error
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
log, "candidate for module '%s' failed: %s",
|
|
|
|
name,
|
|
|
|
str
|
2018-03-24 05:40:20 +01:00
|
|
|
};
|
2017-12-02 22:07:55 +01:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
throw error
|
|
|
|
{
|
|
|
|
"No valid module by name `%s'", name
|
|
|
|
};
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
2018-03-24 05:40:20 +01:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
//
|
|
|
|
// search()
|
|
|
|
//
|
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
std::string
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::search(const string_view &name)
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2018-03-24 05:40:20 +01:00
|
|
|
std::vector<std::string> why;
|
|
|
|
return search(name, why);
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
std::string
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::search(const string_view &name,
|
2018-03-24 05:40:20 +01:00
|
|
|
std::vector<std::string> &why)
|
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
const std::string path
|
2018-03-25 23:32:24 +02:00
|
|
|
{
|
|
|
|
postfixed(name)
|
|
|
|
};
|
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
if(!fs::is_relative(path))
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2018-03-24 05:40:20 +01:00
|
|
|
why.resize(why.size() + 1);
|
2018-03-25 23:32:24 +02:00
|
|
|
return is_module(path, why.back())?
|
|
|
|
std::string{name}:
|
|
|
|
std::string{};
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
2018-03-24 05:40:20 +01:00
|
|
|
else for(const auto &dir : paths)
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
const string_view parts[2]
|
|
|
|
{
|
|
|
|
dir, path
|
|
|
|
};
|
|
|
|
|
|
|
|
const auto full
|
|
|
|
{
|
|
|
|
fs::path_string(parts)
|
|
|
|
};
|
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
why.resize(why.size() + 1);
|
2019-02-08 05:51:38 +01:00
|
|
|
if(is_module(full, why.back()))
|
|
|
|
return full;
|
2018-03-24 05:40:20 +01:00
|
|
|
}
|
2016-11-29 16:23:38 +01:00
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
return {};
|
|
|
|
}
|
2017-12-02 22:07:55 +01:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
//
|
|
|
|
// is_module
|
|
|
|
//
|
2017-12-02 22:07:55 +01:00
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
bool
|
2019-02-09 05:40:08 +01:00
|
|
|
ircd::mods::is_module(const string_view &path)
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2019-02-09 05:40:08 +01:00
|
|
|
std::string why;
|
|
|
|
return is_module(path, why);
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2019-02-08 05:51:38 +01:00
|
|
|
ircd::mods::is_module(const string_view &path,
|
2019-02-09 05:40:08 +01:00
|
|
|
std::nothrow_t)
|
2018-03-24 05:40:20 +01:00
|
|
|
try
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2019-03-01 02:58:09 +01:00
|
|
|
std::string why;
|
|
|
|
return is_module(path, why);
|
2018-03-24 05:40:20 +01:00
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2017-12-02 22:07:55 +01:00
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
bool
|
2019-02-09 05:40:08 +01:00
|
|
|
ircd::mods::is_module(const string_view &path,
|
|
|
|
std::string &why)
|
2018-03-24 05:40:20 +01:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
static const auto &header_name
|
|
|
|
{
|
|
|
|
mapi::header_symbol_name
|
|
|
|
};
|
|
|
|
|
|
|
|
const auto syms
|
|
|
|
{
|
|
|
|
symbols(path)
|
|
|
|
};
|
|
|
|
|
|
|
|
const auto it
|
|
|
|
{
|
|
|
|
std::find(begin(syms), end(syms), header_name)
|
|
|
|
};
|
|
|
|
|
2019-02-09 05:40:08 +01:00
|
|
|
if(it != end(syms))
|
|
|
|
return true;
|
2017-12-02 22:07:55 +01:00
|
|
|
|
2019-02-09 05:40:08 +01:00
|
|
|
why = fmt::snstringf
|
|
|
|
{
|
|
|
|
256, "`%s': has no MAPI header (%s)", path, header_name
|
|
|
|
};
|
|
|
|
|
|
|
|
return false;
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
//
|
|
|
|
// utils by name
|
|
|
|
//
|
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
bool
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::available(const string_view &name)
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2018-03-24 05:40:20 +01:00
|
|
|
using filesystem::path;
|
2017-12-02 22:07:55 +01:00
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
std::vector<std::string> why;
|
|
|
|
return !search(name, why).empty();
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
|
|
|
|
2018-10-23 19:59:16 +02:00
|
|
|
bool
|
|
|
|
ircd::mods::unloading(const string_view &name)
|
|
|
|
{
|
|
|
|
const auto &list(mod::unloading);
|
|
|
|
return end(list) != std::find_if(begin(list), end(list), [&name]
|
|
|
|
(const auto *const &mod)
|
|
|
|
{
|
|
|
|
assert(mod);
|
|
|
|
return mod->name() == name;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::loading(const string_view &name)
|
|
|
|
{
|
|
|
|
const auto &list(mod::loading);
|
|
|
|
return end(list) != std::find_if(begin(list), end(list), [&name]
|
|
|
|
(const auto *const &mod)
|
|
|
|
{
|
|
|
|
assert(mod);
|
|
|
|
return mod->name() == name;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
bool
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::loaded(const string_view &name)
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2018-03-24 05:40:20 +01:00
|
|
|
return mod::loaded.count(name);
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
//
|
|
|
|
// utils by mod reference
|
|
|
|
//
|
|
|
|
|
2019-02-09 08:47:07 +01:00
|
|
|
template<> uint8_t &
|
|
|
|
ircd::mods::get<uint8_t>(mod &mod,
|
|
|
|
const string_view &sym)
|
|
|
|
try
|
|
|
|
{
|
2019-02-09 12:05:19 +01:00
|
|
|
const auto it
|
|
|
|
{
|
2019-02-10 00:51:55 +01:00
|
|
|
mod.exports.find(sym)
|
2019-02-09 12:05:19 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
std::string s
|
|
|
|
{
|
2019-02-10 00:51:55 +01:00
|
|
|
it == end(mod.exports)?
|
2019-02-09 12:05:19 +01:00
|
|
|
std::string{sym}:
|
|
|
|
it->second
|
|
|
|
};
|
|
|
|
|
|
|
|
return mod.handle.get<uint8_t>(s);
|
2019-02-09 08:47:07 +01:00
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
throw undefined_symbol
|
|
|
|
{
|
|
|
|
"Could not find symbol '%s' (%s) in module '%s'",
|
|
|
|
demangle(sym),
|
|
|
|
sym,
|
|
|
|
mod.name()
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
template<>
|
|
|
|
const uint8_t &
|
|
|
|
ircd::mods::get<const uint8_t>(const mod &mod,
|
|
|
|
const string_view &sym)
|
|
|
|
try
|
|
|
|
{
|
2019-02-09 12:05:19 +01:00
|
|
|
const auto it
|
|
|
|
{
|
2019-02-10 00:51:55 +01:00
|
|
|
mod.exports.find(sym)
|
2019-02-09 12:05:19 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
std::string s
|
|
|
|
{
|
2019-02-10 00:51:55 +01:00
|
|
|
it == end(mod.exports)?
|
2019-02-09 12:05:19 +01:00
|
|
|
std::string{sym}:
|
|
|
|
it->second
|
|
|
|
};
|
|
|
|
|
|
|
|
return mod.handle.get<const uint8_t>(s);
|
2019-02-09 08:47:07 +01:00
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
throw undefined_symbol
|
|
|
|
{
|
|
|
|
"Could not find symbol '%s' (%s) in module '%s'",
|
|
|
|
demangle(sym),
|
|
|
|
sym,
|
|
|
|
mod.name()
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2018-10-23 20:15:21 +02:00
|
|
|
template<> uint8_t *
|
|
|
|
ircd::mods::ptr<uint8_t>(mod &mod,
|
|
|
|
const string_view &sym)
|
2019-02-09 08:47:07 +01:00
|
|
|
noexcept try
|
2018-10-23 20:15:21 +02:00
|
|
|
{
|
|
|
|
return &mod.handle.get<uint8_t>(std::string{sym});
|
|
|
|
}
|
2019-02-09 08:47:07 +01:00
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
return nullptr;
|
|
|
|
}
|
2018-10-23 20:15:21 +02:00
|
|
|
|
|
|
|
template<>
|
|
|
|
const uint8_t *
|
|
|
|
ircd::mods::ptr<const uint8_t>(const mod &mod,
|
|
|
|
const string_view &sym)
|
2019-02-09 08:47:07 +01:00
|
|
|
noexcept try
|
2018-10-23 20:15:21 +02:00
|
|
|
{
|
|
|
|
return &mod.handle.get<const uint8_t>(std::string{sym});
|
|
|
|
}
|
2019-02-09 08:47:07 +01:00
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
return nullptr;
|
|
|
|
}
|
2018-10-23 20:15:21 +02:00
|
|
|
|
2019-02-10 00:51:55 +01:00
|
|
|
const std::map<std::string, std::string> &
|
|
|
|
ircd::mods::exports(const mod &mod)
|
|
|
|
{
|
|
|
|
return mod.exports;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::has(const mod &mod,
|
|
|
|
const string_view &name)
|
|
|
|
{
|
|
|
|
return mod.handle.has(std::string{name});
|
|
|
|
}
|
|
|
|
|
2018-10-23 20:15:21 +02:00
|
|
|
bool
|
|
|
|
ircd::mods::unloading(const mod &mod)
|
|
|
|
{
|
|
|
|
const auto &list(mod::unloading);
|
|
|
|
return end(list) != std::find(begin(list), end(list), &mod);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::loading(const mod &mod)
|
|
|
|
{
|
|
|
|
const auto &list(mod::loading);
|
|
|
|
return end(list) != std::find(begin(list), end(list), &mod);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::loaded(const mod &mod)
|
|
|
|
{
|
|
|
|
return mod.handle.is_loaded();
|
|
|
|
}
|
|
|
|
|
|
|
|
ircd::string_view
|
|
|
|
ircd::mods::name(const mod &mod)
|
|
|
|
{
|
|
|
|
return mod.name();
|
|
|
|
}
|
|
|
|
|
|
|
|
ircd::string_view
|
|
|
|
ircd::mods::path(const mod &mod)
|
|
|
|
{
|
|
|
|
return mod.location();
|
|
|
|
}
|
|
|
|
|
2018-09-14 03:02:10 +02:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
|
|
|
// mods/import.h
|
|
|
|
//
|
|
|
|
|
|
|
|
decltype(ircd::mods::imports)
|
|
|
|
ircd::mods::imports
|
|
|
|
{};
|
|
|
|
|
2019-02-10 02:38:46 +01:00
|
|
|
std::string
|
|
|
|
ircd::mods::make_target_name(const string_view &name,
|
|
|
|
const string_view &demangled)
|
|
|
|
{
|
|
|
|
if(!startswith(name, "ircd::"))
|
|
|
|
return std::string{};
|
|
|
|
|
|
|
|
const auto classname
|
|
|
|
{
|
|
|
|
rsplit(name, "::").first
|
|
|
|
};
|
|
|
|
|
|
|
|
thread_local char buf[1024];
|
|
|
|
const string_view mem_fun_ptr{fmt::sprintf
|
|
|
|
{
|
|
|
|
buf, "%s::*)(", classname
|
|
|
|
}};
|
|
|
|
|
|
|
|
const auto signature
|
|
|
|
{
|
|
|
|
split(demangled, "(")
|
|
|
|
};
|
|
|
|
|
|
|
|
const auto prototype
|
|
|
|
{
|
|
|
|
lstrip(signature.second, mem_fun_ptr)
|
|
|
|
};
|
|
|
|
|
|
|
|
auto ret{fmt::snstringf
|
|
|
|
{
|
2019-03-24 21:18:03 +01:00
|
|
|
4096, "%s%s%s",
|
|
|
|
name,
|
|
|
|
prototype? "(" : "",
|
|
|
|
prototype
|
2019-02-10 02:38:46 +01:00
|
|
|
}};
|
|
|
|
|
|
|
|
ret.shrink_to_fit();
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
|
|
|
// mods/sym_ptr.h
|
|
|
|
//
|
|
|
|
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::sym_ptr::sym_ptr(const string_view &modname,
|
|
|
|
const string_view &symname)
|
2018-03-24 05:40:20 +01:00
|
|
|
:sym_ptr
|
|
|
|
{
|
|
|
|
module(modname), symname
|
|
|
|
}
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2018-03-26 00:25:32 +02:00
|
|
|
ircd::mods::sym_ptr::sym_ptr(mod &mod,
|
|
|
|
const string_view &symname)
|
|
|
|
:sym_ptr
|
|
|
|
{
|
|
|
|
module(shared_from(mod)), symname
|
|
|
|
}
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
ircd::mods::sym_ptr::sym_ptr(module module,
|
2018-03-25 23:32:24 +02:00
|
|
|
const string_view &symname)
|
2018-03-24 05:40:20 +01:00
|
|
|
:std::weak_ptr<mod>
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2018-03-24 05:40:20 +01:00
|
|
|
module
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
2019-02-09 08:47:07 +01:00
|
|
|
,ptr
|
2018-03-24 05:40:20 +01:00
|
|
|
{
|
2019-02-09 08:47:07 +01:00
|
|
|
&module.get<uint8_t>(symname)
|
|
|
|
}
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
2019-02-09 08:47:07 +01:00
|
|
|
assert(ptr);
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
2018-03-24 05:40:20 +01:00
|
|
|
// mods/module.h
|
2016-11-16 03:41:12 +01:00
|
|
|
//
|
2016-09-10 01:14:29 +02:00
|
|
|
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::module::module(const string_view &name)
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
try
|
2016-11-16 03:41:12 +01:00
|
|
|
:std::shared_ptr<mod>{[&name]
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
static const load_mode::type flags
|
|
|
|
{
|
2019-05-04 00:58:20 +02:00
|
|
|
load_mode::rtld_global |
|
|
|
|
load_mode::rtld_deepbind
|
2019-02-08 05:51:38 +01:00
|
|
|
};
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
// Search for loaded module and increment the reference counter for this handle if loaded.
|
2018-02-23 03:57:55 +01:00
|
|
|
auto it(mod::loaded.find(name));
|
2016-11-16 03:41:12 +01:00
|
|
|
if(it != end(mod::loaded))
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
auto &mod(*it->second);
|
|
|
|
return shared_from(mod);
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
auto path
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
fullpath(name)
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
};
|
|
|
|
|
2018-08-31 05:56:03 +02:00
|
|
|
log::debug
|
|
|
|
{
|
|
|
|
log, "Attempting to load '%s' @ `%s'",
|
|
|
|
name,
|
2019-02-08 05:51:38 +01:00
|
|
|
path
|
2018-08-31 05:56:03 +02:00
|
|
|
};
|
2018-03-25 23:32:24 +02:00
|
|
|
|
2018-03-26 00:42:52 +02:00
|
|
|
const auto ret
|
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
std::make_shared<mod>(std::move(path), flags)
|
2018-03-26 00:42:52 +02:00
|
|
|
};
|
|
|
|
|
2019-03-01 00:51:44 +01:00
|
|
|
assert(ret);
|
|
|
|
assert(ret->header);
|
|
|
|
assert(ret->header->meta);
|
|
|
|
if(!ret || !ret->header)
|
|
|
|
throw panic
|
|
|
|
{
|
|
|
|
"Unknown module error."
|
|
|
|
};
|
|
|
|
|
2018-03-26 00:42:52 +02:00
|
|
|
// Call the user-supplied init function well after fully loading and
|
|
|
|
// construction of the module. This way the init function sees the module
|
|
|
|
// as loaded and can make shared_ptr references, etc.
|
2019-03-01 00:51:44 +01:00
|
|
|
if(ret->header->meta && ret->header->meta->init)
|
2018-10-25 22:03:07 +02:00
|
|
|
ret->header->meta->init();
|
2018-03-26 00:42:52 +02:00
|
|
|
|
2018-08-31 05:56:03 +02:00
|
|
|
log::info
|
|
|
|
{
|
|
|
|
log, "Loaded module %s v%u \"%s\"",
|
|
|
|
ret->name(),
|
|
|
|
ret->header->version,
|
|
|
|
!ret->description().empty()?
|
|
|
|
ret->description():
|
2018-09-13 14:43:30 +02:00
|
|
|
"<no description>"_sv
|
2018-08-31 05:56:03 +02:00
|
|
|
};
|
2018-03-26 00:42:52 +02:00
|
|
|
|
|
|
|
return ret;
|
2016-11-16 03:41:12 +01:00
|
|
|
}()}
|
|
|
|
{
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
2018-08-31 05:56:03 +02:00
|
|
|
log::error
|
|
|
|
{
|
2019-05-01 23:53:27 +02:00
|
|
|
log, "Failed to load '%s' :%s",
|
2018-08-31 05:56:03 +02:00
|
|
|
name,
|
|
|
|
e.what()
|
|
|
|
};
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
}
|
|
|
|
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::string_view
|
2016-11-29 16:23:38 +01:00
|
|
|
ircd::mods::module::path()
|
2016-11-16 03:41:12 +01:00
|
|
|
const
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2018-03-26 00:25:32 +02:00
|
|
|
const mod &mod(*this);
|
|
|
|
return mods::path(mod);
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::string_view
|
2016-11-29 16:23:38 +01:00
|
|
|
ircd::mods::module::name()
|
2016-11-16 03:41:12 +01:00
|
|
|
const
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2018-03-26 00:25:32 +02:00
|
|
|
const mod &mod(*this);
|
|
|
|
return mods::name(mod);
|
2016-11-29 16:23:38 +01:00
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
bool
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::module::has(const string_view &name)
|
2017-12-02 22:07:55 +01:00
|
|
|
const
|
|
|
|
{
|
2018-03-26 00:25:32 +02:00
|
|
|
const mod &mod(*this);
|
|
|
|
return mods::has(mod, name);
|
2017-03-21 04:38:34 +01:00
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
2018-03-24 05:40:20 +01:00
|
|
|
// mods/symbols.h
|
2016-11-16 03:41:12 +01:00
|
|
|
//
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
std::vector<std::string>
|
2019-02-09 05:39:30 +01:00
|
|
|
ircd::mods::find_symbol(const string_view &symbol,
|
|
|
|
const string_view §ion)
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
const auto av
|
|
|
|
{
|
|
|
|
available()
|
|
|
|
};
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
std::vector<std::string> ret;
|
2019-02-09 05:39:30 +01:00
|
|
|
std::copy_if(begin(av), end(av), std::back_inserter(ret), [&symbol, §ion]
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
(const auto &name)
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
2019-02-09 05:39:30 +01:00
|
|
|
return has_symbol(name, symbol, section);
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
});
|
2016-06-18 07:52:16 +02:00
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
return ret;
|
|
|
|
}
|
2016-03-20 12:00:20 +01:00
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
bool
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::has_symbol(const string_view &name,
|
2019-02-09 05:39:30 +01:00
|
|
|
const string_view &symbol,
|
|
|
|
const string_view §ion)
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2019-02-10 00:36:51 +01:00
|
|
|
if(name.empty() || symbol.empty())
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
return false;
|
2016-03-20 12:00:20 +01:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
const auto syms
|
|
|
|
{
|
2019-02-10 00:36:51 +01:00
|
|
|
symbols(name, section)
|
2019-02-08 05:51:38 +01:00
|
|
|
};
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
return std::find(begin(syms), end(syms), symbol) != end(syms);
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
|
|
|
|
2019-02-09 08:18:46 +01:00
|
|
|
std::map<std::string, std::string>
|
2019-02-08 05:51:38 +01:00
|
|
|
ircd::mods::mangles(const string_view &path)
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
|
|
|
return mangles(mods::symbols(path));
|
|
|
|
}
|
|
|
|
|
2019-02-09 08:18:46 +01:00
|
|
|
std::map<std::string, std::string>
|
2019-02-08 05:51:38 +01:00
|
|
|
ircd::mods::mangles(const string_view &path,
|
2018-03-25 23:32:24 +02:00
|
|
|
const string_view §ion)
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
|
|
|
return mangles(mods::symbols(path, section));
|
|
|
|
}
|
|
|
|
|
2019-02-09 08:18:46 +01:00
|
|
|
std::map<std::string, std::string>
|
2017-12-02 22:07:55 +01:00
|
|
|
ircd::mods::mangles(const std::vector<std::string> &symbols)
|
|
|
|
{
|
2019-02-09 08:18:46 +01:00
|
|
|
std::map<std::string, std::string> ret;
|
2017-12-02 22:07:55 +01:00
|
|
|
for(const auto &sym : symbols) try
|
|
|
|
{
|
|
|
|
ret.emplace(demangle(sym), sym);
|
|
|
|
}
|
|
|
|
catch(const not_mangled &e)
|
|
|
|
{
|
|
|
|
ret.emplace(sym, sym);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
2019-02-08 05:51:38 +01:00
|
|
|
ircd::mods::symbols(const string_view &path)
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2016-10-26 08:16:33 +02:00
|
|
|
return info<std::vector<std::string>>(path, []
|
|
|
|
(boost::dll::library_info &info)
|
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
return info.symbols();
|
2016-10-26 08:16:33 +02:00
|
|
|
});
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
2019-02-08 05:51:38 +01:00
|
|
|
ircd::mods::symbols(const string_view &path,
|
2018-03-25 23:32:24 +02:00
|
|
|
const string_view §ion)
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2019-02-09 05:39:30 +01:00
|
|
|
if(!section)
|
|
|
|
return symbols(path);
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
return info<std::vector<std::string>>(path, [§ion]
|
2016-10-26 08:16:33 +02:00
|
|
|
(boost::dll::library_info &info)
|
|
|
|
{
|
2018-03-25 23:32:24 +02:00
|
|
|
return info.symbols(std::string{section});
|
2016-10-26 08:16:33 +02:00
|
|
|
});
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
2019-02-08 05:51:38 +01:00
|
|
|
ircd::mods::sections(const string_view &path)
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
|
|
|
return info<std::vector<std::string>>(path, []
|
2016-10-26 08:16:33 +02:00
|
|
|
(boost::dll::library_info &info)
|
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
return info.sections();
|
2016-10-26 08:16:33 +02:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
template<class R,
|
|
|
|
class F>
|
|
|
|
R
|
2019-02-10 00:36:51 +01:00
|
|
|
ircd::mods::info(const string_view &p,
|
2016-10-26 08:16:33 +02:00
|
|
|
F&& closure)
|
2019-01-14 01:55:52 +01:00
|
|
|
try
|
2016-10-26 08:16:33 +02:00
|
|
|
{
|
2019-02-10 00:36:51 +01:00
|
|
|
const auto path
|
|
|
|
{
|
|
|
|
fs::is_relative(p)?
|
|
|
|
fs::_path(fullpath(p)):
|
|
|
|
fs::_path(p)
|
|
|
|
};
|
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
boost::dll::library_info info
|
|
|
|
{
|
2019-02-10 00:36:51 +01:00
|
|
|
path
|
2019-02-08 05:51:38 +01:00
|
|
|
};
|
|
|
|
|
2016-10-26 08:16:33 +02:00
|
|
|
return closure(info);
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
2019-01-14 01:55:52 +01:00
|
|
|
catch(const filesystem::filesystem_error &e)
|
|
|
|
{
|
|
|
|
throw fs::error
|
|
|
|
{
|
2019-02-10 00:36:51 +01:00
|
|
|
e, "%s", p
|
2019-01-14 01:55:52 +01:00
|
|
|
};
|
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
2018-03-24 05:40:20 +01:00
|
|
|
// mods/paths.h
|
2016-11-16 03:41:12 +01:00
|
|
|
//
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
decltype(ircd::mods::prefix)
|
|
|
|
ircd::mods::prefix
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
fs::path(fs::MODULES)
|
|
|
|
};
|
2018-03-24 05:40:20 +01:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
decltype(ircd::mods::suffix)
|
|
|
|
ircd::mods::suffix
|
2018-03-24 05:40:20 +01:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
boost::dll::shared_library::suffix().string()
|
2018-03-24 05:40:20 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
decltype(ircd::mods::paths)
|
|
|
|
ircd::mods::paths
|
|
|
|
{};
|
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
//
|
|
|
|
// util
|
|
|
|
//
|
2018-03-24 05:40:20 +01:00
|
|
|
|
|
|
|
std::string
|
2019-02-08 05:51:38 +01:00
|
|
|
ircd::mods::unpostfixed(std::string path)
|
2018-03-24 05:40:20 +01:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
if(fs::extension(fs::path_scratch, path) == suffix)
|
|
|
|
return fs::extension(fs::path_scratch, path, string_view{});
|
2018-03-25 23:32:24 +02:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
return std::move(path);
|
2018-03-25 23:32:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
std::string
|
2019-02-08 05:51:38 +01:00
|
|
|
ircd::mods::postfixed(std::string path)
|
2018-03-25 23:32:24 +02:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
return fs::extension(fs::path_scratch, path) != suffix?
|
|
|
|
path + suffix:
|
|
|
|
path;
|
2018-03-24 05:40:20 +01:00
|
|
|
}
|
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
std::string
|
|
|
|
ircd::mods::prefix_if_relative(std::string path)
|
2018-03-24 05:40:20 +01:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
if(!fs::is_relative(path))
|
|
|
|
return std::move(path);
|
2018-03-24 05:40:20 +01:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
const string_view parts[2]
|
|
|
|
{
|
|
|
|
prefix, path
|
|
|
|
};
|
2016-11-16 03:41:12 +01:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
return fs::path_string(parts);
|
2017-12-02 22:07:55 +01:00
|
|
|
}
|
2016-11-16 03:41:12 +01:00
|
|
|
|
2018-03-24 05:40:20 +01:00
|
|
|
//
|
|
|
|
// paths::paths
|
|
|
|
//
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
ircd::mods::paths::paths()
|
|
|
|
:std::vector<std::string>
|
|
|
|
{{
|
2019-02-08 05:51:38 +01:00
|
|
|
mods::prefix
|
2016-11-16 03:41:12 +01:00
|
|
|
}}
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::paths::add(const string_view &dir)
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
const auto path
|
2018-03-25 23:32:24 +02:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
prefix_if_relative(dir)
|
2018-03-25 23:32:24 +02:00
|
|
|
};
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
if(!fs::exists(path))
|
2018-12-22 00:33:18 +01:00
|
|
|
throw fs::error
|
2018-03-24 05:40:20 +01:00
|
|
|
{
|
2018-12-22 00:33:18 +01:00
|
|
|
make_error_code(std::errc::no_such_file_or_directory),
|
|
|
|
"path `%s' (%s) does not exist",
|
|
|
|
dir,
|
2019-02-08 05:51:38 +01:00
|
|
|
path
|
2018-03-24 05:40:20 +01:00
|
|
|
};
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
|
2019-02-08 05:51:38 +01:00
|
|
|
if(!fs::is_dir(path))
|
2018-12-22 00:33:18 +01:00
|
|
|
throw fs::error
|
2018-03-24 05:40:20 +01:00
|
|
|
{
|
2019-03-17 01:21:42 +01:00
|
|
|
make_error_code(std::errc::not_a_directory),
|
2018-12-22 00:33:18 +01:00
|
|
|
"path `%s' (%s) is not a directory",
|
|
|
|
dir,
|
2019-02-08 05:51:38 +01:00
|
|
|
path
|
2018-03-24 05:40:20 +01:00
|
|
|
};
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
if(added(dir))
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
return false;
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
emplace(begin(), dir);
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
bool
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::paths::add(const string_view &dir,
|
2016-11-16 03:41:12 +01:00
|
|
|
std::nothrow_t)
|
|
|
|
try
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
return add(dir);
|
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
2018-08-31 05:56:03 +02:00
|
|
|
log::error
|
|
|
|
{
|
2019-05-01 23:53:27 +02:00
|
|
|
log, "Failed to add path `%s' :%s",
|
|
|
|
dir,
|
|
|
|
e.what()
|
2018-08-31 05:56:03 +02:00
|
|
|
};
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
return false;
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::paths::del(const string_view &dir)
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
2019-02-08 05:51:38 +01:00
|
|
|
std::remove(begin(), end(), prefix_if_relative(dir));
|
2016-11-16 03:41:12 +01:00
|
|
|
return true;
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
bool
|
2018-03-25 23:32:24 +02:00
|
|
|
ircd::mods::paths::added(const string_view &dir)
|
2016-11-16 03:41:12 +01:00
|
|
|
const
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
return std::find(begin(), end(), dir) != end();
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
}
|