Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - Termite

Seiten: [1] 2 3 ... 12
1
OS-Design / Re: Idee zum Thema Prozessverwaltung
« am: 24. August 2009, 11:59 »
du kanst das vermurkst ruhig verallgemeinern. auch vermurkste Software kann sowas produzieren. Wenn in einem java programm irgendwo so ne schön hässliche endlosschliefe drinn ist dann geht oft auch nicht mehr viel, bzw man braucht verdammt viel gedult das Programm über den Taskmannager oder die Entwicklungsumgebung wieder zu stoppen.
2
OS-Design / Re: Idee zum Thema Prozessverwaltung
« am: 19. August 2009, 09:22 »
das ist meiness wissens nur ein problem von windows.
unter linux tut die konsole fast immer. und von dort lässt sich auch meist der prozess dann schön killen. zur not von einem anderen rechner remot über ssh einlogen, rootrechte besorgen und dann killen.


Ich glaube das Linux parameter für die Maximale grenzen für resorcen hat, um solche amoklaufenden Prozesse zu stoppen, bzw zu begrenzen. 
3
OS-Design / Re: OS für Plattform mit Segmentierung
« am: 17. August 2009, 09:22 »
Moin

Segmentierung, so wie ich sie kenne, (C166 / 8086) hatte damals was mit dem Bedürfniss zu tun, mehr speicher zu addressieren, als mit 16 bit überhaupt möglich ist, darum wurden die Segmentregister eingeführt, durch die man  die Addressierung von 16 auf 20, 24 ,.... bit aufborehn konte. daher auch die lustigen far jumps, bei denen segmentregister und dann der IP manipuliert wird.

Bei 32 bit. ist das normalerweise fast nicht mehr notwendig. ausnahmen wie der PC der mehr als 4gb RAM addressieren soll mal ausgenommen. Beim PC gibts ja jetzt dafür die 64Bit maschienen. Im serverberich / High performenc computing waren die ja genau desewegen ja schon lange im einsatz, da dort 4gb ram schon lang nicht mehr ausgereicht haben. (alpha, ultrasparc, ... )

Bei aktuellen 80X386 CPUs gibt es ja die SegmentSelectoren. Die aber meines wiessens wieder auf einen gemeinsamen virtuellen 32Bit Addressraum zeigen. (Code, Stack, Data zusammen dürfen nicht mehr als 4gb belegen)
4
OS-Design / Re: OS für Plattform mit Segmentierung
« am: 15. August 2009, 12:37 »
wobei mir gerade einfällt in einem FPGA könnte man die MMU ja extern nachrüsten und über einen interrupt an mit der CPU verbinden.

welches FPGA willst du eigentlich einsetzen, nur interesse halber.
den namen der soft cpu wolltest du ja nicht preisgeben. Ich nehme aber an, das es was exotisches ist, bzw ganz spezielle eigenschaften. müsste eine 16 Bit cpu sein, da sonst die segmentierung wenig sinn machen würde.

gruss
5
OS-Design / Re: OS für Plattform mit Segmentierung
« am: 15. August 2009, 11:59 »
Hi

Ich hab jetzt nicht wirklich alles gelesen.

aber auf gewissen hw achritekturen, gerade im embedded bereich, gibt es gewisse hw seitige enschränkungen, die dynamisch wachsende Task stacks nicht ermöglichen. Ohne MMU oder etwas ähnlichem wird das nicht gehen.
Auf dem PC kann jede Task / Thread / Prozess seinen eigene Virtuelle Addressierung haben, die von der MMU wieder auf die Physikalische umgerechnet wird. Bei systemen mit MMU kann keine Task speicher einer anderen Task gefährden.

beim PC wird eine Ausnahme geworfen, wenn der Stack überläuft/ bzw auf Virtuelle Addresen zugegriffen wird für die kein Mapping existiert. Dies veranlast das OS dann eine neue speicherseite in den Stackadressraum einzuhängen.

