Diskussion:Grand Unified Bootloader

ISO mit GRUB 2

grub-mkrescue ist ja eigentlich nicht dazu gedacht, sich eine ISO für sein OS zu erstellen. Mein GRUB2-ISO-Skript funktioniert eigentlich ganz gut, wäre es angebracht das entsprechend einzuarbeiten? Zumal man dann auch kein Problem hätte, die Daten nachträglich auf das Image zu schieben. Zum ansehen des Skripts hier klicken TheThing 11:23, 22. Jun. 2011 (CEST)

Warum GRUB

Ich finde der Teil >Warum Grub< sollte überarbeitet werden, da er meiner Meinung nach ein völlig falsches Bild vermittelt. Es wird behauptet, dass ein eigener Bootloader daran scheitere, dass dafür tiefergehende Assemblerkentnisse notwendig sein. Ich finde dieses Argument insoweit falsch, als dass ein Projekt Betriebssystem natürlich in jedem Fall tiefergreifende Kentnisse in einer Programmiersprache erfordert. In welcher Sprache die Kentnisse vorhanden (oder auch nicht vorhanden) sind, ist hier eigentlich egal. Weiterhin erschließt sich mir nicht, wieso ein eigener Bootloader fehleranfällig sei. (Oder fehleranfälliger als alle anderen Projekte des Unwissenden.) Der berühmte Fehler, des Loaders, der da nur ein paar Kilobyte lädt, kann einem Anfänger natürlich passieren. Was ist schlimm daran? Was sollte den Anfänger daran hindern die Lösung im Internet zu finden? Wenn der Bootloader ein neues Feature braucht kann ich das selbstredend auch anständig implementieren und nicht nur hinzufriekeln. Wenn GRUB jedoch das Feature nicht hat, kann ich kaum das Feature nachrüsten. Natürlich verschlingt ein eigener Bootloader viel Zeit. Der Kernal aber nicht? Und der Bootvorgang des X86 erfordert es nicht, das A20 einzuschalten. Augenscheinlich soll hier dem Leser das Bild suggeriert werden, dass man seinen Kernal in C im PM schreibt und dann von GRUB laden soll. Das ist ein Weg. Aber nicht der einzige. Beispielsweise habe ich mein OS ausschließlich in RM Assembler geschrieben. Hier wäre GRUB völlig sinnlos. Mein Bootloader passt in den 1. Sektor und stellt sämtliche Dateisystemfunktionen bereit. Diesen Weg kann man auch gehen.

Für einen Bootloader braucht man auf jeden Fall weitere Assemblerkenntnisse, als diese für den Kernel unbedingt nötig sind, vor allem muss man für einen Bootloader RM-Assembler können. Wenn man kein Assembler kann, sollte man keinen Bootloader schreiben (es sei denn, man will dabei Assembler lernen). Mehr steht im Artikel dazu auch nicht drin.

Da die Überschrift des Abschnitts „Warum GRUB?“ lautet, geht es bei „fehleranfällig“ darum, dass der eigene Bootloader fehleranfälliger als GRUB ist; nicht darum, dass er fehleranfälliger als der Kernel wäre. Die meisten Hobby-OS-Entwickler zumindest auf Lowlevel sind der Ansicht, dass einen Kernel zu schreiben das wichtigste oder zumindest das erste Ziel in der OS-Entwicklung sein sollte[citation needed]; wenn der Bootloader dann noch Mist baut, lenkt das nur unnötig ab. „Unnötig“, weil es nach Ansicht der meisten interessanter ist, einen Kernel als einen Bootloader zu schreiben.

Die Lösung zu so etwas im Internet zu finden gestaltet sich meist schwierig, da man erstmal das Problem an sich finden muss (was im Artikel als „schwierig zu debuggen“ beschrieben wird), und dann vermutlich nicht mal etwas relevantes findet, wenn man danach googelt (“Boot loader only loads first 64 kB” wird vermutlich keine schrittweise Anleitung zum Lösen des Problems liefern). Was man machen kann, ist, im Forum oder im IRC zu fragen; dort werden die Leute in Bezug auf Bootloader aber eher weniger hilfsbereit sein und einfach sagen „Nimm GRUB“. Deshalb nimmt der Artikel genau das vorweg.

