Programming

Well, Corona688 I see you have very large knowledge about writing linux drivers, so I would be very pleased to receive any help from you.
Let's go to the very begining. I have such files:

Code:

SimpleBin:
void main() {
 write(2, "Write\n", 6);
}

Code:

CallSimpleBin:
#include <stdlib.h>

void main() {
  system("./SimpleBin");
}

Running 'CallSimpleBin' I can call 'SimpleBin'.
Now I would like to call SimpleBin from module:

Code:

SimpleModule:
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

MODULE_LICENSE("GPL");

static int mymodule_init(void) {
 printk(KERN_ALERT "mymodule init\n");
/* here I would like to call SimpleBin */
 return 0;
}

static int mymodule_exit(void) {
 printk(KERN_ALERT "mymodule exit\n");
}
 
module_init(mymodule_init);
module_exit(mymodule_exit);

I also created static library:

Code:

SimpleLib:
void writeToScreen(char* str, int length) {
 write(2, str, length);
}

and I can call it from my user space application:

Code:

extern void writeToScreen(char* str, int length);

void main() {
 writeToScreen("Hi\n", 3);
}

it works. Unfortunatelly I cannot call 'writeToScreen' from module - it even could not compile.

Could you tell me some hints how I can do that?
I really apreciate any of your help.

I am confused. UEFI drivers are intended to extend firmware, have no OS dependence and have nothing to do with an operating system kernel.

How do you expect the kernel to load and interface with a UEFI driver? UEFI drivers can be 32 bit, 64-bit and more commonly EBC (Efi Byte Code). Have you read the Driver Writers Guide for UEFI?

Are you aware, for example, that 64-bit UEFI uses the Microsoft X64 calling convention whereas Linux uses the AMD64 calling convention.

Code:

//
// Unix/Linux arg passing:  RCX, RDX,  R8,  R9
//                                     RSI, RDI scratch 
//   UEFI/EFI arg passing:  RDI, RSI, RDX, RCX, R8, R9
//                                     Callee allocates 32 bytes on stack to spill registers
//                                     RSI, RDI callee-save
//
//   Mapping between registers
//
//   arg1   arg2    arg3   arg4   arg5     arg6      arg7       arg8
//
//   gcc:  (AMD64 ABI)
//   %rdi,  %rsi,  %rdx,  %rcx,    %r8,     %r9,     8(%rsp), 16(%rsp),  ....
//
//   efi:  (Microsoft X64)
//   %rcx,  %rdx,   %r8,   %r9,  32(%rsp), 40(%rsp), 48(%rsp), 56(%rsp), ....
//

You also need a UEFI-aware operating system of which there are a limited number out there. Recent 64-bit versions of Fedora/Redhat/etc.

If you describe exactly what you are trying to achieve - the big picture and not the how to - we can probably help you.

You are right. My friend is creating an UEFI emulator that redefine calls and do all necessary operations.
I need to take advantage of library already loaded (for concept purposes I assume library placed on HDD).
That solution is targeted to work on Redhat.

What I want for now is to make a kind of demo (concept).
It can be simple driver loading simple library and using it for e.g. printing to dmesg.

I've done enough work with them to know they are a severe challenge. I've occasionally had to alter some predefined values. I wrote a linux driver that prints 'hello world' to dmesg. I couldn't write a real driver yet.

But I know enough to tell you that windmills device drivers don't work that way. The kernel isn't going to reach into userspace, rip one function out of your userspace program, and run it raw because you don't get the same kind of stack; you don't get an ordinary heap; you don't get anything from libc; you don't get the same kind of files -- what does stderr even mean when you have no descriptor table? -- you don't get easy system calls like read() and write(); you don't even get easy, direct access to large amounts of available memory, and what memory there is is laid out in an alien way. The ease of all these things in userspace is a convincing illusion created by the kernel, more or less, and the way to use them is to be in userspace. Ordinary code can't run in kernel space any more than you could breathe in a vacuum.

Nearly all communication with the kernel is done through files and system calls instead. Your device driver can create a device file under /dev/ tied to your own kernel functions. someone opens it and your driver's read handler gets called, someone reads it and your device's read-handler gets called, etc. On boot, something in userspace could read from the ROM device and dump it into your special firmware-loading device file, and you'd be done.

Well, let me try to summarize what we get for now:

- it is impossible to load dll library / any other library from hdd/device's flash to RAM memory and take advantage of its functions by device driver (which I used to call just 'module'), isn't it?

- way to do that is e.g. mount (somehow) that dll / any other library as a device and use it in a way of reading / writing to that

Are there any other possibilities to solve that problem?

If by that you mean "directly run userspace code in kernel space", then yes, it's impossible. Otherwise... it really, really depends what the content of this thing is. You can't run just anything in kernel space, it has to be code compiled for your kernel's environment. It also really, really depends on how it's stored and where. The kernel's capable of reading firmware files on demand, I think, but from the sounds of it that's no file... If this dll is userspace code that won't help because it will still be userspace code and unable to operate in kernel space. Extract the userspace code in userspace. Use the userspace code in userspace. Communicate data, not program instructions, in and out of the kernel.

Hmm... so if I create simple doing nothing (or printing text to dmesg) kernel space dynamic library, save it wherever on HDD and try to use from device driver - would that work?
Is there a way to create dynamic library in kernel space and call it from device driver?