und einfach irgend was durch die gegendschieben z.B. ganze Segmente geht auch nicht immer (absolute Addresierun / relative Addresierung). Du sagst, du hast eine segmentierte addressieren, dann funktioniert das nur solang dein  Programm nicht über eine Segment grenze hinweg springen muss.

Im embedded bereich wird normalerweise die Stacksize jeder Task zur designzeit definiert, zur laufzeit wird da nichts mehr vergrössert oder verkleinert, da die HW wie oben beschrieben das meist gar nicht ermöglicht. bzw das meist eine zusätzliche fehlerquelle ist die mang gerne ausschliesen möchte. Das einzige, was man machen kann, ist beim taskwechsel zu prüfen, ob der Taskblock inclusieve definiertem stack noch in ordnung ist. (magic number) wenn nicht kann das os die verarbeitung einstellen, da es ja nicht wisssen kann, was genau alles Überschrieben wurde.

6
Offtopic / Re: PHP und die get Methode.
« am: 31. March 2009, 11:38 »
Aktuell PHP 5 und PHP 6 steht vor der tür.
7
OS-Design / Re: Kommandozeilendesign
« am: 28. February 2009, 13:51 »
vieleicht noach das, wie die ggf benötigten Parameter an das programm übergeben werden.

auch mal darüber gedanken machen, welche zeichen für ein komando überhaupt zugelassen sind. dann kann man sich ggf das suchen sparen.
8
Lowlevel-Coding / Re: Struktur auf beliebigen Speicher anwenden
« am: 31. January 2009, 19:28 »
So, nochmal was anderes in C. Ich möchte wenn eine Bedingung erfüllt ist eine Funktion verlassen. Wie mache ich das? Also ich meine das hier:

u8 test(void)
{
if (bla)
{
bla
}

else
{
bla

if (bla)
{
bla
return 1;
//ich will nach hallo
}

bla
return 0;
}

//hier ist hallo
}

Wie "springe" ich nach der Stelle, die ich hallo genannt habe?

thx

bitmaster

zurück mal zum ursprünglichen Problem ein else würde da schon wunder bewirken.

goto in c find ich hässlich. kann verwendet werden.  sollte aber vermieden werden. und so kompliziert verschachtelte schleifen baut ihr nun auch noch nicht. und wenn sollte man sich überlgen obs nicht doch anders geht.

u8 test(void)
{
        u8 ret;

        ret = 0;
if (bla)
{
bla
                ret = -2;
}
else
{
bla

if (bla)
{
bla
ret = 1;
//ich will nach hallo
}
                else
                {
    bla
    ret = 0;
                }
}

return ret;
}
9
Lowlevel-Coding / Re: Struktur auf beliebigen Speicher anwenden
« am: 29. January 2009, 12:05 »
Moin Moin

ich arbeite teilweise auch ohne OS bzw mit sehr exotischen sachen microC/OS-II auf einem ARM 7 z.B. Malloc und free werden mir vom compiler zur verfügung gestellt. voraussetzung ist, das ich einen heap definiere, im embeded bereich macht man das meist statisch, da so viel speicher gar nicht vorhanden ist.

gcc hat sicher auch eigene Funktionen für malloc und free. die gehen sicher intern wieder auf andere Fuktionen, die man ggf erst implementieren muss. z.B. um vom os speicher für den heap anzufordern.
10
Lowlevel-Coding / Re: Struktur auf beliebigen Speicher anwenden
« am: 29. January 2009, 10:00 »
Moin Moin

das was ihr sucht kann jeder c compiler und nennt sich malloc, realloc und free.

wenn sich zur laufzeit die grösse des arrays nicht verändert, sondern nur bestimmt werden muss, ist das der einfachste weg.

sollte sich zur laufzeit die grösse des Arrays verändern, ist eine Liste die beste wahl. wobei man auch bei einer liste um malloc und free nicht drum herumkommt. und ob nun einfach doppelt verkettet, oder doch lieber ein baum, oder doch lieber gleich nen wald ( ein baum aus bäumen) ist dann geschmakssache, bzw hängt von den anforderungen an die liste ab.