Ich möchte darauf hinweisen, dass der Artikel im bewussten Abschnitt sogar aufzeigt, dass es Vorteile haben kann, einen eigenen Bootloader zu schreiben. Was der Abschnitt also tut, ist keineswegs zu behaupten, dass jeder GRUB benutzen muss; vielmehr suggeriert er einfach, wie du richtig sagst, GRUB zu benutzen, denn das ist eine weitverbreitete Meinung auf Lowlevel[citation needed].

Wie gesagt, wenn jemand mit Problemen bei seinem eigenen Bootloader ins Forum oder ins IRC kommt, ist die Antwort im Allgemeinen einfach „Nimm GRUB“, weil es eben schwierig ist, Bootloader zu debuggen und es häufig kein allgemeines Rezept gibt. Außerdem ist es einfach so, dass viele, die einen Bootloader selbst schreiben, sich noch nicht sehr lange mit OS-Dev beschäftigt haben (Quelle: Erfahrung, und außerdem ich selbst). Das macht das Debuggen nicht gerade einfacher. Aus diesem Grund nimmt der Artikel genau diese Reaktion vorweg. Wir möchten niemanden ermutigen, seinen Bootloader selbst zu schreiben, wenn er dann bei Problemen einfach „Nimm GRUB“ gesagt bekommt. Ich persönlich halte es für besser, gleich GRUB zu empfehlen. Vielleicht wäre es besser, wenn wir Leuten, die Probleme mit einem eigenen Bootloader haben, einfach helfen würden. Weiß ich aber nicht, denn ich persönlich halte den Bootloader mittlerweile für ziemlich uninteressant. Alles, was der machen muss, muss auch der Kernel am Ende irgendwie machen.

Ähnlich dazu ist übrigens, dass wir fordern, dass die Leute C können, bevor sie einen Kernel in C schreiben. Das ist eigentlich ziemlicher Unsinn. Ein Kernel ist ein wunderbares Projekt, um C zu lernen (und ich bin nicht der einzige, der das sagt). Aber wir wollen vermeiden, dass im Forum oder im IRC Fragen zur Sprache C gestellt werden, weil das hier nicht die richtige Plattform dazu ist. Also sagen wir einfach, C muss man können, und dann ist klar, dass man sich Antworten dazu von woanders holen muss.

Zuletzt möchte ich noch darauf eingehen, dass du nicht findest, dass man seinen Kernel in C im PM schreiben sollte und im Zuge dessen sagst, das A20-Gate müsste beim Booten nicht eingeschaltet werden: Der RM ist obsolet, und seit der Einführung von UEFI ist es nicht mal unwahrscheinlich, dass er bald gar nicht mehr existiert. Um mehr als jedes zweite MB ansprechen zu können (was sich bei heutigen RAM-Größen durchaus als sinnvoll erweist), muss das A20-Gate eingeschaltet werden (wobei es heute teilweise schon fest eingeschaltet ist). Beides kann man ignorieren, wenn man will, aber das ist nunmal der Stand der Zeit seit zwei Jahrzehnten (oder mehr), und ich halte es für sehr sinnvoll, dieses Wiki daran auszurichten.

Zum Thema C: Der Artikel erwähnt nicht einmal, welche Sprache man zu verwenden hat, soweit ich das sehen kann. Man darf auch C++, D, Pascal, Sather, oder sogar Assembler für den Kernel benutzen. Die Annahme, die der einführende Abschnitt trifft, ist, dass man ein Betriebssystem mit einem Kernel im PM oder LM schreiben möchte. Dabei hilft GRUB, weil ein Bootloader meiner Ansicht nach kein Teil des Betriebssystems ist.

