Thema: GLIBC implementation

[woigl]

Um mein OS portabel zu halten empfielt es sich ja sich an die GLIBC zu halten und diese im eigenen Kernel zu implementieren.

Dabei fehlt mir aber noch ein wenig das verstaendniss wie die GLIBC Funktionen von einer Applikation mit dem Kernel kommunizieren. Wie hat Linux dies realisiert?

[Legend]

http://www.tldp.org/LDP/khg/HyperNews/get/syscall/syscall86.html

Obwohl das scheinbar vor 2.6er Zeiten geschrieben wurde, da man soweit ich weiss keine eigenen Syscalls mehr hinzufügen darf.

Aber wieso wird ein OS portabler wenn es sich an die glibc hält???
Enthält die nicht auch einen Teil Posix?

[woigl]

http://www.tldp.org/LDP/khg/HyperNews/get/syscall/syscall86.html

Obwohl das scheinbar vor 2.6er Zeiten geschrieben wurde, da man soweit ich weiss keine eigenen Syscalls mehr hinzufügen darf.

Aber wieso wird ein OS portabler wenn es sich an die glibc hält???
Enthält die nicht auch einen Teil Posix?

Ja und genau da verliere ich den Überblick...

...also mal als Beispiel will ich den GCC unter meinem OS laufen lassen... ...was benötigt dazu mein Kernel alles?

[Legend]

Ich glaub eher du willst zu deinem Kernel ne passende C Bibliothek mitliefern - oder willst du nen 2. Linux Kernel machen?

[woigl]

Ich glaub eher du willst zu deinem Kernel ne passende C Bibliothek mitliefern - oder willst du nen 2. Linux Kernel machen?

nein keinen 2ten Linux Kernel sondern einen Kernel der Ansi C versteht - und somit denke ich das der gcc portierbar sein müsste... oder?

[Legend]

Nun gut, um gcc zu bauen hat man schon das Problem das man ./configure vorbeikommen muss - was ein riesiges shell Script ist. Von daher erwarten einen beim gcc noch ganz andere Probleme.

Was den Standard selber angeht, so finde ich grad nix sinnvolles, nur Änderungen zum Vorgänger und Kritik an dem Standard.

[woigl]

Nun gut, um gcc zu bauen hat man schon das Problem das man ./configure vorbeikommen muss - was ein riesiges shell Script ist. Von daher erwarten einen beim gcc noch ganz andere Probleme.

Was den Standard selber angeht, so finde ich grad nix sinnvolles, nur Änderungen zum Vorgänger und Kritik an dem Standard.

Okay, aber wenn ich dich richtig verstanden habe muß ich eigentlich nur den ANSI C Standard einbauen... um somit mehr oder weniger kompatibel zu sein?!  

[Legend]

Sagen wir mal so - ohne ANSI C Funktion wird genau KEIN Programm von einer anderen Platform laufen. Weil eigentlich jedes Linux, jedes Windowsprogramm irgendwo diese Funktionen benutzt.

Für mehr Kompatibilität müsstest du noch mehr unterstützen - und dann geht es auch schon meistens direkt ans Design!

Je kompatibler man ist, desto weniger innovativ kann man sein.

[woigl]

Sagen wir mal so - ohne ANSI C Funktion wird genau KEIN Programm von einer anderen Platform laufen. Weil eigentlich jedes Linux, jedes Windowsprogramm irgendwo diese Funktionen benutzt.

Für mehr Kompatibilität müsstest du noch mehr unterstützen - und dann geht es auch schon meistens direkt ans Design!

Je kompatibler man ist, desto weniger innovativ kann man sein.

okay, muss dir hierbei recht geben... ...man sollte doch innovativ bleiben!

[SSJ7Gohan]

Naja, man kann aber die POSIX Funktionen immernoch als eine Art Wrapper einbauen, so wie Cygwin das macht.

Das ./configure Problem kann man lösen, indem man gcc cross-compiliert.
Man erstellt die Executeable einfach unter Linux und portet sich dann eine einfache shell, dann sollte sich auch ./configure ausführen lassen. So schwer sollte das eigentlich garnicht sein, GCC auf einem Hobby-OS laufen zu lassen, denn der GCC ist eigentlich sehr portabel gecodet.

[woigl]

Jep, das mit den Wrapper ist cool...

Ja mal sehen - werds dann mal versuchen den GCC rueber zu bringen.

[woigl]

Ich habe da aber noch eine ganz spezifische Frage und versuche diese nun so gut als möglich zu erklären...

Also ich habe erstens einen Kernel und dann eine Bibliothek welche im C geschrieben ist. Diese Bibliothek wird dann bei Programmen dazu gelinkt und muss Kernel Funktionen ausführen. Nehmen wir als Beispiel mal einen Dateizugriff her, da das Dateisystem im Kernel implementiert ist muß ich ja aus der Bibliothek irgendwie darauf zugreifen. Wie kann man dies effektiv realisieren?

Wie wird das bei anderen OS gemacht?

[Legend]

