nForce Next

[Demirug]

Ob dieser neue Chipsatz wirklich "nForce-Next" heisen wird kann ich natürlich nicht sagen. Es ist auch eigentlich kein Chipsatz sondern eine ganze Chipsatzfamile.

Kern eines jeden Chips ist ein Switch an den alle Geräte mit einer Punkt zu Punkt Verbindung angeschlossen sind. Soweit noch nichts besonderes. Der Gag kommt jetzt. Es ist ein IP-Switch mit DHCP-Server und "Quality Of Service". Dadurch können sich die einzelnen Geräte ohne die CPU unter Verwendung des IP-Protocols miteinader unterhalten. So kann der Harddisk-Controller direkt zur VPU (Video Processing Unit) streamen und diese streamt dann nach dem dekodieren zur GPU weiter. Soweit so gut aber das Spiel geht noch weiter.

Sobald an dem Switch selbst wieder ein Gerät hängt das Zugang zu einem externen IP-Netzwerk hat kann man auch über die Systemgrenze hinweg streamen. Also zum Beispiel den Sound direkt zur Steroanlage. Auch die geziehlte Remoteaktivierung einzelner Geräte ist möglich solange die Zugangspunkt laufen. Man kann also von der Set-Top Box (natürlich mit nForce Next Chipsatz) im Wohnzimmer die Festplatte (und nur die Festplatte und den IP-Switch) im PC einschalten um einen Film von dieser zu holen.

Für lokale CPU-Geräte Verbindungen gibt es noch zusätzlich einen Highspeed Kanal bei dem sich beide eine Speicherbereich teilen und darüber daten austauschen können.

Als zusätzliches Feature haben die Chipsätze noch eine Option um mehrer virtuelle Systeme zu verwalten. Jedem dieser Systeme kann man Geräte zuordnen (auch entfernte) und auf jedem ein beliebiges OS laufen lassen. Über das jederzeit zugängliche Chipsatz-OS kann man dann zwischen den Systemen schnell umschalten.

PS: Ich habe mir das nicht aus den Fingern gesaugt das ist eine Idee die so wirklich von nVidia kommt.

[reunion]

Original geschrieben von Demirug
Ob dieser neue Chipsatz wirklich "nForce-Next" heisen wird kann ich natürlich nicht sagen. Es ist auch eigentlich kein Chipsatz sondern eine ganze Chipsatzfamile.

Kern eines jeden Chips ist ein Switch an den alle Geräte mit einer Punkt zu Punkt Verbindung angeschlossen sind. Soweit noch nichts besonderes. Der Gag kommt jetzt. Es ist ein IP-Switch mit DHCP-Server und "Quality Of Service". Dadurch können sich die einzelnen Geräte ohne die CPU unter Verwendung des IP-Protocols miteinader unterhalten. So kann der Harddisk-Controller direkt zur VPU (Video Processing Unit) streamen und diese streamt dann nach dem dekodieren zur GPU weiter. Soweit so gut aber das Spiel geht noch weiter.

Sobald an dem Switch selbst wieder ein Gerät hängt das Zugang zu einem externen IP-Netzwerk hat kann man auch über die Systemgrenze hinweg streamen. Also zum Beispiel den Sound direkt zur Steroanlage. Auch die geziehlte Remoteaktivierung einzelner Geräte ist möglich solange die Zugangspunkt laufen. Man kann also von der Set-Top Box (natürlich mit nForce Next Chipsatz) im Wohnzimmer die Festplatte (und nur die Festplatte und den IP-Switch) im PC einschalten um einen Film von dieser zu holen.

Für lokale CPU-Geräte Verbindungen gibt es noch zusätzlich einen Highspeed Kanal bei dem sich beide eine Speicherbereich teilen und darüber daten austauschen können.

Als zusätzliches Feature haben die Chipsätze noch eine Option um mehrer virtuelle Systeme zu verwalten. Jedem dieser Systeme kann man Geräte zuordnen (auch entfernte) und auf jedem ein beliebiges OS laufen lassen. Über das jederzeit zugängliche Chipsatz-OS kann man dann zwischen den Systemen schnell umschalten.

PS: Ich habe mir das nicht aus den Fingern gesaugt das ist eine Idee die so wirklich von nVidia kommt.

Soll diese option schon im nächsten Nforce-Chipsatz enthalten sein oder ist das nur eine Idee???

Und was für Vorteile würde das eigendlich bringen außer einer vermutlich höheren Geschw.???

[Gast]

Total Connectivity im Total-Media-Home-Network bei maximiertem Ease-of-Use und environment friendly power-saving and noise prevention features.

Genug Anglizismen?

Q

[Demirug]

Original geschrieben von Gast
Total Connectivity im Total-Media-Home-Network bei maximiertem Ease-of-Use und environment friendly power-saving and noise prevention features.

Genug Anglizismen?

Q

Warst du bei Huang und Vivoli zum Kaffe drinken?

[Demirug]

Was ich noch vergessen habe. Es gibt da eine Liste mit möglichen Geräten (PU = Processing Unit) die man anschliessen könnte. Darunter gibt es auch eine PPU. Dabei soll es es sich um eine Physik Processing Unit handeln. Diese soll Physikalische Berechnungen beschleunigen.

[Winter[Raven]]

wow ... klingt ja schon nicht schlecht. Die Frage ist und bleibt wie es dann umgesetzt wird. Aber um die Wahrheit zu sagen, trau ich NV alles zu.

Ahso, und mir soll einer Erzählen NVidia sei nicht Innovative.

[ethrandil]

