9

I have a big system written mostly in C that was running in user space up till now. Now I need to compile the code as a kernel module. For that, afaik, I should at least rewrite the code and replace functions as malloc, calloc, free, printf with their kernel equivalents, because those are solely user-space functions. The problem is, however, that I don't have the source code to some custom-made libraries used in the system, and those libraries call malloc etc. inside their functions. So, basically, I might need to reimplement the whole library.

Now the question: will it be a really dirty hack, if I'd write my own implementation of malloc as a wrapper around kmalloc, something like this:

void *malloc(size_t size) {
    return kmalloc(size, GFP_USER);
}

Then link this implementation to the system code, which will eliminate all the Unknown symbol in module errors.

Actually I thought that this would be a common problem and someone would have already written such a kmalloc wrapper, but I've been googling for a couple of days now and found nothing useful.

EDIT: The reason for doing this is that the system I'm talking about was a realtime application running on VxWorks realtime OS and now we want to port it to be used on Linux RTAI, where the apps mostly run in kernel space. But I guess there is a possibility to have real-time in user space as well, so, I should probably do as Mike suggested and separate the code into kernel and user-space parts and communicate between them with shared memory.

eris
  • 129
  • 6
  • I just saw [this hack](http://stackoverflow.com/a/14728092/912144) for gcc which may be useful to you. – Shahbaz Feb 08 '13 at 12:32
  • 9
    Normally people try to move things out from the kernel, instead of the other way around. My personal experience is that if you think you're needing to make a kernel module of your program, then you're probably doing it wrong. – Some programmer dude Feb 08 '13 at 12:34
  • @JoachimPileborg he probably got to this thinking it will be faster in kernel space – Ulterior Feb 08 '13 at 12:37
  • 2
    @Ulterior - of course the more stuff you shove in the kernel the less deterministic it becomes. – Mike Feb 08 '13 at 12:39
  • I agree with Joachim Pileborg. Moving a big application into kernel space is a huge mistake. I'll rather suggest profiling it wisely, and only optimize the few (if any) significant bottlenecks around some syscalls. – Basile Starynkevitch Feb 08 '13 at 12:40
  • 1
    @eris, can you explain what are your motives for this? There may be a better way. – Shahbaz Feb 08 '13 at 12:40
  • You're asking a question about "how", which anyone with kernel experience will respond to with "why?". – Art Feb 08 '13 at 13:21

2 Answers2

9

I've never seen this done before. I did have to do something similar at a previous job (in our phones, for power savings reasons, we had to port a portion of code from user space from the kernel) but that's how I did it.. I took a portion of the code and moved it, and a small portion at that.

When I did it I changed the user space calls to kernel calls because of a number of reasons two primary ones:

  1. It was less confusing that way (others looking at the code didn't have to wonder why I was calling "malloc" from the kernel)

  2. malloc and kmalloc don't work exactly the same. What I mean by that is

    2a. kmalloc takes a flags parameter, in your example above you hardcoded it. What if you decide later that you want to change it in some places and not others? (assuming you have a number of different places where you get dynamic memory).

    2b. kmalloc doesn't give you memory in the same way as malloc. malloc() will give you the number of bytes you pass in as size_t size. kmalloc() on the other hand, is in the kernel and thus is dealing with the physical memory of the system, which is available only in page-sized chunks; thus when you call kmalloc() you are going to get only certain predefined, fixed-size byte arrays. if you're not aware of this, you might ask for just over a particular chunk and thus get much more memory than you need... a direct port of your code won't protect you from that.

    2c. The header files have to change too. Obviously you can't include <stdlib.h> in the kernel, so just because you "wrapped" the malloc call, you still have to go around replacing header files.

quick example of my point in 2b above:

void * stuff;
stuff = kmalloc(1,GFP_KERNEL);
printk("I got: %zu bytes of memory\n", ksize(stuff));
kfree(stuff);

To show the actual amount of memory allocated:

[90144.702588] I got: 32 bytes of memory

anyway... technically, how you describe it, should work fine. Both take a size_t and return a void * so it should work; but be aware that the more code you move into the kernel the less deterministic things become, and that malloc()<=>kmalloc() isn't as 1:1 as it seems.

Mike
  • 47,263
  • 29
  • 113
  • 177
0

Trying to make my RTAI code compilable in both user and kernel spaces (as well as working with POSIX), I have developed URT which essentially does what you are asking. It's a lightweight abstraction level over real-time systems (and even over the inconsistent user-space vs kernel-space RTAI functions).

Shahbaz
  • 46,337
  • 19
  • 116
  • 182