Ich möchte auch noch sagen, dass auch ich eine Menge Bootloader selber geschrieben habe und immer wieder Freude an 512-Byte-Spielereien finde. Ich glaube, wie es auch der Artikel sagt, dass man beim Schreiben eines Bootloaders (und eines Kernels) in Assembler eine Menge über die x86-Architektur lernt. Ich glaube allerdings auch, dass man C wunderbar bei der OS-Entwicklung lernen kann. Da müssen wir uns jetzt überlegen, ob das Wiki zielführend oder nicht ausgerichtet sein soll: Aktuell ist es recht zielführend. Was vermutlich auf lange Sicht nicht funktionieren wird, davon raten wir ab. Kernel in Sprachen außer C, ein eigener Bootloader, Real Mode… Das sind alles Dinge, die viele Leute ausprobiert haben, und die sich dann als nicht so gut erwiesen haben. Umgekehrt kann man das aber alles machen, wenn man Ahnung davon hat. Aber leider versuchen das auch Leute, die keine Ahnung haben, und das funktioniert dann eben häufig nicht so gut. Darauf könnten wir das Wiki aber auch ausrichten, und sagen, „Hey, da werdet ihr ein Jahr oder mehr dran sitzen, ihr werdet am Ende nichts funktionierendes haben, aber ihr habt eine Menge gelernt.“ So lief das für mich, und ich finde das auch gut so. Das wäre die nicht zielführende Variante.

Ich denke, Hobby-OS-Dev ist tatsächlich nicht zielführend. Am Ende hat fast niemand etwas wirklich benutzbares (Betonung auf „fast“), aber fast alle haben eine Menge gelernt. Aber das macht sich doof, wenn man das ins Wiki schreibt. Also bin ich eher dafür, dass da steht „Hey, nimm lieber GRUB, das funktioniert bei den meisten besser“ mit einer Notiz drunter, was man verpasst, wenn mans nicht tut, als dass da steht „Schreib erstmal einen eigenen Bootloader, bevor du dich für oder gegen GRUB entscheidest, dabei lernst du nämlich eine Menge“.

Vielleicht sollten wir eine dicke Notiz auf die Startseite packen, dass alle Vorschläge, wie man etwas zu tun oder zu lassen hat, subjektiv sind, und ausdrücklich empfehlen, dass man sich auch dagegen entscheiden kann. Nur sollte man dann keine Hilfe im Forum oder IRC erwarten (nicht, dass es sie auf keinen Fall gibt, aber na ja…). —Clici McXan 15:05, 2. Mai 2015 (CEST)

Ich versuche mal, die Grundidee etwas kürzer zu fassen: Wenn du ein OS entwickeln willst, dann ist der Bootloader – je nach Sichtweise – entweder gar nicht Teil des OS (so sehe ich das) oder einer der uninteressantesten Teile, die die wenigsten Auswirkungen auf das Endergebnis haben. Durch einen schlechten Bootloader kann man manches kaputtmachen, aber mehr als GRUB bietet, wirst du kaum brauchen, und kannst deswegen durch einen eigenen Bootloader nichts gewinnen. In anderen Worten: Wenn es dir ums OS geht, ist der Bootloader nur Arbeit, die nichts bringt.

Bleiben die Fälle, in denen jemand bewusst nicht an einem OS, sondern an einem Bootloader arbeiten will. Dann soll er gern einen Bootloader schreiben, aber dann wird er es vermutlich auch richtig machen wollen und nicht mit einem notdürftigen 512-Byte-Loader abhaken. Wenn es dir also um den Bootloader geht, und darum, RM-Assembler zu lernen, dann schreib einen guten Bootloader und lade damit ein anderes OS.

Wenn du übrigens einen RM-Kernel in Assembler geschrieben hast, dann würde ich, ohne dir zu nahe treten zu wollen, behaupten, dass dein OS noch nicht weit über die Hello-Welt-Phase hinaus ist und das der Grund ist, warum du den Bootloader noch als einen interessanten Teil ansiehst, über den es sich zu streiten lohnt. --Taljeth 17:11, 3. Mai 2015 (CEST)

Hallo Clici McXan, ehrlich gesagt verstehe ich deinen Beitrag nicht. Es ist meiner Auffassung nach eine etwas merkwürdige Haltung, eine Wiki mit Forum zu betreiben und gleichzeitig zu signalisieren, dass man Anfängern nur dann weiterhilft, wenn Sie einen gewissen Kentnisstand haben. So gesehen, wenn ich Grub nehme und perfekt C kann, wozu brauche ich dann dieses Forum bzw. dieses Wiki? Glücklicherweise bin ich seit Jahren in einem anderen Forum aktiv, dass nach der Philosophie arbeitet, dass auch blutigsten Anfängern geholfen wird. Und jemand mit viel Ahnung hat mal zu mir gesagt, (ich hatte da ein Problem mit so nem Hello World Loader), er hilft mir gerne, wenn ich selber einen Bootloader entwickle. Aber er fixt mir nicht dieses Hello World Ding zusammen. Ich habe auf diesen Rat gehört und dabei eine Menge gelernt. Will sagen nur Standardlösungen zu präsentieren (so wirds gemacht) ist vielleicht auch nicht der beste Weg. Ich habe nie gesagt, dass man Grub nicht nutzen soll. Aber man kann auch andere Wege gehen.