Ehrm, seh ich das Richtig, dass dann erstmal "tcpip-kodierer" vor die IDE-Geräte geschaltet werden müssen, und nach und nach die Geräte nativ tcpip unterstützen werden?
Wär ja mal was um das immernoch recht statische Modell der "Karten" abzulösen =)
Auch für verteiltes Rechnen nicht übel.

Allerdings müsste das 'Bios' verglichen mit heutigen wesentlich flexibler sein, z.B. Treiber unterstützen. Oder wird das das Betriebssystem irgendwie übernehmen? ... hmmm hmm ...

recht interessant :)

Allerdings wird der Overhead auf den Datenleitungen steigen...

[Bokill]

Hängen diese Überlegungen nicht "zufällig" mit dem Hypertransportlink zusammen?

Jedenfalls klingt dieser Text fast so wie eine Produktbeschreibung eines weiteren HTr- Link tauglichen Chips.

Hypertransport ist ja schon derzeit über die Hammerplattform hinaus in anderen Bereichen vertreten.

NVIDIA, MIPS, Transmeta, SUN, Cisco, PMC- Sierra, Broadcom Corp., SGI und Apple waren ja schon die weiteren Gründungsmitglieder des Hypertransportkonsortiums.

[Quasar]

Original geschrieben von Demirug
Warst du bei Huang und Vivoli zum Kaffe drinken?

Nicht direkt, nur auf den letzten beiden CeBit-PKs und da dreht sich das meiste schon um das digital vernetzte Heim. War nur halt nie so berichtsträchtig, wie die neuesten Geforce-Spekulationen. ;)

[mrdigital]

klingt spannend, aber ich weiss nicht, ob sich der aufwand lohnt, jedem Teil IP beizubringen, denn dass was die da beschreiben kann man auch anderst lösen, nur mit weniger Fehlerquellen ;) Wenn jeder meiner Chips / Komponenten / was auch immer IP spricht, dann will ich nicht Firmwareprogrammierer sein. Zumal das IP Protokoll nicht unbedingt für niedrige Latenzzeiten spricht. Ich bin da ein wenig skeptisch, aber die Idee klingt interessant. Hast du mehr Details zu dieser Technik, Demirug?

[Bokill]

Das Hypertransportprotokoll ist Paketbasiert, jeder Chip hat lediglich eine Punkt zu Punkt Verbindung...

weswegen sollte da jede Komponente da eigene IP- Adressen haben?

Vermutlich wandelt dort ein "Netzwerkchip" das IP- Datenpaket in ein Datenpaket für HTr um.

Das HTr- System ermöglicht gleichsam das Zusammenstückeln wie ein legospiel.

[Crushinator]

Original geschrieben von Demirug
(...) Sobald an dem Switch selbst wieder ein Gerät hängt das Zugang zu einem externen IP-Netzwerk hat kann man auch über die Systemgrenze hinweg streamen. Also zum Beispiel den Sound direkt zur Steroanlage. Auch die geziehlte Remoteaktivierung einzelner Geräte ist möglich solange die Zugangspunkt laufen. Man kann also von der Set-Top Box (natürlich mit nForce Next Chipsatz) im Wohnzimmer die Festplatte (und nur die Festplatte und den IP-Switch) im PC einschalten um einen Film von dieser zu holen. (...) Oh' toll, Du hast so eben IP-Streaming erfunden. Schade nur, daß man es mit entsprechender Software, Settop-Boxen mit Ethernet (sogar mit lange verfügbaren in Nordamerika gut verbreiteten ATI-Chipsätzen) oder notfalls Bridges, die aus fast allem Ethernet-Frames und IP-Pakete machen bereits heute haben kann. ;) Der Rest hört sich ja nach ganz normalem P-t-P Switching innerhalb eines Chipsatzes an - was auf Hypertransport/Infiniband/V-Link und die sonstigen verfügbaren (propritären) Techniken schließen läßt - was um eine IMHO sinnlose (weil aufwendige) Protokollschicht in Form von IP ergänzt wurde.
PS: Ich habe mir das nicht aus den Fingern gesaugt das ist eine Idee die so wirklich von nVidia kommt. Die Idee verfolgt auch eine andere - sich vom Purpurtentakel angesteckte - Firma, nämlich Microsoft und ist damit ziemlich weit gekommen, nämlich gar nicht. Allerdings würde ich nur zu gerne sehen, wie man 5+1 oder mehr Roh-Audio-Kanäle mit dem selben "IP-Switch" zur Stereoanlage transportiert, über den auch der sonstige externe IP-Verkehr wie z.B. in Form eines 3,7 MBit/s Videostreams läuft.

[Gast]

Diese PPU klingt interessant, allerdings sehe ich nicht so richtig eine Zielgruppe dafuer. Anyone else?

[Ailuros]

Ahso, und mir soll einer Erzählen NVidia sei nicht Innovative.

Ich koennte Dir viele interessante Geschichten ueber's nForce Team erzaehlen und welche Talente es genau durch die Jahre aufgesaugt hat :P

[zeckensack]

Original geschrieben von Demirug
Kern eines jeden Chips ist ein Switch an den alle Geräte mit einer Punkt zu Punkt Verbindung angeschlossen sind. Soweit noch nichts besonderes. Der Gag kommt jetzt. Es ist ein IP-Switch mit DHCP-Server und "Quality Of Service". Dadurch können sich die einzelnen Geräte ohne die CPU unter Verwendung des IP-Protocols miteinader unterhalten. So kann der Harddisk-Controller direkt zur VPU (Video Processing Unit) streamen und diese streamt dann nach dem dekodieren zur GPU weiter.Braucht man dafür nicht ein vernünftiges OS? *hust* pipes *hust*

