Thema: Device-Filesystem

[Svenska]

Hm, ich weiss, es ist noch sehr frueh, darueber zu sprechen, aber ich
fände es im Hinblick auf Treiber ganz nuetzlich.
Die Idee von Unix "Alles ist eine Datei" ist nämlich mit den Rawdevices
usw sehr nuetzlich, nur eben missfällt mir, dass die Devicefiles auf der
Platte gespeichert sind.

Wie wäre es, wenn der Kernel eine, oder sagen wir mal zwei, Pages
reserviert, die eine Art "Device-Filesystem" enthalten, jeweils mit einem
Namen (8 Zeichen reichen ja aus) und der Adresse, unter der der Treiber
gefunden werden kann. Jeder Treiber meldet sich dann beim Kernel an,
und der Kernel erzeugt (als einzigstes Programm, was das kann!) dann
den Eintrag. Der Treiber wählt den Namen selbst aus (net, sound) und der
Kernel hängt dann noch eine fortlaufende Nummer an (/dev/net0 etc).

Damit könnte man immer im Deviceordner nachschauen, ob ein derartiges
Gerät vorhanden bzw. der Treiber dafuer geladen ist, ohne sich um
irgendwelchen nichtvorhandenen Devices kuemmern zu muessen oder
versehentlich eine reguläre Datei unter /dev/ anzulegen und die Platte
vollzumuellen (Bsp. /dev/dsp1 als Abspielgerät und solche Scherze).

Eigentlich bräuchte man dann ja nur eine Lese- und Schreib-funktion fuer
die Einträge, der Rest läuft dann ueber spezielle Treiberschluesselworte.
Datei erzeugen etc. gibt es einfach nicht - nur ne Fehlermeldung - und der
Kernel erzeugt die Einträge durch direkte Speicherzugriffe. Zwei Pages
á 4 Kb sollten dicke ausreichen (512 Einträge bei 8 Zeichen/Name und
8 Bytes/Adresse..., mehr Devices sollte ein PC nicht brauchen, oder?)
Oder habe ich irgendwas vergessen? Dieser Ansatz gefiele mir jedenfalls
sehr gut.

Svenska

[joachim_neu]

Ich werde es bei meinem system so machen, dass das system beim booten und danach im idle alles nach Hardware scannt und ne tabelle mit den namen anlegt (eben nach dem schema fddA,fddB,...). auf gleiche weise werden auch partitionen genommen. dann schaut das system in einer datei nach, und läd alle treiber und linkt sie mit dem gerät. die liste kann NUR vom kernel verändert werden. dadurch is auch gleich das mit den FSs auf den Partitionen und geräten gelöst. sprich die platten werden dann mit hddA, hddB, .. angesprochen, die floppys mit fddA, fddB, ... und dann werden die nach partitionen gescannt und dann eben die als fdd0, fdd1,.. und hdd0, hdd1,... eingebunden. und je nach dem build des kernels findet er halt die geräte oder net. nur kann er dann auch gleich die passenden ports für den treiber öffnen und der treiber muss nurnoch laufen und hat keine kontrolle, kann also z.B: kein laufwerk blockieren. wenn ich nun also auf ein gerät zugreifen kann ich einfach an den treiber was schicken. man muss halt die funktionsnummern gleich halten bei allen treibern des gleichen typs, aber das is egal. man könnte theoretisch das ganze auch so machen, dass man nur lesen, schreiben und position wechseln kann. das würde reichen, auch bei platten. man würde bytes zurückbekommen, keine sektoren. der treiber müsste trotzdem das ganze vorrätig halten, dann ginge es schneller. so hätte man sogar das treiberinterface für alle treiber gleich, was die als parameter erwarten is ja dann egal, kann man auch darüber abwickeln

aber das is auch nur einer der vielen ansätze, vielleicht sollten wir das in OSDesign machen? (falls ja bitte verschieben)

[hannibal]

ist ein sehr guter vorschlag. waere aber auch nicht schlecht das ganze vielleicht permanent auf der platte zu speichern? vor allem um langwierige hardware-scans waehrend dem booten zu vermeiden. abgesehen davon wuerde dies auch der philosophie des mikrokernels entgegenkommen, da man ja die driverliste zur laufzeit veraendern und dynamisch laden kann.

wie gesagt, sehr interessanter ansatz .

lg, hannibal

[Svenska]

Wenn man es auf die Platte speichert, hat man bei Fehlerchen und so
immer das Problem mit den Device-Files.
Existiert das File nicht und man macht einen Output, ist in
nullkommaganzwenig die Platte voll, dann ist das nämlich eine reguläre
Datei.
Ausserdem könnte man damit ja einfach nachschauen, ob eine bestimmte
Hardware vorhanden bzw. ansprechbar ist (Devicefile anwesend?)

Svenska