Hallo Taljeth, du trittst mir kein bisschen zu Nahe. Aber deine behauptung stimmt so nicht. Mein vollständig in RM Assembler geschriebenes OS umfasst z.Z. über 26.000 Zeilen Quelltext. Neben mehreren integrierten Programmen, einem vollständig eigenentwickelten Dateisystem verfügt es auch über eine 46 Befehle starke API mit deren Hilfe Programme für das OS Entwickelt werden können. Details findest du unter www.beepsoft.de Also anscheinend kann man mit dem völlig veralteten Realmode doch noch ganz nette Dinge anstellen. Und ich würde wetten, dass mir der GRUB nicht gestattet mein eigenes Dateisystem zu entwickeln.

Hi,

Wenn du perfekt C kannst, kannst du noch lange kein OS schreiben. Wenn ich einfach nur perfekt C++ kann, kann ich auch noch lange kein AAA-Spiel für den Massenmarkt entwickeln. Dieses Wiki und das Forum erklären (unter anderem), wie man mit C ein OS entwickelt.

Ich hoffe, ich habe nie gesagt, dass wir blutigsten Anfängern nicht helfen. Die Frage ist, worin sie Anfänger sind. Wir werden niemandem helfen, der zum ersten Mal einen Computer benutzt, gerade den Browser ausprobiert, und dabei auf diese Seite gestoßen ist, weil das nichts bringen würde. Wir helfen Leuten, die Anfänger bei der Betriebssystementwicklung sind und dazu Fragen haben, denn darum geht es auf dieser Seite. Grundsätzlich helfen wir aber nicht Leuten, die Schwierigkeiten haben, die nichts mit Betriebssystementwicklung zu tun haben, zum Beispiel mit der Programmiersprache, in der sie gern das OS schreiben würden (bspw. C). „Grundsätzlich“ heißt nicht, dass ihnen nie geholfen wird, aber es heißt, dass sie keine Hilfe erwarten dürfen.

Nach Meinung der meisten hier gehört der Bootloader nicht zum Betriebssystem. Das ist der Grund, warum Fragen zur Bootloaderentwicklung ebenso grundsätzlich nicht Thema dieser Seite sind. Wieder heißt „Grundsätzlich“, dass Hilfe dabei nicht bestraft wird, aber es heißt eben auch, dass wir im Zweifel eher von dem Thema wegsteuern.

Während wir bei Programmiersprachenfragen häufig sagen können „Dazu gibt es genug Seiten, lies dir die halt durch“, können wir das bei Bootloadern nicht, oder zumindest nicht guten Gewissens. Es wäre natürlich schön, wenn es eine Seite gäbe (möglichst im deutschsprachigen Raum), die sich intensiv mit der Bootloaderentwicklung auseinandersetzt. Dann könnten wir immer sagen „Geht doch dahin, da hilft man euch“. Gibt es nicht, also können wir das nicht. Das einzige, was wir deshalb machen können, ist zu sagen „Nimm GRUB“.

Wenn du eine konkrete Frage zu einem Bootloader hast, kannst du sicherlich ins Forum gehen und diese Frage stellen, mit nicht allzu wenig Glück bekommst du sogar eine Antwort; da Bootloader allerdings nicht das Thema dieser Seite sein sollen, haben wir uns entschieden, Leuten generell von eigenen Bootloadern abzuraten, damit das nicht zu oft passiert (das war ja das ursprüngliche Thema dieser Diskussion, soweit ich mich erinnere).