Oder kriegt Windows das auch irgendwie hin?

[Ailuros]

Es duerfte kein Zufall sein dass es (voruebergehend?) "Next" heisst.

[Demirug]

Original geschrieben von zeckensack
Braucht man dafür nicht ein vernünftiges OS? *hust* pipes *hust*

Oder kriegt Windows das auch irgendwie hin?

Windows hätte damit genauso Probleme oder eben keine wie jedes andere OS.

Im Prinzip würde ja nur alle Geräte (oder PUs wie nVidia das nennt) erst einmal als Hot-Plug fähig deklariert. Treiber wie bisher bräuchte man ja nicht mehr weil die Geräte dann ja genormte höhere Protokolle auf IP Basis beherschen müssten. Ich sehe das Problem eher auf der Seite der Anwendungsprogramme. Mach einmal deinem Player verständlich das er zwischen den Beteiligten Geräten die Streamverbindungen aufbauen soll und dann über ein Kommando an die Festplatte den Wiedergabe startet. Software die damit umgehen kann gibt es einfach noch nicht.

Da man sich bei nVidia ja aber nicht sein eigenes Grab schaufeln möchte (wegen inkompatibilitäten) gibt es da eine Interopschnittstelle in zwei Richtungen.

Zum einen kann man bei der Definition der virtuellen Systeme die PUs als "Clasic" Hardware auf die bekannten Resourcen (IO-Port, Memory-Mapped RAM, Interrupts) mappen. (geht wohl mit Plug and Play fast von aleine so wie ein Sendersuchlauf beim Fernseher) Der Chipssatz übernimmt dann das übersetzten zwischen den Clasic-Zugriffen und den IP-Protokollen. Auf der anderen Seite können PUs auch von der CPU zur Verfügung werden. In diesem Fall würden die IP-Packte zur CPU gehen und dort dekodiert werden. Dann könnte die CPU auf ein "altes" Gerät direkt zugreifen.

[zeckensack]

Original geschrieben von Demirug
Windows hätte damit genauso Probleme oder eben keine wie jedes andere OS.

Im Prinzip würde ja nur alle Geräte (oder PUs wie nVidia das nennt) erst einmal als Hot-Plug fähig deklariert. Treiber wie bisher bräuchte man ja nicht mehr weil die Geräte dann ja genormte höhere Protokolle auf IP Basis beherschen müssten. Ich sehe das Problem eher auf der Seite der Anwendungsprogramme. Mach einmal deinem Player verständlich das er zwischen den Beteiligten Geräten die Streamverbindungen aufbauen soll und dann über ein Kommando an die Festplatte den Wiedergabe startet. Software die damit umgehen kann gibt es einfach noch nicht.Das ist klar. Ich spielte darauf an, daß auch der Kernel (bzw die API zum Kernel) das ganze unterstützen können muß, bevor man überhaupt Software darauf aufsetzen kann.

Und da hat Windows traditionell eben riesige Probleme. Man denke hier an ganz banale Dinge wie USB-"Support". Bei Unix schreibt man einfach ein Modul, das das ganze nach /dev/usb mappt und kann loslegen, zumindest die Lauffähigkeit ist erreicht. Hot Plug ist eine separate Angelegenheit, aber auch schon lange gelöst. Die ganze Grundarchitektur ist einfach viel flexibler, eben weil Unix ... Unix ist ("alles verhält sich wie eine Datei").

"named pipes" gibt's auf zB Linux schon seit Ewigkeiten, und diese bieten tatsächlich die nötige Semantik für Routing-Aufgaben. Man kann einen Daemon schreiben, der Traffic auf bestimmten pipe-Namen abhört und dann die Dinge ins Rollen bringt. Das gleiche Nutzungsmodell ist auch für 'alte' Hardware einsetzbar. Man braucht den Kernel nichtmal anzufassen ...

[Demirug]

Original geschrieben von zeckensack
Das ist klar. Ich spielte darauf an, daß auch der Kernel (bzw die API zum Kernel) das ganze unterstützen können muß, bevor man überhaupt Software darauf aufsetzen kann.

Und da hat Windows traditionell eben riesige Probleme. Man denke hier an ganz banale Dinge wie USB-"Support". Bei Unix schreibt man einfach ein Modul, das das ganze nach /dev/usb mappt und kann loslegen, zumindest die Lauffähigkeit ist erreicht. Hot Plug ist eine separate Angelegenheit, aber auch schon lange gelöst. Die ganze Grundarchitektur ist einfach viel flexibler, eben weil Unix ... Unix ist ("alles verhält sich wie eine Datei").

Wenn es nur um Lauffähigkeit geht kannst du das bei Windows genauso machen. Ich habe hier einen Treiber für ein USB-Gerät für Windows NT 4.0. Das Treibermodel von NT verhält sich genauso. Alles ist eine Datei.

"named pipes" gibt's auf zB Linux schon seit Ewigkeiten, und diese bieten tatsächlich die nötige Semantik für Routing-Aufgaben. Man kann einen Daemon schreiben, der Traffic auf bestimmten pipe-Namen abhört und dann die Dinge ins Rollen bringt. Das gleiche Nutzungsmodell ist auch für 'alte' Hardware einsetzbar. Man braucht den Kernel nichtmal anzufassen ...

Bei NT sind die auch schon immer drin. Neben einer ganzen Reihe von zusätzlichen Interprozess Kommunikations Verfahren.

Beim dritten OS-Kernel in Folge sollte jemand auch wissen wie man es macht.

[Crushinator]

