Hello,

How do you build only a static (.a) library for kernel modules.

The closest I got was with

obj-m:=whatever.o
whatever-objs:=lib.a
lib-y:=linuxdriverc.o
lib-y+=linuxdrivercpp.o
lib-y+=linuxdriverfile.o

that creates the .a library but also some whatever files. I just want the .a library ??? I'd like to name it too, but it looks like it only likes lib.a

TIA!!

Not sure how to do this. Have you looked at the makefile for the driver? Are you really wanting a static kernel? Sometimes known as a monolithic kernel.

What are you trying to do? What is the goal?

I want to create static libraries for creating kernel modules (drivers).

Static modules are somewhat an oxymoron. See what I mean?

You can't, as that doesn't make sense.
Libraries, dynamic or static, are for userspace executables. There simply is no loader-linker for the kernel, other than the kernel module loader.
Also for basic security, kernel modules are in a different format from userspace executables.

Regards

In another post I just did, I noticed if I build a .o separately and include it on the build, the symbols are found. If I take that same .o and put it in a static .a library and include that, it will link in the static lib but symbols are not found.

So it looks like for some reason, they only take .o files instead of .a files? There must be a way to have the Makefile automate creating the -objs references from extracting the .a library. I don't understand why they would not accept .a files for convenience and having a library of stable kernel module support files which will only be linked if used?

??

Seems like you're asking an XY question. You have a problem X, and came up with solution Y. But you're stuck making Y work, so you're asking for help on Y.
The fundamental issue is really solving X, not Y.

In this case X seems to be functionality that currently exists in userspace (as libraries), that you seem to want to put in kernel space (i.e. in a kernel module).
This is not a simple case of it's just machine code (as you assert in your other thread).
It's a matter of drawing a line between an unsecure userspace and a kernel executing in privileged mode.
You seem to have knowledge of executable file formats and library structures, but ignore the finer points of a secure kernel.

Some functionality can be clearly delegated to user or kernel space. If it's in the grey area, then you can implement it in the kernel, make a case for inclusion into the kernel, and then see if it is accepted by the community for mainline. Or your efforts may get rejected.
Since this functionality seems to already exist in userland rather than the kernel, a decision has already been made, so you may have an uphill battle to reverse that (e.g. your intent to relocate this functionality maybe misguided).

Who or what is this "they"?
As you've already been told, you simply cannot link kernel code with userspace code.
Security has precedence over convenience.

Regards

A static .a library is basically just an archive of object .o files. The linker takes care of selecting the object files needed based on symbols. So I don't see it as having anything to do with userspace.

To understand why "your request is absurd problematic," kindly consider that ... "in any operating system," there are two worlds:

• The "user-land" world that is kindly created by the operating-system kernel for the benefit of user programs ... and ...
• The "kernel" world, which is responsible for creating (the foundations of ...) that environment, but which therefore cannot partake of it.

"The kernel" is an always-resident program whose sole purpose is "to control the system hardware." Programs which run in this environment do not have access to any of the facilities that the kernel is responsible for creating ... nor to any of the "(user-land) system programs," such as ld the Linux loader, which user-land programs "can presume, and therefore utterly ignore."

If you want to create a kernel extension using a library, you must (a) ensure that the library code is statically linked to create an executable, and (b) that the resulting executable has no external references of any kind, nor(!) any expectations of being able to access any of the facilities which exist "in user-land."