Re: Du hast echt NULL Ahnung. - Kamera-Speicherkarte für 12500 Euro

31. Mai 2004 18:46

31. Mai 2004 11:58
>
> > Von den praktischen und historisch bedingten Problemen bei
> > Festplatten wollte ich hier garnicht anfangen.
>
> Nö. Weil Du NULL Ahnung hast.

Soso.

> Du kannst mit hardware, die nur 16-bit
> adressieren kann eben nur maximal 65536 verschiedene Blöcke auf dem
> Speichermedium ansprechen.

Hoer' mal zu Du Clown. Eine CF-Card ist ein intelligentes Subsystem.
Die Adressierbarkeit des darauf befindlichen Speichermediums hat
nichts mit der Schnittstelle zu tun. Die ist geraeteunabhaengig, wie
bei SCSI und IDE auch. Friss', stirb oder mach' Dich hier halt weiter
zum Affen!

Ich habe bereits Firmware und Treiber fuer SCSI-Geraete programmiert
und bin mir sicher, dass Du mir nichts mehr zu dem Thema zu erzaehlen
hast. Ausser Klugscheisserei hab' ich von Dir bisher hier nix
vernommen.

> Daran hat sich das Dateisystem zu halten.

Hat es nicht. Ein Massenspeicher - etwa eine IDE-Platte - nimmt
Befehle entgegen. Bei SCSI bspw. sind diese Befehle 6, 10 oder 12
Bytes lang. In einem Kommandoblock befinden sich Bitfelder mit
entsprechender Breite zur Adressierung des Mediums. Auch bei CF-Cards
sitzt kartenseitig ein Controller, der Befehle entgegennimmt. Die
Schnittstelle ist dieselbe, egal ob der Controller nun ueber 512KB
oder 12GB Massenspeicher gebietet.

Hoer' also endlich mit Deinen bloedsinnigen Behauptungen auf, nur
weil es Dir an Vorstellungsvermoegen mangelt, auf welche Art und
Weise Adressierung in einem Computer geschehen kann ohne, dass die
Hardware veraendert werden muss. Ich bau' Dir mit einem Z80 (8 Bit)
ein System mit einem IDE-Controler (16 Bit, bspw. auf FPGA-Basis) und
einem 32-bitigen Dateisystem (z.B. ext2 auf dem Speichermedium). Wenn
Du die Realisierbarkeit eines solchen Vorhabens nicht glauben kannst,
Deine Sache!

> Deswegen bringt Dir nur eine neue firmware in einem Gerät was die
> 32-bit adressierung nicht in hardware unterstützt, überhaupt nichts.
> Das genaue Gegenteil behauptest Du aber ständig, ohne Belege oder
> Referenzen liefern zu können.

Du haelst also das, was Du hier von Dir gibst fuer belegt? Du leidest
an gehoeriger Selbstueberschaetzung. Fuer das Ego sicher gesund, an
der Richtigkeit Deiner Aussagen aendert das nix.

> Faktisch behauptest Du, es wäre
> problemlos möglich, mit hardware, die nur 16-bit adressieren kann
> einen 32-bit Adressraum anzusprechen.

Das hab' ich nie behauptet. Das ist lediglich eine falsche
Schlussfolgerung Deinerseits. Nochmal: Hier geht's nicht um den
Adressraum einer CPU. Krieg' das mal endlich in Deinen Schaedel rein!
Bei praktisch allen Massenspeichern handelt es sich um intelligente
Subsysteme, die ueber eine definierte Schnittstelle angesprochen
werden. Und nein: Da ist kein Adressbus, der die Speicherstelle
auswaehlt und ein Datenbus, auf dem die Daten wandern. Hast Du das
wirklich geglaubt?

Ich habe mich gegen Deine Aussage gerichtet, dass zur Unterstuetzung
dieser 32- oder 64-Bit-Dateisysteme neue Hardware erforderlich sei.
Und vielleicht siehst Du das mal endlich ein!

Ein Umstieg von FAT16 auf FAT32 bedarf in keinem Fall einer Aenderung
an der Hardware, nur weil auf einmal irgendwie 32 Bit envolviert
sind. Mir scheint, Du hast von der Art dieser Envolvierung absolut
keinen Ahnung!

> Und genau, da liegt Dein Hauptfehler.

Ganz schoen frech, diese Aussage, angesichts Deines Knowhows.

> Das Dateisystem und der in hardware verfügbare
> Adressierungsraum hängen sehrwohl zusammen.

Unsinn. Fuer Dich etwas vereinfacht: Diese Schnittstellen
implementieren einen Kommunikationskanal ueber den Befehle,
Statusinfos und Daten ausgetauscht werden. Diese Protokolle sind
weitgehend standardisiert. Bei CF-Cards macht das die CompactFlash
Association, bei IDE die ATA Working Group und bei SCSI die IEEE.