Original geschrieben von Demirug
Wenn es nur um Lauffähigkeit geht kannst du das bei Windows genauso machen. Ich habe hier einen Treiber für ein USB-Gerät für Windows NT 4.0. Das Treibermodel von NT verhält sich genauso. Alles ist eine Datei. Es ist aber immernoch kein Vergleich, da Dein USB-Gerät nur durch explizit an diesen Treiber "gelinkte" Software angesprochen werden kann. Ich wüßte nicht, daß man den NT-Kernel durch einen Treiber um eine allgemeine Geräteklasse für systemweiten Zugriff erweitern könnte, was dagegen durch mappen von "/dev/usb" unter den Unices eben möglich ist.

[Demirug]

Original geschrieben von crushinator
Es ist aber immernoch kein Vergleich, da Dein USB-Gerät nur durch explizit an diesen Treiber "gelinkte" Software angesprochen werden kann. Ich wüßte nicht, daß man den NT-Kernel durch einen Treiber um eine allgemeine Geräteklasse für systemweiten Zugriff erweitern könnte, was dagegen durch mappen von "/dev/usb" unter den Unices eben möglich ist.

Du kannst unter NT einen Treiber auch dorthin mappen wohin du ihn haben möchtest. Mit einer komplett neue Geräteklasse kann aber eine vorhanden Software sowieso nichts anfangen. Benutzt man eine vorhanden und implementiert dafür die notwendigen IO-Kommandos funktioniert das ohne Probleme.

[zeckensack]

Original geschrieben von Demirug
Wenn es nur um Lauffähigkeit geht kannst du das bei Windows genauso machen. Ich habe hier einen Treiber für ein USB-Gerät für Windows NT 4.0. Das Treibermodel von NT verhält sich genauso. Alles ist eine Datei.?(
Dann verrate mir bitte das Windows-Äquivalent:
more < /dev/rtc

Oder alternativFILE* f=fopen("/dev/rtc","r");
fgets(f,<...>);
.
.
.

Und was sagst du dazu:
mount /dev/usb/rio500 /mnt/flash-knueppel
vs
mount ./flash-image /mnt/flash-knueppel

*verwirrtist*

[Demirug]

Original geschrieben von zeckensack
?(
Dann verrate mir bitte das Windows-Äquivalent:
more < /dev/rtc

Oder alternativFILE* f=fopen("/dev/rtc","r");
fgets(f,<...>);
.
.
.

Copy and Paste aus einem Projekt mit Spezialhardware


DeviceName.Format ("\\\\.\\NATMiniDev%i", m_CardID);

m_hNat = CreateFile(DeviceName, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);



Und was sagst du dazu:
mount /dev/usb/rio500 /mnt/flash-knueppel
vs
mount ./flash-image /mnt/flash-knueppel

*verwirrtist*

Das man bei NT nicht Mounten kann weist du doch. Aber um neue Laufwerke in das System zu bringen benutzt man den guten alten virtuellen SCSI-Adapter Trick. Damit bekommt man sogar Wechselmedien zum Laufen.

[Crushinator]

Original geschrieben von Demirug
Du kannst unter NT einen Treiber auch dorthin mappen wohin du ihn haben möchtest. Was sagte ich denn vorhin? Man kann nur dahin mappen, wofür eine Klasse existiert und keine neue - wie bei USB als Generic Hotplugable Device notwendig - erstellen.
Mit einer komplett neue Geräteklasse kann aber eine vorhanden Software sowieso nichts anfangen. Benutzt man eine vorhanden und implementiert dafür die notwendigen IO-Kommandos funktioniert das ohne Probleme. Natürlich kann vorhandene Software damit was anfangen, wenn die neue Klasse davon z.B. normale Blockgeräte oder Capture-Devices exportiert. Das Problem bei NT und Nachfolgern ist ja leider, daß man für "Klassen" die die HAL nicht von Haus aus zur Verfügung stellt auch keine Treiber schreiben kann, die jene Klasse komplett abbilden können. Diesbezüglich finde ich Linux & Co. wesentlich flexibler.

[Demirug]

Original geschrieben von crushinator
Was sagte ich denn vorhin? Man kann nur dahin mappen, wofür eine Klasse existiert und keine neue - wie bei USB als Generic Hotplugable Device notwendig - erstellen.

Das Mapping ist ja primär nur ein Name unter dem das Gerät ansprechbar ist. Dann kann zwar Anwendung darauf zugreifen nur was nutzt das wenn die Anwendung das datenformat das dieses Gerät liefert nicht versteht?

Natürlich kann vorhandene Software damit was anfangen, wenn die neue Klasse davon z.B. normale Blockgeräte oder Capture-Devices exportiert. Das Problem bei NT und Nachfolgern ist ja leider, daß man für "Klassen" die die HAL nicht von Haus aus zur Verfügung stellt auch keine Treiber schreiben kann, die jene Klasse komplett abbilden können. Diesbezüglich finde ich Linux & Co. wesentlich flexibler.

Bist du sicher das du die NT-Kernel Konzepte verstanden hast und weisst was die einzelnen Teilen machen?

Der HAL stellt lediglich eine genormte Schnittstelle auf Basis Resourcen (IO-Ports, DMA, Memorymapped IO, IRQs) da.

Als Lektüre empfehle ich "Inside Windows NT"

Andere Schnitstellen sind auf höhere Ebene genormt und da kann man selber welche ergänzen. Ich kann also ohne Probleme eine neue Klasse von Geräten definieren. Nur was nutzt das wenn es keine Anwendungen gibt die mit dieser Klasse was anfangen können?

[StefanV]

Hm, ist eine Architektur, die auf dem IP Protokoll aufbaut nicht unsicher und anfällig für Zugriffe von außen?? :|

Irgendwie könnte ich mir vorstellen, daß man mit so einer Architektur 'von außen' auf den Rechner zugreifen kann und jenen problemlos ausspionieren könnte :|

[ScottManDeath]

@Demirug
OT: ich suche einen generischen usb treiber der es mir ermöglicht mittels CreateFile (so wie du es beschrieben hast) auf einen usb port meiner wahl daten zu schicken. kennst du sowas? ich will damit einem dsp-system mit usb port daten schicken/bekommen.


HANDLE m_dsp = CreateFile("\\\\USB0",FILE_READ .....);

[Demirug]

Original geschrieben von ScottManDeath
@Demirug
OT: ich suche einen generischen usb treiber der es mir ermöglicht mittels CreateFile (so wie du es beschrieben hast) auf einen usb port meiner wahl daten zu schicken. kennst du sowas? ich will damit einem dsp-system mit usb port daten schicken/bekommen.


HANDLE m_dsp = CreateFile("\\\\USB0",FILE_READ .....);


Von welchem OS reden wir überhaupt? Direkt bekannt ist mir jetzt keiner aber im DDK sind Sourcecodes für USB-Treiber dabei die man leicht anpassen kann wenn man ein paar Details bezüglich des USB Geräts hat.

[Bokill]

Ich glaube einige sollten sich mal die Dokus zum Hypertranasportlink reinziehen... oder in 1 bis 2 Wochen mal bei P3D hereinschauen...

[Crushinator]

Original geschrieben von Demirug
Bist du sicher das du die NT-Kernel Konzepte verstanden hast und weisst was die einzelnen Teilen machen? Ja, schließlich schreibe ich nur seit ca. 7 Jahren Treiber dafür.
(...) Der HAL stellt lediglich eine genormte Schnittstelle auf Basis Resourcen (IO-Ports, DMA, Memorymapped IO, IRQs) da. Ach ja? :) und muß die HAL von NT4 denn NICHT angepaßt werden, wenn ich z.B. eine NUMA-Architektur habe oder kann ich mir dann auch einen Treiber schreiben, der das gerade biegt? ;)
Als Lektüre empfehle ich "Inside Windows NT" Thanx, die kenn' ich fast schon auswendig. Die DVDs von MSDN-Universal und praktische Anwendung finde ich persönlich viel besser.
Andere Schnitstellen sind auf höhere Ebene genormt und da kann man selber welche ergänzen. Ich kann also ohne Probleme eine neue Klasse von Geräten definieren. Nur was nutzt das wenn es keine Anwendungen gibt die mit dieser Klasse was anfangen können? Das meine ich doch die ganze Zeit. Man kann keine komplett neue Klasse deffinieren und daraus Geräte für andere (existiernde) Klassen erstellen. Um jetzt nicht noch weiter aneinander vorbeizureden: Wieso entwickelt Keiner eine Geräte-Klasse für NT die absolut der von Win2K für USB entspricht, damit geeignete Treiber z.B. ein Digicam als Capture-Device systemweit anbieten können? :naughty: Vielleicht deshalb weil der Kernel keine geeignete Grundklasse dafür zur Verfügung stellt?