Falls du dir übrigens die Frage stellst, warum wir Bootloader nicht als Thema auf dieser Seite sehen, so ist für mich persönlich die Antwort: Weil fast alle Probleme, die beim Schreiben eines Bootloaders auftauchen, letzten Endes auch Probleme sind, die man beim Schreiben eines Kernels hat. Wenn man einen Kernel mit Gerätetreibern schreiben kann, sollte man auch einen Bootloader schreiben können.

Du hast vollkommen Recht, wenn du sagst, Standardlösungen zu präsentieren ist nicht unbedingt der beste Weg, das habe ich so ähnlich ja auch geschrieben:

Vielleicht sollten wir eine dicke Notiz auf die Startseite packen, dass alle Vorschläge, wie man etwas zu tun oder zu lassen hat, subjektiv sind, und ausdrücklich empfehlen, dass man sich auch dagegen entscheiden kann.

Leider sind wir nicht in der Lage, alle Lösungen zu präsentieren (das ist sogar ganz einfach unmöglich), deshalb müssen wir uns auf Standardlösungen beschränken. Abgesehen davon, was Bootloader angeht kenne ich keinerlei Form von Tutorial oder Grobanleitung zum Selberschreiben, die ich guten Gewissens als Alternative zu GRUB präsentieren könnte.

Übrigens wird dich vermutlich niemand daran hindern, Eigener Bootloader (o. ä.) zu füllen. Wenn der Inhalt gut genug ist, sodass man dabei tatsächlich von einem ordentlichen Bootloader sprechen kann (und nicht nur von etwas, was halt schnell den eigenen Kernel lädt, mit hartkodierten Offsets, Maximallängen, und was weiß ich, das heißt, was man üblicherweise so bei eigenen Bootloadern sieht), dann können wir gern den strittigen Abschnitt im Artikel hier überarbeiten, und wir hätten alle was gewonnen.

PS: GRUB kann mit Blocklisten statt Dateinamen umgehen. Damit kann man auch Dateien von GRUB unbekannten Dateisystemen laden.

PPS: Ja, der Real Mode und insbesondere das BIOS sind übrigens völlig veraltet, wenn das ironisch gemeint war. Spätestens seit UEFI sind deren Tage endgültig gezählt.

—Clici McXan 21:13, 31. Jul. 2015 (CEST)

Hi,

ich möchte da auch mal kurz meine Senf dazugeben. Zunächst einmal kann ich Clici McXan da zustimmen was die Empfehlung von GRUB angeht. Natürlich kann es durchaus sinnvoll sein eine angepasste oder gar eigene Lösung zu verwenden (vor allem wenn man es der Herausforderung wegen macht), aber in 90% der Fälle ist GRUB nicht nur mehr als ausreichend, sondern sogar besser als Selbstentwickeltes. Ich sehe das in etwa so, dass jemand fragt, wie er denn ein für Linux geschriebenes Programm auf einem PC ausführen kann. Natürlich kann man ihm empfehlen FreeBSD zu installieren und die Linux-Emulation zu verwenden, oder Windows zu installieren und ein Linux in Virtualbox laufen zu lassen, aber im Allgemeinen wird der Rat eben lauten: Installier dir ein Linux. Viele Wege führen nach Rom, und es ist sicher nicht falsch einen breiten Weg mit wenig Schlaglöchern zu empfehlen.

Nun zu deinem Realmode-Argument. Zahlen alleine sagen da nicht viel aus, entscheidend ist, was sie bewirken. Sicherlich kann man im Realmode so einiges anstellen, einige haben das sogar zu einer Kunstform erhoben, aber wenn ich dann ein "OS" sehe, bei dem ein amoklaufender Texteditor den Kernel zu Fall bringt, dann spreche ich dem ganzen schon ein Stück weit die Existenzberechtigung ab. Der Realmode ist nun einmal ein Relikt der Vergangenheit, mehr Bürde als Feature, und hat im 21. Jahrhundert abseits von Kompatibilitätsgründen (und die werden auch weniger) keinen Platz mehr. Und das nicht nur aufgrund des Fehlens von elementaren Mechanismen wie Speicherschutz, sondern auch, weil ich mir nicht 16GB RAM in den Rechner stecke nur um dann mehr als 99% davon nicht benutzen zu können. Dass GRUB die Verwendung des Realmodes erschwert ist meiner Meinung nach eher gut als schlecht, da so eventuell Anfänger davon abgehalten werden auf die Idee zu kommen, der Realmode sei irgendetwas anderes als eine Sackgasse.