Beispiel IDE-Schnittstelle: Datenbusbreite 16 Bit. Adressbusbreite: 3
Bit. Wie das geht? Ganz einfach: Eine dieser 8 Adressen ist ein
Befehlsregister, in das man mit mehreren Schreibzyklen einen Befehl
absetzt. Eines der im Befehl enthaltenen Bitfelder enthaelt eine
Sektoradresse. Und wenn das Bitfeld irgendwann nicht mehr reicht,
weil das Medium zu gross ist, dann implementiert man auf Plattenseite
in der Firmware einen neuen Befehl, mit einem breiteren Bitfeld fuer
die Sektoradressierung. Im SCSI-Standard ist das mehrfach geschehen.
Die noetigen Anpassungen sind hostseitig rein softwaretechnischer
Art. Bei SCSI musste man solche Befehle bspw. schon zur Adressierung
von mehr als 1GB (6-Byte-Befehl auf 10-Byte-Befehl) einfuehren.

Aber ich hab' ja keine Ahnung. Hab' ja nur schon Treiber und Firmware
fuer solche Schnittstellen programmiert, von denen ich ja keine
Ahnung hab'. Klar!

> Warum behauptest Du eigentlich ständig das Gegenteil?

> Kannst Du Referenzen nennen, wo das
> was Du "beschreibst" auch tatsächlich so drin steht?

Meine Referenzen fuer dieses Beispiel sind der ATA-Standard und der
SCSI-Standard. Den CF-Standard kannst Du Dir selber raussuchen. Ueber
Dateisystem wirst Du da aber eh wenig finden (s.u.).

> > Die Festplatte sollte
> > nur ein Beispiel dafuer sein, dass Speichermedien auch ueber eine
> > definierte Schnittstelle angesprochen werden, deren "Breite"
> > vollkommen unerheblich fuer das daraufliegende Dateisystem ist.
>
> Ach. Du kannst nur nicht erklären, wie Du das LBA in hardware

Falsch. Ich kann Dir hier nur nichts erklaeren, weil Du es nicht
hoeren willst. Scheint ein Schema bei Dir zu sein.

Weisst Du ueberhaupt was LBA ist und wozu es gut ist? Weisst Du was
CHS-Adressierung ist? Wahrscheinlich weiss Du noch nichtmal was
Int13h-Erweiterungen sind oder Sektor-Mapping, geschweige denn, dass
Du ueberhaupt schonmal was mit Systemprogrammierung auf einem PC
gemacht hast.

Aber mitreden moechtest Du trotzdem, gell? Klar. Denn Du weisst ja,
wovon Du redest! Lass' mich raten: Informatik? Zweites Semester? Oder
PC-Welt-Leser im 4. Jahrgang? Wuerde einiges erklaeren...

> umsetzen willst, wenn diese nur 16-bit Adressierung unterstützt und
> Du mehr als 65536 Blöcke auf dem Speichermedium ansprechen willst.

Oh man. Du bist echt ne harte Nuss. Weiss Du eigentlich wie gross ein
Block beim PC ist? Weisst Du eigentlich, wie Platten am PC
urspruenglich angesprochen wurden? Sagt Dir ST506 irgendwas? Wo
tauchen die von Dir erwaehnten 16Bit dort auf? Na?

Und erklaeren mir bitte, warum ich eine Platte mit mehreren Gigabyte
heute noch an einem Controller von 1988 betreiben kann! Ausser den
Uebertragungsmodi hat sich an der parallelen ATA-Schnittstelle
naemlich nicht sonderlich viel veraendert, ausser einem Haufen an
Befehlen, die alle treiberseitig durch Software implementierbar sind.

Aber das geht ja nicht, weil damals ja noch 16-Bit-Prozessoren
state-of-the-art waren und dann kann man an einen solchen Controller
natuerlich keinen Platte anschliessen, auf der sich ein
64-Bit-Dateisystem befindet. Klar.

> Da nützt Dir auch kein anderes Dateisystem etwas.

Da hast Du ausnahmsweise mal recht. Weil das Dateisystem eigentlich
damit auch nix zu tun hat. Denn eigentlich sitzt das ganze, was ich
Dir grade erklaert habe nochmal ne Abstraktions-Schicht unter dem
Dateisystem. Aber das erklaer' ich Dir jetzt nicht auch noch... Du
bist ja schon mit den einfachsten Grundsaetzen des
Schnittstellendesings ueberfordert. Wuerde Dich eh bloss verwirren.

Hast Du ueberhaupt schonmal irgendwas mit Hardware und
Systemprogrammierung zu tun gehabt? Was qualifiziert Dich eigentlich,
Deinen Klappe so weit aufzureissen? Wuerde mich mal ernsthaft
interessieren!

queue