Unter Linux mappe ich das Gerät durch meinen "Treiber" einfach auf "/dev/dcxx0" und stelle es damit - notfalls durch Emulation anderer Geräte-Befehlsätze - jedem existiernden Grabber-Proggi zur Verfügung.

[ScottManDeath]

Original geschrieben von Demirug
Von welchem OS reden wir überhaupt? Direkt bekannt ist mir jetzt keiner aber im DDK sind Sourcecodes für USB-Treiber dabei die man leicht anpassen kann wenn man ein paar Details bezüglich des USB Geräts hat.

Win 2K/XP
da werd ich mal die hochschule fragen ob sie das DDK mit der MSDN bekommen haben da es das nicht mehr wie das für Win2K zum download gibt. und dann mal stöbern gehen. ich wollte eigentlich mich davor drücken ;)

thx so far

[Crushinator]

Original geschrieben von ScottManDeath
OT: ich suche einen generischen usb treiber der es mir ermöglicht mittels CreateFile (so wie du es beschrieben hast) auf einen usb port meiner wahl daten zu schicken. kennst du sowas? ich will damit einem dsp-system mit usb port daten schicken/bekommen. Libusb-win32 (http://libusb-win32.sourceforge.net/) könnte Dir da IMHO am einfachsten weiterhelfen. :)

/edit: Binaries sind da (http://sourceforge.net/project/showfiles.php?group_id=78138).

[ScottManDeath]

cool, thx, werd ich mir mal genauer anschauen, sieht nach kurzem überfliegen genau nach dem aus was ich suche :)

[Demirug]

crushinator, ja ich glaube wir reden da wirklich irgendwie aneinader vorbei.

Das NT 4.0 keine USB Geräte unterstützt liegt doch an den fehlenden Plug und Play Fähigkeiten und vorallem an der fehleden Unterstützung für Hot-Plug. Wenn man mit bestimmten Begrenzungen zu leben bereit ist lassen sich USB Geräte aber trotzdem zum Laufen bringen.

Aber kommen wir nochmal auf das Beispiel mit dem Grabber zurück. Woher weiss das Grapper-Programm wie man die Daten von der Hardware abfragt? Scheinbar muss das ja mal festgelegt worden sein. Schreibt man nun einen Treiber der sich an diese Festlegung hält kann sich das Grapper-Programm auch von der entsprechenden Hardware bedienen. Darin unterscheiden sich Linux und NT überhaupt nicht. Falls eine Emulation notwendig ist kann man sich ja mit Filtertreiber helfen.

Gibt es für ein Gerät noch keine Klasse dann gibt es logischerweise auch noch keine Programme die mit dieser Art von Gerät etwas anfangen könnten. Schreibt man sich nun aber denoch einen Treiber und ein passendes Programm hat man im gleichen Moment eine neue Geräte-Klasse definiert. Macht man diese öffentlich könnten auch anderer für ihere Hardware entsprechenden Treiber schreiben die dann mit dem nun vorhandenen Programm läuft oder es könnte jemand auch ein anderes Programm für die Hardware schreiben.

Ich hatte es öfter mit Spezial-Karten zu tun die in keine der vorhandenen Klassen gepasst haben. Da haben sich die Hersteller jeweils auch einfach eine neue Geräte-Klasse definiert. Damit sie aber nicht so viel internas rausrücken müssen gab es dann gleich noch eine DLL dazu welche die Kommunikation mit dem Treiber übernommen hat und die Funktionen als API zur Verfügung stellt. Würde man nun für eine anderer Hardware einen Treiber schreiben der sich auch an das entsprechende Protokoll hält könnte jedes Programm das die entsprechende API benutzt automatisch auch mit dieser Hardware arbeiten.

Ich kann also beim besten Willen da keine Unterschiede zwischen NT und Linux feststellen.

[Crushinator]

Original geschrieben von Demirug
crushinator, ja ich glaube wir reden da wirklich irgendwie aneinader vorbei. Das tun wir fast immer. ;D
Das NT 4.0 keine USB Geräte unterstützt liegt doch an den fehlenden Plug und Play Fähigkeiten und vorallem an der fehleden Unterstützung für Hot-Plug. Wenn man mit bestimmten Begrenzungen zu leben bereit ist lassen sich USB Geräte aber trotzdem zum Laufen bringen. Das stimmt nicht ganz, denn sowohl PnP als auch Hot-Plug funktionieren einigermaßen. Noch keine SB16 PnP im NT4-Rechner gehabt? ;) Hot-Plug läßt sich über SCSI am einfachsten realisieren. Ich habe auch schon für einen Kunden in einer 2 monatigen Aktion einen SCSI-Treiber für einen nicht näher zu nennennden USB-Controler realisiert, über den ein Scanner eingebunden wurde, dessen selbstgeschriebenen TWAIN32-Treiber Photoshop zum scannen benutzt, und es funktioniert mittlererweile auch ganz gut.
Aber kommen wir nochmal auf das Beispiel mit dem Grabber zurück. Woher weiss das Grapper-Programm wie man die Daten von der Hardware abfragt? Scheinbar muss das ja mal festgelegt worden sein. Schreibt man nun einen Treiber der sich an diese Festlegung hält kann sich das Grapper-Programm auch von der entsprechenden Hardware bedienen. Darin unterscheiden sich Linux und NT überhaupt nicht. Falls eine Emulation notwendig ist kann man sich ja mit Filtertreiber helfen. Natürlich unterscheiden sie sich am meisten in der Art wie Programme mit den Treibern bzw. dessen draufgesetzten Schichten kommunizieren, kurz API gennant. :D Unter Linux kann ich relativ einfach (sogar aus einem pipe) ein neues Gerät erstellen, womit die Anwendungen glücklich werden, während ich unter Windows im genannten Falle des Grabbers auch die ganze "WDM Video Capture" Schnittstelle nachbilden muß, nur damit die entsprechenden für Win2K+ exisitiernden Programme was mit dem neuen Gerät anfangen können. Leider läßt sich "WDM Video Capture" unter NT4 kaum nachbilden, da weder die notwendige Kernelschicht (WDM-Unterstützung) ohne Kernelsource zu realisieren ist noch die User-Schicht, weil die API stark mit jener Kernelschicht verzahnt ist.