Auch dein Dateisystem-Argument ist eher ein Anti-Argument. Die meisten Hobby-Dateisysteme sind nur miese Reimplementierungen von FAT, und das leider besonders oft bei vehementen Realmode-Verfechtern (nicht, dass ich deine Leistung schmälern oder gar dein Werk beleidigen will, aber es ist nun einmal der häufigste Fall. Richtige Innovationen bei Dateisystemen finden heute in Richtung ZFS/XFS/BTRFS usw. statt, mir wäre nicht bekannt dass ein Hobby-OS ein Dateisystem mit handfesten Vorteilen hervorgebracht hat). FAT gibt es schon, es ist sinnlos es zum hundertsten "neu zu erfinden" statt einfach FAT selbst zu verwenden. Auch hier sehe ich GRUB eher positiv, da es Anfänger hier einen Stein in den Weg, der in die falsche Richtung führt, legt.

Um nochmal etwas taljeths letztes Argument aufzugreifen: Vergleiche dein OS mal mit den etwas "größeren" Hobby-OS. Beispielsweise Tyndur, ToAruOS, Μxoµcota, oder auch Ghost. Und verdeutliche dir dabei, warum die Entwickler dieser OS eben diesen Weg gegangen sind, und sich nicht zu sehr vom not-invented-here-Syndrom haben verleiten lassen. Manchmal kann ein Sonderweg sinnvoll sein, aber es hat eben einen Grund, warum zu manchen Dingen so vehement geraten wird.

--TheThing 23:23, 31. Jul. 2015 (CEST)

Hallo Clici McXan: ich lese ja schon seit einiger Zeit diese Seite und war immer der Meinung, dass es hier um Betriebssystemprogrammierung im allgemeinen ginge, nicht nur um selbige mit C. Hab ich mich wohl geiirt. Gern werde ich demnächst einen Artikel auf meiner Seite veröffentlichen, wie man (aus meiner Sicht) einen Bootloader programmieren (kann!) Dieser Artikel kann dann gerne geprüft werden. Ich hoffe unter den Gesichtspunkten der Qualität und nicht unter der Prämisse, ob etwas standardconform geschrieben wurde. Also heißt das, dass Grub meinen Kernal laden könnte? Ich bezweifle stark, dass das BIOS veraltet ist. Das Konzept einer Firmware, die zum Start eines PCs Hardware initialisiert wird es sicherlich noch eine Weile geben. Und ob sich jetzt das UEFI durchsetzt, dass gerade unter dem Gesichtspunkt Sicherheit doch schon fragwürdig ist. (Stichwort UEFI Rootkit)... Wir werden es erleben. Und was heißt, der Realmode ist veraltet. Meines Wissens nach ist der Realmode in jedem PC nach wie vor implementiert. Ob jetzt der Realmode nur deshalb veraltete ist, weil ich mit dem Protectedmode (übrigens auch nicht mehr ganz taufrisch) mehr Speicher laden kann, weiß ich nicht.

Hallo TheThing: Grundsätzlich wird Linux/Windows immer besser sein, als etwas Selbstentwickeltes. Insofern, was machen wir uns die Mühe? Du steckst dir also 16GB RAM in den Rechner. Ich vermute, das machst du damit die nur mäßig gut entwickelte Software weiterhin funktioniert. Ließ dir mal die Systemanforderungen vom Windowsmediaplayer durch und vergleiche die mit dem QV Player für DOS. Warum führt der RM in eine Sackgasse. Du machst in deinem Beitrag verschiedene Andeutungen über mein OS. Ich lade dich hiermit ein, mein OS zu testen und dann gerne sachliche Kritik darüber zu äußern. Also ich habe es bisher noch nicht geschafft mit meinem Editor meinen Kernal zum Absturz zu bringen. Auch hat mein Dateisystem nicht wirklich etwas mit FAT gemein. Zum Schluss: Ich habe mir alle von dir angegebenen OS angesehen. Erkläre mir doch jetzt mal bitte, was der von dir angeführte Vergleich ergeben soll. Berücksichtige dabei bitte, dass vielleicht nicht alle Projekte das selbe Ziel verfolgen.