Bei Unixen generell z.B. ist open ein Systemaufruf, dementsprechend kann man z.B. bei Linux den Syscall-ISR aufrufen mit den richtigen Parametern!

[woigl]

Bei Unixen generell z.B. ist open ein Systemaufruf, dementsprechend kann man z.B. bei Linux den Syscall-ISR aufrufen mit den richtigen Parametern!

okay aber wie sieht es mit scanf aus? wie werden die Daten hin und her gegeben?

[SSJ7Gohan]

Ich würde persönlich nur die Elementaren Funktionen in den Kernel packen (wenn du einen Monolitischen Kernel machst). Das heißt also, Funktionen wie open, read, write, close und andere io funktionen würde ich in den Kernel machen. Die Auswertung der Ausgabe oder Eingabe würde ich jedoch von der lib machen lassen. Das hat den Vorteil, das es flexibler ist, und sich einfacher auf andere Umgebungen als C portieren lässt.

[Legend]

Bei Unixen generell z.B. ist open ein Systemaufruf, dementsprechend kann man z.B. bei Linux den Syscall-ISR aufrufen mit den richtigen Parametern!

okay aber wie sieht es mit scanf aus? wie werden die Daten hin und her gegeben?

Von deinem Terminal liest du per stdin, was dort eine Datei ist. Also benutzt du den read syscall, wie bei Dateien, und die C Lib verarbeitet das dann weiter - ich muss allerdings sagen das ich noch kein Linux gesehen habe das nicht irgendwo nach ner Menge SSH, su, lokal anmelden usw. doch irgendwann mal lustige Zeichen bei manchen speziellen Tasten produziert hat. Deswegen würde ich diesen simplen Ansatz überdenken.

[woigl]

Bei Unixen generell z.B. ist open ein Systemaufruf, dementsprechend kann man z.B. bei Linux den Syscall-ISR aufrufen mit den richtigen Parametern!

okay aber wie sieht es mit scanf aus? wie werden die Daten hin und her gegeben?

Von deinem Terminal liest du per stdin, was dort eine Datei ist. Also benutzt du den read syscall, wie bei Dateien, und die C Lib verarbeitet das dann weiter - ich muss allerdings sagen das ich noch kein Linux gesehen habe das nicht irgendwo nach ner Menge SSH, su, lokal anmelden usw. doch irgendwann mal lustige Zeichen bei manchen speziellen Tasten produziert hat. Deswegen würde ich diesen simplen Ansatz überdenken.

Okay, klingt mal ganz gut... wie sieht es dann mit Windows aus? Wie machen es die MS Leute?

[Legend]

Also ich meine, wobei ich mir da nicht ganz sicher bin, das es bei MS viel mehr Syscalls gibt, evtl. auch für spezielle für Terminals. Auch unschön.

...

Wieso "auch"?

Weil das Konzept alles als Dateien anbieten zu wollen wie bei Unix (und damit auch bei Linux) fehlerhaft ist. Grundsätzlich ist es gut, zu versuchen einheitliche Werkzeuge anzubieten - aber nur dort wo Dinge auch überhaupt einheitlich behandelt werden können. So macht z.B. seek auf stdin oder auf deiner Netzwerkkarte keinen Sinn. Im Bereich der Geräteprogrammierung hat man sowieso dadurch nichts gewonnen, weil man für die interessanten Sachen sowieso geräteklassen-spezifische ioctls benutzen muss (ioctl ist auch ein Syscall).

Deswegen - wähle eine sinnvollere Abstraktion!

[woigl]

Also ich meine, wobei ich mir da nicht ganz sicher bin, das es bei MS viel mehr Syscalls gibt, evtl. auch für spezielle für Terminals. Auch unschön.

...

Wieso "auch"?

Weil das Konzept alles als Dateien anbieten zu wollen wie bei Unix (und damit auch bei Linux) fehlerhaft ist. Grundsätzlich ist es gut, zu versuchen einheitliche Werkzeuge anzubieten - aber nur dort wo Dinge auch überhaupt einheitlich behandelt werden können. So macht z.B. seek auf stdin oder auf deiner Netzwerkkarte keinen Sinn. Im Bereich der Geräteprogrammierung hat man sowieso dadurch nichts gewonnen, weil man für die interessanten Sachen sowieso geräteklassen-spezifische ioctls benutzen muss (ioctl ist auch ein Syscall).

Deswegen - wähle eine sinnvollere Abstraktion!

Ja aber genau das ist der Punkt - welche Abstraktionen sind sinnvoll?

bzw. wie sieht ein Beispiel mit einem Syscall aus?

[SSJ7Gohan]

Also, ich finde es gut, Dateien, Sockets, Pipes, Terminals usw. über I/O Streams anzusprechen. Bei shared memory, Treibern(/dev/) usw. macht das IMHO überhaupt keinen Sinn. Geräte/Komponenten die in etwa das gleiche machen, sollten über die selbe Schnittstelle ansprechbar sein. Andere Resourcen wie shared memory, sollten nicht über dasselbe Interface angesprochen werden.

Windows hat eigene API Funktionen, um auf die Konsole zu schreiben und von ihr zu lesen.