Was ich damit sagen will ist, daß man unter Windows in solchen Fällen zu viel vom Kernel (siehe WDM) und dann noch der API abhängig ist, während es unter Linux wegen der simplen Prozeß-Interkommunikation nur reicht, wenn ein "/dev/dcxx0" trotz eines Uraltkernel gemappt wird, während es völlig egal ist, wie die Kernelschicht implementiert wurde. Die angesprochene Emulation findet dann im Device-Mapper statt.
Ich hatte es öfter mit Spezial-Karten zu tun die in keine der vorhandenen Klassen gepasst haben. Da haben sich die Hersteller jeweils auch einfach eine neue Geräte-Klasse definiert. Damit sie aber nicht so viel internas rausrücken müssen gab es dann gleich noch eine DLL dazu welche die Kommunikation mit dem Treiber übernommen hat und die Funktionen als API zur Verfügung stellt. Würde man nun für eine anderer Hardware einen Treiber schreiben der sich auch an das entsprechende Protokoll hält könnte jedes Programm das die entsprechende API benutzt automatisch auch mit dieser Hardware arbeiten. Es sei denn, es handelt sich um ein Gerät, wofür die verbreitete MS-Schnittstelle erst gar nicht unter dem Betriebssystem existiert, wie z.B. WDM Video Capture unter NT.

[Demirug]

Original geschrieben von crushinator
Das stimmt nicht ganz, denn sowohl PnP als auch Hot-Plug funktionieren einigermaßen. Noch keine SB16 PnP im NT4-Rechner gehabt? ;)