...und nu macht euch ran, zerfleischt den Ansatz, auf das er noch besser
werden möge!

[hannibal]

Wenn man es auf die Platte speichert, hat man bei Fehlerchen und so
immer das Problem mit den Device-Files.
Existiert das File nicht und man macht einen Output, ist in
nullkommaganzwenig die Platte voll, dann ist das nämlich eine reguläre
Datei.
Ausserdem könnte man damit ja einfach nachschauen, ob eine bestimmte
Hardware vorhanden bzw. ansprechbar ist (Devicefile anwesend?)

Svenska

...und nu macht euch ran, zerfleischt den Ansatz, auf das er noch besser
werden möge!

ich wuerde mal sagen ein sichern auf der festplatte muss sowieso vorgenommen werden, man kann das ganze ja dann beim booten von der festplatte in den speicher laden und beim runterfahren wieder auf die festplatte uebertragen. sollte mal waehrend der laufzeit ein fehler mit einem device-file auftreten und das system stuerzt ab, hat man nebenbei noch eine nette systemwiederherstellungsmoeglichkeit da ja die alten device-files noch auf der platte sind und noch nicht upgedated worden sind.

lg, hannibal

[Svenska]

Wenn jeder Treiber beim Hochfahren sich beim Kernel meldet und ein
Devicefile haben will...
Wozu auf Platte sichern? Wenn das System gebootet wird und ein Treiber
nicht geladen werden kann, gibt's eben kein Device und damit ist die
Hardware nicht ansprechbar.
Ohne Treiber ist ein Device(file) ja schliesslich wertlos...

Svenska

[hannibal]

ja, das ist mir schon klar, nur willst du bei jedem bootvorgang die ganze hardware scannen?

[stultus]

man könnte doch einfach die adressen für jedes gerät fest eincompilieren, die ports ändern sich ja wohl kaum oder??? ansonsten find ich die idee devicefile nur bei treiber auch ganz ok...

[joachim_neu]

nur wo speicherste, welcher treiber zu welchem gerät gehört? ein gerät finden OK, einen treiber laden OK, beide verlinken OK, nur woher kennste den treiber?

[mastermesh]

Da gibts AFAIK ein ID-System dafür... bestimmte Hardware hat eine bestimmte ID und wenn diese mit einer Treiber-ID übereinstimmt, wird der Treiber geladen.

Ob das jetzt allgemein stimmt, weiß ich nicht... bei BeOS wird es jedoch intern so gehandhabt.

[Jidder]

Bei Linux hat so weit ich das verstanden hab jeder Treiber eine probe()-Funktion. Die wird vom Kernel aufgerufen und der Treiber sagt dann ob er mit dem Device was anfangen kann oder nicht.

@mastermesh: ich glaube, du meinst die PCI IDs. Die sind leider wie der Name schon sagt nur für PCI-Devices...

[Svenska]

Man könnte ja eine Konfigurationsdatei einstellen, in der alle Treiber,
die geladen werden sollen, eingetragen werden. So umgehst du den
ganzen Kram mit dem durchprobieren.
Auch könnte man so die Treiber von Hand laden und - was ich
persönlich als grossen Vorteil erachte - durch einfaches "dir"
anfragen, ob ein bestimmtes Gerät vorhanden ist.

Fest einkompilieren wuerde ich nur den Treiber fuers Bootmedium.

Und ja, jeder Treiber sollte "seine" Hardware beim Start scannen im
Format "Ja sage mal... ich erinnere mich, dass an 0x300 eine NE2000
sitzen sollte... bist du da?" "Ja!" "Gut, dann melde ich
dich mal bereit..."
Sodass keine unnuetzen Treiber geladen werden und die Treiber auch
immer etwas zum Ansprechen haben.

Svenska

[Roshl]

"Ja sage mal... ich erinnere mich, dass an 0x300 eine NE2000
sitzen sollte... bist du da?" "Ja!" "Gut, dann melde ich
dich mal bereit..."

Das wäre mal ne geile Programmiersprache^^

[T0ast3r]

Ich schließe mich der Idee von Svenska an.
Nach dem booten und dem ganzen Kram sollte dann eben die Konfidatei gesucht werden, in der die Dateinamen der Treiber drinstehen.
Wenns dann nicht vrhanden sind, hat man eben ein pech.
Aber ich würde auf keinen fall Treiber fest eincompilieren.
zudem wäre eine Tabelle im Speicher über die Hadware, die bei Booten angelegt wird auch nicht schlecht.

[Svenska]

Den Treiber fuers Bootmedium muss man einkompilieren, damit man
alle anderen Treiber nachladen kann. Oder man lässt eben diesen Treiber
noch im RM laden - oder macht eine Ramdisk aus ner Datei mit dem
Treiber drin... ein Treiber muss immer da sein