wobei die einfachste version für eine dynamisch wachsende Liste realloc, bzw. ein malloc mit memcopy und einen free der alten liste währe.

gruss

ps. und in C++ würde ich euch die STL ans herz legen. wieso das rad neu erfinden, wenn sich schlaue köpfe schon das hirn verränkt haben und die fast optimale implementierung gefunden haben ( list, map, hashmap, sortiert, nicht sortiert, optimiert auf linaren zugriff, ... ) bzw Boost

11
Lowlevel-Coding / Re: Struktur auf beliebigen Speicher anwenden
« am: 26. January 2009, 23:38 »
Nabend

und asche auf mein haupt,

in deiner kernel.c sollte noch die zeile von bluecode rein. ups is ja schon drinnen, nur im falschen kontext
#include <multiboot.h>

// muss global deklarirt werden! kann von allen funktionen dieser C Datei
// verwendet werden. wenn ein extern existiert auch von anderen
// übersetzungseinheiten. werden vom linker in den Data bereich abgelegt.

struct multiboot_info *boot_info;

// ein static reduziert die gültigkeit einer globalen variablen auf genau die C
// Datei in der sie definiert wurde. extern tut dann nicht mehr!

void main(u32 multiboot_address, u32 multiboot_magic)
{
//clear screen
ClearScreen();

// was hier deklariert wird hat nur gültigkeit inerhalb dieser funktion
// und sonst niergens nennen sich auch lokale variablen und werden
// meist auf dem Stack / heap angelegt.
boot_info = (struct multiboot_info *) multiboot_address;

test();

usw.
}
12
Lowlevel-Coding / Re: Struktur auf beliebigen Speicher anwenden
« am: 26. January 2009, 10:20 »
Moin

extern heist so viel wie das die definition der Variable in einer anderen übersetzungseinheit erfolgt und nicht in der Aktuellen. Somit ein hinweis auf den Compiler/linker das er die variable trotzdem verwenden darf, und erst der Linker im hinterher angibt wo er das ding wirklich finden kann.

So als erstes sollte man sich in C angewöhnen 2 H Dateien zu verwalten. eine für den öffentliche teil, der andere für den Internen krempel, der auser im Modul sonst keinen was angeht. Zusätzlich zu den .C Dateien

MOD_C1.H öffentlicher teil des Moduls
typedef struct multiboot_info
{
    unsigned long int ELEMENT;
    unsigned long int ELEMENT1;
    unsigned long int ELEMENT2;
} multiboot_info_Type;

extern struct multiboot_info *boot_info;
/* oder alternative
extern multiboot_info_Type * boot_info;
*/


MOD_C1.C  Die implementierunt des Moduls
#include "MOD_C1.H"
boot_info = (struct multiboot_info *) multiboot_address;
/* oder alternative
boot_info = (multiboot_info_Type *) multiboot_address;

*/

ABC_Cx.C  ein anderes Modul
#include "MOD_C1.H"

boot_info->ELEMENT;


gruss
13
OS-Design / Re: kmalloc und malloc
« am: 17. January 2009, 12:55 »
wobei eine sortierte Liste auch noch andere Vorteile hat.
mit free wird ja ein speicherbereich in die Freispeicher liste eingetragen. Liegen jetzt 2 Seicherbereiche direckt hintereinander, können diese zusammengefasst werden, damit mus ggf beim nächsten malloc nicht eine neue 4K kachel angefordert werden.
14
Hast du es mal mit der konsole versucht? das ist das womit die windows user die linux user aufziehen. so das alte Dos fieling. Die KDE tools setzen meines wissens nur auf den konsolen tools auf.

cdrtools (cdrecord) bzw. cdrkit

wobei wenn ich das gerade sehe, da war vor kurzem ein grosser knatsch wegen einer lizenzumstellung wodurch es probleme bei manchen distries gab ( im speziellen bei Debian glaub ich )
15
Moin