Ja, ich hatte eine SB16 PnP in einem NT4-Rechner. Hat auch wunderbar funktioniert bis ich die Karte in einen anderen Slot gesteckt habe. Dabei wurden die Resourcen durcheinader gewürfelt und da ein paar Treiber so schlau waren und die PnP-Daten nur bei der Instalation abzufragen konnte ich dann nochmal anfangen Treiber zu Installieren. Du hast aber recht das war eher ein Problem der Treiber den von NT.

Hot-Plug läßt sich über SCSI am einfachsten realisieren. Ich habe auch schon für einen Kunden in einer 2 monatigen Aktion einen SCSI-Treiber für einen nicht näher zu nennennden USB-Controler realisiert, über den ein Scanner eingebunden wurde, dessen selbstgeschriebenen TWAIN32-Treiber Photoshop zum scannen benutzt, und es funktioniert mittlererweile auch ganz gut.

Ja über "SCSI-Treiber" lässt sich eine ganze Menge anstellen. :D

Natürlich unterscheiden sie sich am meisten in der Art wie Programme mit den Treibern bzw. dessen draufgesetzten Schichten kommunizieren, kurz API gennant. :D Unter Linux kann ich relativ einfach (sogar aus einem pipe) ein neues Gerät erstellen, womit die Anwendungen glücklich werden, während ich unter Windows im genannten Falle des Grabbers auch die ganze "WDM Video Capture" Schnittstelle nachbilden muß, nur damit die entsprechenden für Win2K+ exisitiernden Programme was mit dem neuen Gerät anfangen können.

Leider läßt sich "WDM Video Capture" unter NT4 kaum nachbilden, da weder die notwendige Kernelschicht (WDM-Unterstützung) ohne Kernelsource zu realisieren ist noch die User-Schicht, weil die API stark mit jener Kernelschicht verzahnt ist.

Was ich damit sagen will ist, daß man unter Windows in solchen Fällen zu viel vom Kernel (siehe WDM) und dann noch der API abhängig ist, während es unter Linux wegen der simplen Prozeß-Interkommunikation nur reicht, wenn ein "/dev/dcxx0" trotz eines Uraltkernel gemappt wird, während es völlig egal ist, wie die Kernelschicht implementiert wurde. Die angesprochene Emulation findet dann im Device-Mapper statt.

Jetzt, habe ich verstanden auf was du hinaus möchtest. Es geht dir um das Problem das bestimmte Runtimes für ältere Windows Versionen nicht mehr verfügbar gemacht werden und daher Anwendungen die auf diese Runtimes aufbauen nicht zum laufen zu bekommen sind.

Das ist jetzt aber kein Problem der Kernelarchitektur sondern eine Folge davon das MS bei Windows auf ein Mehrschichtmodel mit Runtimes setzt. Das hat ja durchaus auch seine Vorteile da die Runtimes immer wieder anfallende Arbeitsschritte gleich übernehmen können.

Linux ist dagegen wie du schon sagst eher Flach aufgebaut. Der Verzicht auf Runtimes hat sicherlich seine Vorteile. Allerdings fördert dies auch durchaus eine Aufsplitterung der Kräfte (OK, es gibt genügend die für Ruhm und Ehre bereit sind zu arbeiten) indem für die gleiche Aufgabe mehrfach unterschiedliche Bibliotheken geschrieben werden. Genauso kann es durchaus passieren das zwei Leute die voneinader nichts wissen für die gleiche Art von Geräten zwei Unterschiedliche Treiberschnittstellen + API entwickeln. Dann kann man anfangen fleisig Filtertreiber zu schreiben.

Sowas musste ich mal mit Framegrapper (noch zu DOS/Windows 3.11 Zeiten) erleben. Es wurde ein Framegrapper A mit Software B benutzt. Nun gab es allerdings ein Problem (weiss nicht mehr genau was es war) weswegen man Framegrapper A nicht mehr benutzten konnte. Die Software wollte aber nicht mit den neuen Grapper nicht zusammenarbeiten weil diese unterschiedliche APIs hatten.

Es sei denn, es handelt sich um ein Gerät, wofür die verbreitete MS-Schnittstelle erst gar nicht unter dem Betriebssystem existiert, wie z.B. WDM Video Capture unter NT.

Wobei einem dann immer noch frei steht eine eigene Schnittstelle zu schafen. Damit könnte man aber auch alle Programme die auf eine andere Schnittstelle aufsetzten vergessen. Aber zum laufen würde man es bekommen.

[Xmas]

Original geschrieben von Stefan Payne
Hm, ist eine Architektur, die auf dem IP Protokoll aufbaut nicht unsicher und anfällig für Zugriffe von außen?? :|

Irgendwie könnte ich mir vorstellen, daß man mit so einer Architektur 'von außen' auf den Rechner zugreifen kann und jenen problemlos ausspionieren könnte :|
Wieso sollte IP unsicherer sein als jedes andere Protokoll? Nur weil der Aufbau bekannt ist?

[Crushinator]

Original geschrieben von Demirug
(...) Linux ist dagegen wie du schon sagst eher Flach aufgebaut. Der Verzicht auf Runtimes hat sicherlich seine Vorteile. Allerdings fördert dies auch durchaus eine Aufsplitterung der Kräfte (OK, es gibt genügend die für Ruhm und Ehre bereit sind zu arbeiten) indem für die gleiche Aufgabe mehrfach unterschiedliche Bibliotheken geschrieben werden. Genauso kann es durchaus passieren das zwei Leute die voneinader nichts wissen für die gleiche Art von Geräten zwei Unterschiedliche Treiberschnittstellen + API entwickeln. Dann kann man anfangen fleisig Filtertreiber zu schreiben. Auch nicht ganz richtig. Es gibt sehr wohl sogenannte "Runtimes" mit API (siehe SANE als TWAIN-äquivalent oder video4linux für Video Capture) man muß als Treiberentwickler nur wiessen, wie sich das benötigte "/dev/wasauchimmer" verhalten muß - was man durch die Sources herausfinden kann - dann muß man jenes Verhalten implementieren und eben das Device mappen. Ein Mehrschichten-Runtime-Modell wie es MS gerne verwendet, läutet oft nur den Tod für deren ältere OSe.