Die Tabelle, welche Hardware vorhanden ist, soll ja gerade das Device-
Filesystem sein.
Ist eine "Datei" vorhanden => Gerät vorhanden, Treiber aktiv, einsatzbereit.
Ist die "Datei" nicht da => Treiber nachladen oder Pech.

So dachte ich mir das...

Svenska

[T0ast3r]

Die Idee mit der RamDisk ist eh nicht schlecht, die können wir benutzen.
Da laden wir dann alle Treiber rein, die eben in einer Konfi Datei stehen.
Aber wie du schon gesagt hast, hat man eben ein Pech wenn der passende Treiber der in der Konif Datei steht nicht vorhanden ist. Wobvei da könnte man dann einfach einen Standarttreiber laden, der gängig läuft.

[Svenska]

Wird langsam OT...

Vergleiche mal mit dem Linux-Kernel.
Wenn du ein IDE-Sýstem hast, ist der IDE-Treiber fest einkompiliert, bei
SCSI-Rootplatte muss der SCSI-Hostadaptertreiber drin sein, da du von
dem ja das Modul laden musst.
Und fuer Installationen gibt's zum einen dutzende Kernel mit allen
möglichen Treibern oder halt Driver-Disks (Floppytreiber im Kernel...)
oder die initrd (cramfs, rd im Kernel) und so weiter.

Oder man lässt den Bootloader den Rootsystemtreiber nachladen, noch
im Realmode und damit mit BIOS-Hilfe. Das hat aber nix mit dem Device-
Filesystem zu tun.

Also nochmal.

In einer Konfigurationsdatei stehen alle Treiber drin, die beim Start
geladen werden, diese werden geladen und pruefen die Hardware.
Danach meldet sich der Treiber beim Kernel (wenn der Test prositiv
verläuft) und der Kernel erzeugt ein Device fuer dieses Gerät. Sollten
mehrere Geräte eines Typs verbaut sein, lädt man eben noch einen
Treiber. Sollte ja nicht weiter stören. Stellt der Treiber aber fest, dass
die Hardware nicht vorhanden ist, so entlädt er sich (u.U. mit
Fehlermeldung) einfach selbst ohne weiteres Aufhebens.

Das Device-System wird dann halt einfach im Speicher gehalten und ist
beim Ausschalten nicht mehr vorhanden. So kann man durch einfaches
pruefen auf bsp. "/dev/net?" untersuchen, ob eine Netzwerkkarte
vorhanden ist, "/dev/sound0" fuer digitale Samples, "/dev/mouse0"
fuer Maus und so weiter. Treiber, die nicht beim Start geladen werden,
kann man einfach nachladen (z.B. modprobe, insmod; device.com).

Und wer unbedingt die Hardware durchprobieren will, kann das ja tun...
und bei der Installation sollte sowieso die Hardware erkannt werden,
zumindest die wesentlichsten Dinge. Auch hat diese Idee den Vorteil,
dass man damit wichtige Geräte (Tastatur, Maus) auch zweimal
anschliessen kann (kennt wer den Siedler2-Multiplayermodus?), z.B.
wenn der Mainboard-Tastaturanschluss kaputt ist und dann gibt man
halt einen Parameter an (kbd=kbd1) oder sowas... man kann ja ne
alte Tastatur auch an den Parallelport anschliessen (mit ner einfachen
Schaltung, geht auch mit XT-Tastaturen) und solche besonderen
Konfigurationen könnte man damit auch ansprechen.

Aber jetzt wirds wieder OT...

Das fände ich jedenfalls eine gute Idee.

Svenska

[mastermesh]

Ich würd mir an euerer Stelle noch keine nähreren Überlegungen machen.

Wir versuchen gerade, einen GRUB-basierten Bootstrap durchzuführen. Wenn alles klappt, werden alle "lebenswichtigen" Module zusammen mit der Kernel per GRUB geladen. Wie es dann weitergeht... tja, das werden wir dann sehen.

[DDR-RAM]

Ich würd mir an euerer Stelle noch keine nähreren Überlegungen machen.

Wir versuchen gerade, einen GRUB-basierten Bootstrap durchzuführen. Wenn alles klappt, werden alle "lebenswichtigen" Module zusammen mit der Kernel per GRUB geladen. Wie es dann weitergeht... tja, das werden wir dann sehen.

Wer seid ihr?
Wo kann man das nachlesen das ihr das tut?



Aber zum Thema kann ich nicht allzu viel sagen.
Bin da bisschen hin und hergerissen.

MfG
DDR-RAM

[mastermesh]

'Wir' sind... zur Zeit nur ich  

Im Klartext: ich bereite gerade eine Art SDK vor... also ein einheitliches Build-Setup, das sich jeder herunterladen kann und damit programmieren kann.

Nicht dass nachher wieder solche Probleme auftreten wie "mit meinem gcc funzt es nicht!" oder "wie compiliere ich den kernel???" usw...