Solved How to develop a module that is loaded to the program?

[ogogon]

Colleagues, tell me, please, how to develop a module that is loaded to the program?

I would like it to load if necessary, complete its task and unload, releasing memory.

Is there some compact description talking about this?

Grateful for recommendations,
Ogogon.

 

[ralphbsz]

This is the section of the forum for FreeBSD internal development. I presume you are asking about how to develop a kernel module? In that case, start with the man page for kldload and kldunload. There are guides for how to develop device drivers in the handbook, and lots of online tutorials for how to develop kernel modules.

If this is for a userspace program, the mechanism is called DLL; there must be lots of information on the web, as this is a fairly standard problem. And in that case, your question is in the wrong section of the forum, but that's easy to fix.

Before you go down the path of implementing DLLs, think about easier ways to solve the problem. If you have swap space, then unused memory will simply be pushed to swap; in that case, unloading the DLL is not even necessary. And instead of dynamically linking into your program, consider splitting the work into two programs which then communicate via some IPC (inter-process communication) mechanism, which could be as easy as RPCs. Matter-of-fact, using RPCs has the advantage that in the future, you can move part of the program to another node (another computer), allowing you to use more memory, and scaling better.

 

[Geezer]

... the mechanism is called DLL ...

I had always called them shared executables, and thought that dll was a specifically a windowzy term. But I bow to your better judgement.

 

[SirDice]

I had always called them shared executables

They're not executables, they're libraries (you can't execute a library). So shared library is better.

and thought that dll was a specifically a windowzy term

DLL is short for Dynamic Link Library, which is what they are. Windows just used that abbreviation for their extensions (*.dll). But there's nothing specifically Windows about it.

 

[jbo@]

For future readers (just to add - not to correct):

So shared library is better.

These are sometimes also referred to as "dynamic libraries" (also outside of Windows).

Windows just used that abbreviation for their extensions (*.dll). But there's nothing specifically Windows about it.

There is nothing Windows specific about the concept of shared/dynamic libraries. However, the DLL format certainy IS specific to Windows or Windows-like systems/infrastructure.

 

[SirDice]

However, the DLL format certainy IS specific to Windows or Windows-like systems/infrastructure.

True. That's also the case for the way executables are stored. Windows uses PE, FreeBSD (any UNIX or UNIX-like system actually, except MacOS) uses ELF.

 

[_al]

Formally, so - shared object

​

ogogon,​

start with user space program - dlopen(3) and look for usage examples...

 

[Bobi B.]

Unless this module is going to be ran too frequently and finishes up very quickly, why don't you use fork(2) and exec(3) to run this task as a separate new process? This way OS will take care to reclaim the memory even if you have memory leaks, plus it will not kill controlling process in case of a crash of the child process.

 

[jbo@]

I think that at this point OP has to specify whether they want to create a module that a (userland) application can load during runtime (eg. a plugin) or whether they are looking for creating a kernel module.
Those are two separate things leading you down two different paths (although technically not dissimilar).

 

[zirias@]

If this is indeed about some sort of "plugin" mechanism, then ... yes, first think about YAGNI, you can achieve a lot with just a child process and e.g. a bidirectional pipe.

Then, if you really need plugins, my advice would be: define a plugin API. In C, this could simply be a struct of function pointers that's passed (by pointer) to some init function of the plugin.

It is possible to expose symbols of your binary to libraries loaded with dlopen(3), but I wouldn't recommend that. You're losing control over what a plugin can do ... and, it's not a simple thing on e.g. Windows, where you need to create an "import lib" for your main program.

 

[ogogon]

start with user space program - dlopen(3) and look for usage examples...

Thank you, this is definitely exactly what I was asking about.
I even found a guide written by your namesake, Andrey Kuzin, which simply and clearly describes how to use this functionality. There is something to move on from.

I thank everyone who took part in this discussion.
Ogogon.