Moin, Am Mit, 2002-07-17 um 13.17 schrieb Michael Welle: > Dirk Haage <[EMAIL PROTECTED]> writes: > > Am Die, 2002-07-16 um 23.32 schrieb Michael Welle: > >> Dirk Haage <[EMAIL PROTECTED]> writes: > >> > Am Die, 2002-07-16 um 17.40 schrieb Michael Welle:
> >> > Linux: viel in nicht portierbarem Assembler (an unn�tigen Stellen), > >> > willk�rlich gezogene Kernelschnittstellen...) > >> Sicherlich sind grosse Projekte besser in den Griff zu bekommen, wenn > >> man ingenieurmaessig vorgeht und Erkenntnisse aus der Softwaretechnik > >> beachtet. Das ist unabhaengig von Mikrokern oder nicht. Das haengt > > > > Stimmt im allgemeinen. Da es aber hier um Betriebssystemkerne ging... > > > >> wohl eher von kaufmaennischen Zwaengen ab. > > > > ? > Der Grund, warum Konzepte der ST nicht oder nur wenig beachtet werden, > duerfte bei kommerziellen Projekten oft der Zwang sein, schnell am > Markt zu sein, billig zu sein, ST kostet Leute und Geld. Zeitdruck > fuehrt dazu, das beim Entwurf oder der Implementierung schonmal > geschlabbert wird und hacks eingefuehrt werden etc. Vermutlich liegt > da das Problem von Kompilaten aus Redmont etc. Achso, du meinst die Fehler der BWLer. Nur ist das ne Milchm�dchenrechnung. Denn auf Dauer kosten die Hacks mehr Geld, als sie vorher durch die Zeitersparnis gespart haben. Aber das ist ein v�llig anderes Thema. Auf der anderen Seite sollten man dann aber eigentlich erwarten, das bei den vielen Informatiker und anderen f�higen Leuten in der OSC, freie Software viel h�ufiger nach vern�nftigen Entwicklungskonzepten entwickelt werde w�rde. > >> Oder bei Synchronisierung > >> (Semaphore, Monitore, etc) finden sich wohl auch Gegenbeispiele. > > > > Wieso? Das ist ein Konzept, von der Struktur und der Idee einfach. Oder > > was m�chtest du damit ausdr�cken? > Prinzipiell kann ich ein Sync-Problem mit Semaphoren oder mit > Monitoren loesen. Monitore sind ein hoeherwertiges, komplexeres > Konzept als Semaphore. Trotzdem sollten Loesungen mit Monitoren > uberschaubarer und wartbarer sein (bei qualitativ gleicher > Umsetzung) => ein einfaches Konzept bedeutet nicht immer Uebersicht > und bessere Wartbarkeit. OK, Punkt f�r dich, oder besser: ein halber. ;) ich w�rde Semaphore, Kanal, Monitor usw. als an sich eigenst�ndige, einfache Konzepte bezeichnen (auch wenn sie untereinander betrachtet verschiedene Komplexit�t enthalten). Etwas anderes w�re (wenn auch nicht real vorhanden) ein Kanal-Semaphoren-Monitor, also ein Komplex, der alle Funktionalit�ten auf einmal zur Verf�gung stellt. Ist im �brigen wieder Unix-Philosophie: ein Programm macht eine Sache und die Programme k�nnen miteinander kombiniert werden. Warum sowas also im User-Bereich machen und auf Kernel-Ebene das Konzept �ber den Haufen werfen? > [...] > > Hmm, das sehe ich anders. Kehren wir zum obigen Beispiel zur�ck: Die > > ersten Tests waren ziemlich frustierend, da nix ging und Fehlersuche war > > fehlanzeige, da das System ja tot war, keine Kernelausgaben, keine Logs, > > nix. > > Was ich sagen will: Der Fehler soll ja deswegen nicht einfach > > unbehandelt, unerkannt bleiben, sondern er soll den Betrieb nicht > > st�ren. Sieh das ganze aus einer anderen Perspektive: Alles im Betrieb > > sind Dienste. Wenn jetzt auf deinem Rechner der Dienst "ftp" versagt, > > laufen die Dienste "ssh", "http" u.s.w trotzdem noch. Denn eigentlich > > ist ftp auch nur ein Remote-FS-Dienst wie NFS, also ein Betriebsmittel, > > genauso wie beliebige FS, SCSI-Treiber usw. > Ja, so gesehen hast Du schon recht ;). Nur bei Mikrokern vs mono. Kern > ist es imho etwas anders. Dort ist der Kern in Prozesse zerlegt > (zB. fs, mm, skeduling etc). Wenn davon einer die Graetsche macht, hat > man meist es Pech. Fuer ssh, ftp etc. aendert sich bei beiden Konzepten > eher nix. N�, eben genau nicht. Solange die untersten Prozesse bestehen bleiben, ist alles ok, da kann alles andere gerne draufgehen, wird einfach neu gestartet. Desweiteren lassen sich Fehler in den Mini-Kernel-Prozessen meist viel einfacher finden. Und stell die die M�glichkeiten vor: Hey, ich find das Scheduling doof, ich m�chte hier was mit Realtime-f�higkeit oder nen einfachen FCFS, ich tausch mal eben den Scheduling Prozess aus. > >> > ein > >> > komplett abst�rzendes System: > >> > - kaputte Hardware in den lebenswichtigen Systemen (Prozessor, Speicher) > >> > - ein Fehler im (micro)-Kernel, also beim Interrupt-Handling, der > >> > Prozesskommunikation oder dem Scheduling > >> > > >> > nichts f�r ungut > >> Kein Problem. > > Genau, solange alles sachlich bleibt ;) > Pech nur fuer die Leute, die sich schon die Erdnuesse besorgt haben > ;). /dirk -- dirk haage | [EMAIL PROTECTED] advanced network technologies phone +49 (0)30 85 07 06 12 mobile +49 (0)172 9 26 32 18 -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
