afaik musst du für lstat schon selbst den speicher bereitstellen.
also ändere mal die deklaration um in
struct stat puffer;
und der aufruf sieht dann entsprechend so aus:
lstat(verzinhalt->d_name,&puffer)==-1
dann sollte auf jeden fall der segfault weg sein
Unter Linux:
In /proc/<PID>/statm findest du Informationen über die Speicherbenutzung des Prozesses mit der PId <PID> .
Für die Bedeutung der Felder siehe Tabelle 1-2: http://linux.startcom.org/docs/en/Introduction to Linux/x8608.html
Fabeltier schrieb:
Das der Linker die Object Files nicht finden kann, entnehme ich bereits der Fehlermeldung.
Du hast geschrieben, dass der Linker die Datei nicht findet. Dass dein Makefile die Objektdatei nicht da erstellt, wo sie hin soll, hättest du ruhig erwähnen können. Es hätte sie ja nach der Fehlermeldung auch garnicht erstellen können. Fürs nächste mal, bitte genauere Fehlerbeschreibung.
Da gibt es spezielle Module, die man in der Kernelkonfiguration auswählen kann.
Die heißen so ähnlich wie ip_conntrack_ftp. Die müssen geladen sein, damit dieser ganze FTP-Kram funktioniert auf dem Router. dnsmasq ist meines Wissens nach nur ein kleiner DNS-Server, der aus der /etc/hosts-Datei liest und hat mit diesem Problem eigentlich gar nichts zu tun.
lagalopex schrieb:
SIG_SETMASK wird redefiniert -> schlecht
SIGTSPT gibts nicht
Und c99 ist halt _nur_ der c99 standard... nimms raus, nimm gnu99 oder was auch immer
OH MANNN!!!! Klar, c99 das wars!!!
Danke, ich hab das daemliche c99 und pendantic jetz aus dem Makefile gehauen und schon kompilierts.
Also fuer Euch Code-Fanatiker
das #define macht gar keinen Sinn und war ein Ueberbleibsel von irgendwas, weil's halt nicht kompiliert hatte, ein SIG_BLOCK wird jedoch gar nicht verwendet im Code.
Nebenbei hab ich nun gets() in fgets() umgewandelt, SIGTSPT sollte SIGTSTP heissen, der Aufruf von catch_syspend() heisst nun catch_suspend(), usw usw..
Brav?
Ich hatte das Beispiel ja auch nur aus einem der vielen Tutorials, noch ein paar zusaetzliche Typos eingebaut und fertig war's
abhängig von der hardware die hinter der seriellen schnittstelle benutzt wird, wirst du wohl nicht um ein usb uart device herumkommen (z.b. FT232 und konsorten). usb geräte müssen grundsätzlich einen puffer zur verfügung stellen welcher daten der ein- und ausgabe hält. der ft232 z.b. stellt diesen puffer bereit. wie schon gepostet, stellt dir linux unter /dev/ttyUSB das gerät zur verfügung wenn eben ein solches uart device angeschlossen ist. kommunizieren kannst du allerdings auch via libusb mit der hardware, falls linux das gerät nicht als solches erkennt.
Eine kleine Nachkorrektur:
Das Betriebssystem scheint auch beim Schreibzugang zu blocken, solange keiner aus der Pipe liest. Das macht es natürlich quasi obligatorisch, MyProgram vorher zu starten, damit die Closes-Source App nicht womöglich festhängt.
Du kannst es selbst ausprobieren, wenn das Programm hw ein HelloWorld Programm ist:
Terminal 1:
~$ mkfifo myfifo
~$ ./hw
Hello, world!
~$ ./hw > myfifo
Programm hängt fest beim Schreibzugriff auf StdOut
Terminal 2:
~$ cat myfifo
Hello, world!
hw ist jetzt fertig, denn es konnte die Welt begrüßen.
Hallo Linux Freunde,
kan mir jemand sagen, wie ich meine Serielle Schnittstelle /dev/ttyS0 wie folgt einstellen kann.
8 Datenbits
Keine Parität
1 Stopbits
Übertragungsgeschwindigkeit 9600 Baud
Vielen Dank im Voraus.
Sorry!!! Da steckten tatsächlich einige Überlegungsfehler drin! Ist eigentlich logisch, dass das Programm nicht abbricht, da der Kindsprozess ja noch läuft...
argh! Also das ganze hab ich folgendermassen gelöst:
Sobald der Kindsprozess startet, schreibt der seine Prozess ID in die pipe und sendet dem Hauptprozess ein Alarmsignal, woraufhin dieser die Prozess ID des Kindsprozesses aus der pipe liest. Danach wird im Hauptprozess der alarm gesetzt und ein weiteres Mal auf das Signal gewartet. Sobald dieses eintrifft, sei dies vom Kindsprozess oder vom Elternprozess, wird mittels kill geprüft, ob der Kindsprozess noch existiert und falls ja, dieser mit einem SIGTERM beendet. Hernach greift der Elternprozess noch ein letztes Mal auf die pipe zu und entnimmt der den Rückgabewert des Kindsprozesses. Sollte der Kindsprozess den Rückgabewert noch nicht geschrieben haben, liegt dieser auch nicht vor und das Ergebnis kann nicht verifiziert werden, entspricht also einem Nichterfolg. Bloss wenn der Kindsprozess erfolgreich seinen Rückgabewert in die pipe geschrieben hat, kann der Hauptprozess diesen verifizieren und erhält ein erfolgreiches Ergebnis.
Grüsse
Super! Vielen Dank nochmals tntnet!!! Mit einer pipe funktionierts prächtig!
Wieder mal was dazugelernt! Ich finde einfach, das hätte in meinem Buch etwas genauer stehen dürfen!...
Naja, zum Glück gibts solche Foren!
Grüsse
Hallo, vielleicht kennt sich ja hier jemand damit aus: in folgendem Bespielprogramm kann ich keine Umlaute eingeben bzw. wieder ausgeben lassen:
#include <ncurses.h>
#include <stdlib.h>
void quit()
{
endwin();
}
int main()
{
int b;
initscr();
atexit(quit);
curs_set(2);
keypad(stdscr,TRUE);
meta(stdscr, TRUE);
mvprintw(2,2,"ÜÄÖ wird nicht richtig ausgegeben, jedoch öäü??");
mvprintw(3,2,"Bitte geben Sie mal was ein: ");
while ((b=getch()) != KEY_F(5))
{
mvprintw(4,2,"Die Eingabe lautete %c",b);
}
return 0;
}
Ich habe schon alles durchprobiert. Bei der Eingabe lassen sich weder Groß- noch Kleinbuchstaben bei den Umlauten eingeben.
Hat vielleicht jemand eine Idee, wie man dieses Problem beheben kann ?
Gruss Jürgen
strong schrieb:
Laut der Aufgabe müssen wir auf Kernelebene alle fehlgeschlagenen Versuche, ein Signal beim Senden an eine Prozess mit printk Funktion ausgeben lassen. Dann modifizierte Kernel noch mal kompilieren.
Dann würde ich sagen, du solltest dich mal ein wenig mit den Kernel-Sourcen vertrtraut machen und die signal.c scheint mir da ein guter Ansatz zu sein.
SDL kannst du wirklich einfach verwenden.
Auf den NeHe OpenGL Seiten (http://nehe.gamedev.net/) gibt es auch zu OpenGL mit SDL Beispiele und auch einen "Basis-Code".