OK, ich sehe ja ein, daß sie alle paar Jahre wieder mal das Volk mit vielen Sachen die es nicht baucht "beglücken" müssen, um an sein Bestes heranzukommen. Aber gut finden, tu' ich das aus den genannten Gründen nicht.
Wobei einem dann immer noch frei steht eine eigene Schnittstelle zu schafen. Damit könnte man aber auch alle Programme die auf eine andere Schnittstelle aufsetzten vergessen. Aber zum laufen würde man es bekommen. Verglichen mit den Möglichkeiten oder besser gesagt "Sitten" unter Linux ist es trotzdem zu unflexibel, und das pranger' ich an.

[StefanV]

Original geschrieben von Xmas
Wieso sollte IP unsicherer sein als jedes andere Protokoll? Nur weil der Aufbau bekannt ist?

Hm, war nur 'ne Frage an euch ;)

Hab selbst keinen Schimmer, obs unsicherer ist oder nicht.

Mein Gefühl sagt mir, daß das IP Protokoll unsicherer ist...

[Crushinator]

Original geschrieben von Stefan Payne
(...) Mein Gefühl sagt mir, daß das IP Protokoll unsicherer ist... Wenn Du meinst, daß man damit in der Lage wäre von Außen Deine über IP-Adresse (bei entsprechendem Routing) ansprechbare GPU "abzuschiessen", hat Dich Dein Gefühl nicht getäuscht, aber abgeschossen werden kann auch jetzt eine IP-fähige Settop-Box oder ein solcher Drucker. :)

[StefanV]

Original geschrieben von crushinator
Wenn Du meinst, daß man damit in der Lage wäre von Außen Deine über IP-Adresse (bei entsprechendem Routing) ansprechbare GPU "abzuschiessen", hat Dich Dein Gefühl nicht getäuscht, aber abgeschossen werden kann auch jetzt eine IP-fähige Settop-Box oder ein solcher Drucker. :)

Naja, eigentlich dachte ich an die Möglichkeit der Spionage.
Was man so alles im Rechner hat usw, inkl Platteninhalt.

'Dank' des IP Protokolls dürfte sich das auch recht leicht streamen lassen...

Und da nV ja bekanntlich Amis sind (CIA/NSA ahoi), könnte es ja sein, daß nV drum gebeten wurde....

[Crushinator]

Original geschrieben von Stefan Payne
Naja, eigentlich dachte ich an die Möglichkeit der Spionage. (...) Hmmm, laß mich mal überlegen :kratz2: ...hmmm... also wenn man danach ginge, wäre das optimale Spionagewerkzeug eigentlich Windows selbst, und wenn wir schon dabei sind dafür US-Unternehmen in Frage kommen zu lassen, würden mir (neben MS und nVIDIA) auf Anhieb noch 3Com und Intel als sogenannte "Network Solutions Provider" einfallen, die es aufgrund der Natur und der Verbreitung ihrer Hard- und Software (z.B. Netzwerkkarten und deren Treiber) um einiges leichter hätten ggf. spionierte Daten auch noch zum Empfänger zu übertragen.

[Xmas]

Original geschrieben von Stefan Payne
Mein Gefühl sagt mir, daß das IP Protokoll unsicherer ist...
Unsicherer als was? IP ist nicht per se sicher oder unsicher.

[zeckensack]

Original geschrieben von Xmas
Unsicherer als was? IP ist nicht per se sicher oder unsicher. IP lässt sich extrem leicht auf externe Netzwerke umlenken und um den halben Erdball senden (und Sniffer gibt's auch reichlich), eben weil die Infrastruktur die gleiche ist.

Das ist mit HT und anderen reinen onboard-Bussen derzeit einfach nicht möglich, ohne direkten Zugriff auf die Hardware zu haben.

Von daher kann ich die Bedenken schon verstehen.

Die Idee ist ähnlich wagemutig, wie TCP/IP an RPC zu koppeln ... :grübel:

[StefanV]

Original geschrieben von Xmas
Unsicherer als was? IP ist nicht per se sicher oder unsicher.
Anderrum:

Bei einer IP Switch Technology wäre es möglich direkt auf die HW zuzugreifen und 'von außen' direkt über die HW zuzugreifen, was bei einem Proprietärem Bus, dessen Spezifikation nur ausgewähnte Personen kennen, nicht der Fall.

Aktuelle Rechner kann man 'von Haus aus' nicht per Hardware fernsteuern.

Bei der Nforce Next Architektur wäre es aber zumindest theoretisch denkbar, von außen über das Internet (welches das gleiche Protokoll benutzt) auf die HW zuzugreifen...

Hm...
Das ganze könnte man mit entsprechend aufwendigen Verschlüsselungs Algos wieder hinbiegen, nur würde das a) Transistoren fressen und b) die Latenz steigern, also auch nicht wirklich das Wahre...

Irgendwie fühle ich mich nicht wohl dabei, wenn ich einen Chipsatz im Rechner hätte, der auf Basis des IP Protokolls arbeiten würde :|