zwischen Linux und suse ist immer noch ein kleiner unterschied. Was kann linux dafür das suse ein system voller nicht vollständig funktionierender komponenten zusammenstellt? auserdem gibts noch genug andere Distries die ggf weniger fehler haben. Ubuntu, Debian, ....
16
Sowas geht generlel nur über den Linker.

ist meist vom eingesetzen linker abhángig. und sowas ist selbst im Embeded Bereich, wo man sowas öffter braucht ( z.B. für prüfsummen vor oder nach dem FW Image, Versionsnummern, .... ) ist das nicht immer ganz einfach.
17
Lowlevel-Coding / Re: Problem mit Zeiger auf Funktionen.
« am: 25. October 2008, 19:34 »
Nabend

1. legt für deine funktionenspyter in der struktur erst mal typedefs an, anstelle sie direkt in der struktur zu definieren. die wirst du öfters mal brauchen. (struktur, Funktionsparameter, ggf für casts, ... )  witer wegen der type prüfung beim übersetzen. (damit passiern weniger fehler)
2. leg 3 Add funktionen an. z.B. addKeyDown, addKeyUp, addKeyPress
3. verwende als parameter die unter 1 definierte typedefs als parameter.


    typedef int (*(KeyDown_T)(unsigned char scan1, unsigned char scan2, unsigned char shift));

struct key_funk
{
   KeyDown_T Key_down;
}

void addKeyDown( KeyDown_T fktptr)
{
   Key_Vunction.Key_down = fktptr;
}

2 hat den grund, da dur verschiedene Parameterlisten hast, damit must du nicht den funktionspointer unnötig durch die gegend kasten. den ohne cast wird sich das warscheinlich nicht übersetzen lassen. dein problem ist, das du bei deiner add implementierung eine funktion übergeben willst. das muss aber ein funktionspointer sein. ( daher auch der typedef, der einen funktionspointer definiert)


ggf hilft das auch weiter http://www.math.uni-wuppertal.de/~axel/skripte/oop/oop7_9.html

gruss
18
Offtopic / Re: libgobject-2.0.so.0: wrong ELF class: ELFCLASS64
« am: 21. October 2008, 11:33 »
sollte auch so sein, den das haben meines wissens alle Linux versionen so zu handaben.
19
Offtopic / Re: libgobject-2.0.so.0: wrong ELF class: ELFCLASS64
« am: 20. October 2008, 10:50 »
Moin

ich hab zwar noch nie ein 64 bit linux system aufgesetzt, aber so wie ich die Fehlermeldung interpretiere, ist die libgobject2.0.so.0 in der Falschen version vorhanden. sprich anstelle der 32Bit version erkennt er eine 64bit version. was natürlich nicht tuen kann. ( oder umgekehrt )

Linux verwaltet meines wissens die Libs für 64Bit und 32 Bit getrennt. (in getrennten verzeichnissen. die 64bit bekommen einen anderen namen) ggf kann es ein, das die falschen versionen in den falschen pfaden liegen. Kann es sein, das du teile deines systems selber übersetzt hast? ggf ursache für das durcheinander.


gruss
20
OS-Design / Re: Design eines Grafiktreiberinterface
« am: 17. October 2008, 14:22 »
Hmmm

ich könnte mir vorstellen, das mit dem schnellen kopieren im grafikspeicher sich folgendes realisieren lässt.

für jedes Fenster existiert ein quasi eigener Monitor abklatsch im Grafik speicher. (nur so gross wie das Fenster selber) zum aufbauen des Monitorbildes werden nor noch die entsprechenden Ausschnitte auf den sichbaren Monitorbereich kopiert. Natürlich in der richtigen reihenfolge.

kann man sogar noch weiter treiben, das wenn z.B. ein scrollfenster für z.B. ein bild gebraucht wird, das ganze bild schon im speicher liegt, aber nur der sichtbare bereich in den darstellungsramen kopiert wird. wird gescrollt, wird einfach nur der neue auschnitt reinkopiert.
Seiten: [1] 2 3 ... 12

Einloggen