Ich habe ein großes System, das hauptsächlich in C geschrieben ist und bis jetzt im Benutzerbereich lief. Jetzt muss ich den Code als Kernelmodul kompilieren. Dafür, afaik, sollte ich zumindest den Code neu schreiben und Funktionen wie malloc , calloc , free , printf mit ihren Kernel-Äquivalenten ersetzen, da diese ausschließlich User-Space-Funktionen sind. Das Problem ist jedoch, dass ich den Quellcode für einige benutzerdefinierte Bibliotheken, die im System verwendet werden, nicht habe, und diese Bibliotheken rufen malloc usw. innerhalb ihrer Funktionen auf. Also, im Grunde muss ich vielleicht die ganze Bibliothek neu implementieren.
Nun die Frage: Wird es ein wirklich schmutziger Hack sein, wenn ich meine eigene Implementierung von malloc als Wrapper um kmalloc schreibe, etwa so:
Verknüpfen Sie anschließend diese Implementierung mit dem Systemcode, wodurch alle Unbekannten Symbole in Modul -Fehlern entfernt werden.
Eigentlich dachte ich, dass dies ein häufiges Problem wäre und jemand hätte schon einen solchen kmalloc-Wrapper geschrieben, aber ich google seit ein paar Tagen und fand nichts nützliches.
EDIT: Der Grund dafür ist, dass das System, von dem ich spreche, eine Echtzeitanwendung war, die auf dem VxWorks Echtzeit-Betriebssystem läuft und jetzt wollen wir es auf Linux RTAI portieren, wo die Apps meistens im Kernel-Bereich laufen . Aber ich denke, es gibt eine Möglichkeit, Echtzeit im Benutzerraum zu haben, also sollte ich wahrscheinlich tun, wie Mike vorgeschlagen hat und den Code in Kernel und User-Space Teile trennen und zwischen ihnen mit Shared Memory kommunizieren.
Ich habe das noch nie zuvor gesehen. Ich musste etwas Ähnliches bei einem früheren Job machen (bei unseren Telefonen mussten wir aus Gründen der Energieeinsparung einen Teil des Codes aus dem Userspace aus dem Kernel portieren), aber so habe ich es gemacht. Ich habe a genommen Teil des Codes und bewegte es, und ein kleiner Teil davon.
Als ich es getan habe, habe ich die Aufrufe des User-Space auf Kernel-Aufrufe geändert, und zwar aus einer Reihe von zwei Gründen:
Es war weniger verwirrend (andere, die sich den Code ansahen, mussten sich nicht wundern, warum ich "malloc" vom Kernel aus anrief)
malloc und kmalloc funktionieren nicht genau gleich. Was ich damit meine, ist
2a. kmalloc benötigt einen flags -Parameter, in Ihrem obigen Beispiel haben Sie ihn fest codiert. Was ist, wenn Sie später entscheiden, dass Sie es an einigen Orten ändern möchten und nicht an anderen? (Angenommen, Sie haben verschiedene Orte, an denen Sie dynamisches Gedächtnis haben).
2b. kmalloc gibt Ihnen nicht den gleichen Speicher wie malloc . malloc() gibt Ihnen die Anzahl der Bytes, die Sie als size_t size übergeben. kmalloc() hingegen befindet sich im Kernel und beschäftigt sich damit mit dem physikalischen Speicher des Systems, der nur in seitengroßen Chunks verfügbar ist; Wenn Sie also kmalloc() aufrufen, erhalten Sie nur bestimmte vordefinierte Byte-Arrays mit fester Größe. Wenn Sie sich dessen nicht bewusst sind, können Sie nach einem bestimmten Chunk fragen und so viel mehr Speicher erhalten, als Sie benötigen ... ein direkter Port Ihres Codes schützt Sie davor nicht .
2c. Die Header-Dateien müssen sich ebenfalls ändern. Offensichtlich können Sie <stdlib.h> nicht in den Kernel einschließen, also müssen Sie, nur weil Sie den malloc-Aufruf "umgebrochen" haben, die Header-Dateien ersetzen.
schnelles Beispiel meines Punktes in 2b oben:
%Vor%Um die tatsächliche Menge an zugewiesenem Speicher anzuzeigen:
%Vor% sowieso ... technisch, wie Sie es beschreiben, sollte gut funktionieren. Beide nehmen ein size_t und geben ein void * zurück, so dass es funktionieren sollte; Aber beachten Sie, dass je mehr Code in den Kernel verschoben wird, desto weniger deterministische Dinge werden, und das malloc() & lt; = & gt; kmalloc() ist nicht so 1: 1 wie es scheint.
Ich versuche, meinen RTAI-Code sowohl im Benutzer- als auch im Kernel-Bereich kompilierbar zu machen (und auch mit POSIX zu arbeiten) und habe URT was im Wesentlichen das tut, was Sie fragen. Es ist eine leichtgewichtige Abstraktionsebene gegenüber Echtzeitsystemen (und sogar gegenüber den inkohärenten RTAI-Funktionen zwischen Benutzerraum und Kernelraum).
Tags und Links c linux linux-kernel rtai