für was stehen die 1. 2 felder in /proc/stat bei disk_io
laut doku für (maj, min). kann aber net, sein, da ich mehrere festplatten hab.
und laut der maj min nummer wäre die nur einzelne partitionen von der ersten
als z.b. 8,0 für sda und statt 8,16 für sdb steht da 8,1 das wäre sda1 kann mir da irgendjemand weiterhelfen, ich erkenn da kein system.
kmalloc ist die eine Routine mit dem man Speicher innerhalb des Kernels allocieren kann. Für normale Anwendungen ist diese Funktion nicht geeignet. Du wirst auch keine Biblothek finden mit der in der du die implementation für diese Funktion findest.
Joe
Belgarad schrieb:
wie siehts da mit dem maximalen payload aus:
-muss ich mich an der MTU size orientieren, oder wird der payload beim versand durch den treiber auf eine entsprechende anzahl pakete verteilt?
In ein TCP/UDP-Paket geht erstmal theoretisch 64kiByte rein, die MTU hat auf ner anderen Schicht zu suchen. Aber auch darum kümmert sich TCP/UDP soweit ich weiß selber (zumindest bei TCP bin ich 100%ig sicher). Nochmal nachgecheckt: ein UDP kann maximal 64k - headergröße Daten enthalten, es wird kein Zusammenhang zwischen Paketen hergestellt.
-wie siehts dann beim empfang aus (read() bzw. recv()), muessen die pakete ggf. wieder assembliert werden.
Jein. Das Betriebssystem kümmert sich bei TCP darum, dass du die Pakete in der richtigen Reihenfolge bekommst. read/recv stellen allerdings nicht sicher, dass du alle Daten auf einmal bekommst, du musst also so oft read/recv machen, bis du die gewünschte Zahl an Daten erhalten hast und das alles in einem Puffer zusammenpacken.
Bei UDP besteht kein Zusammenhang zwischen Paketen und daher kannst du nicht sagen, in welcher Reihenfolge die Pakete ankommen.
ist das verhalten bei udp / tcp unterschiedlich?
Bei TCP muss vor dem Sendevorgang eine Verbindung hrgestellt werden, bei UDP nicht. TCP ist fehlersicher, d.h. es kümmert sich automatisch darum, dass fehlerhafte Pakete neuverschickt werden usw. UDP schickt ein Paket ins Netz und man kann nur hoffen, dass es ankommt, Garantien gibts dafür nicht, da muss sich das Programm dann drum kümmern. Dafür ist UDP etwas zügiger.
@kingruedi: eine gute Möglichkeit zu schauen, ob der Prozess mit einer ausgelesenen PID läuft, ist zu schauen, ob das Verzeichnis /proc/PID existiert. Die darin enthaltenen Dateien (z.B. status) können Aufschluss darüber geben, ob es sich bei dem Prozess auch um "setimgr" (oder je nachdem, wie der Binary-Name lautet) handelt.
Oder hast du nen anderen Vorschlag? Eine plattformunabhängige Variante wird es hierfür ja sicher nicht geben (verständlicherweise)
aber bei den meisten script-kiddies ises doch so die machen eine Portscann lassen dann ein zweit tools die sie haben/kennen drüberlaufen und wenn der Rechner dann nicht aufgeht gehen sie weiter und selbst wenn der rechner gecknackt wird scheitern die meisten am Linux selber weil sie eben keinerlei konsolenbefehle können und windows-lamer sind (ich kenn da so n paar)
MFG eiskalt
Hi,
vielleicht sollte man die "Unix Programmieren Links" mit auf die normale
FAQ-Seite setzen und entsprechend ordnen (so wie du es mit 'Programmieren'
und 'misc' schon gemacht hast).
mfg
v R
Eine DESTDIR Variable für make, um das ganze auch mit stow verwalten zu können ist in jedem Fall edel.
jo, ist in autoconf ja eh schon automatisch drin
XPMs sind eben üblicher, wenn es aber auch mit BMPs geht, dann nimm ruhig BMPs, dann bist du kompatibler zu deiner Windoze Version.
BTW. würde ich vielleicht der SDL den Vorzug geben gegenüber direkter X Programmierung, da du so eine Version für mehrere Platformen erstellen kannst und die LowLevel arbeit gut gewrapped ist durch die SDL
Ergebnisse pi mal Daumen kann man sicherlich mit einem Profiler erzeugen und wenn du unter Linux arbeitest ist das gprof (http://www.gnu.org/manual/gprof-2.9.1/gprof.html). Damit kannst du sicherlich auf dem selben Prozessor eine gewisse Abschätzung treffen. Für alles andere kann nur eine Emulation helfen da die Zeiten für bestimmte Operationen von Prozessor zu Prozessor so sehr varieren das man keine wirklichen Ergebnisse hat. Selbst ein AMD K6 hat eine völlig andere Architektur als der Athlon, geschweige denn ein Intel oder Motorola. Da glaube ich kaum das du zuverlässige Ergebnisse bekommen wirst.
Joe
[ Dieser Beitrag wurde am 11.07.2003 um 10:50 Uhr von JoeIntel editiert. ]