Bei Kio ist mounten nicht notwendig, darum ist es nicht wirklich vergleichbar. Wünschenswerter wäre dass Kio die Kde nähe aufgibt und eine API für andere Programme gibt (darauf kann dann ja eine kde oder gnome spezifische API aufsetzen). Wenn die dafür geschriebene Slaves dann auch noch mit Fuse mountbar wären, das wäre überhaupt top.
Da eigentlich sowieso alle davon eine read/write/open/close API haben, müsste das doch möglich sein...
*träum*
Ich arbeite an einem anderen noch wichtigeren Projekt;) welches die Konfiguration vereinheitlicht. (http://www.libelektra.org und http://wiki.libelektra.org)
wieso nicht gleich gnome-vfs 2.x? das ist schon jetzt ziemlich eigenstaendig,braucht nur glib,gconf und orbit. und wsa is an mounten schlimm? so sehen es wenigstens alle apps! man kann ja mount so einrichten das user ihre user-space prozesse in ihren verzeichnissen mounten duerfen.
> wieso nicht gleich gnome-vfs 2.x? das ist schon jetzt ziemlich eigenstaendig,braucht nur glib,gconf und > orbit.
Dann braucht es ja eine ganze Menge. Auch kio braucht kaum das gesamte KDE/Qt System. Die ganzen Oberflächenelemente werden ja z.B. nicht benötigt.
Ich fände es aber auf jeden Fall auch gut, wenn gnom-vfs und kio zu einer Schicht verschmelzen würden, evtl. auch im Zusammenhang mit Fuse. Dann könnten alle Desktopumgebungen / Programme nutzen daraus ziehen.
aber als es die gnome-vfs definiert wurden, wurde hier einfach das Rad neu erfunden ohne tief erst einmal die KIO zu untersuchen. "Not invented here syndrom".
Da so vorgegangen wurde, ist natürlich das vereinheitlichen nun wieder ein Problem... Die Strukturen sind leider sehr unterschiedlich.
KIO ist C++ verwendet Qt und Kdelibs weiterhin passt es nicht zu glib apps (weil es sie und die ganzen typen davon einfach nicht verwendet) und verwendet kein orbit. kp wie stark das alles,aber alles gruende dafuer das es nicht in gnome passt.
Das Anfordern einen Slaves wird in KDE über DCOP gemacht. Soll das in KDE 4.0 nicht anders werden? Iirc soll da was Desktop übergreifendes zum Einsatz kommen und DCOP damit obsolet werden. Also können hier alle aufatmen und ein Flamewar ist nicht mehr nötig :-)
Von Kevin Krammer am Fr, 28. Oktober 2005 um 16:30 #
und wsa is an mounten schlimm?
Mounten bedeutet es sieht aus wie lokale Dateien und Verzeichnisse. D.h. eine Applikation würde davon ausgehen, daß sie zum Beispiel eine Datei synchron laden kann, weil es lokal eh schnell geht. Was in diesem Fall dann ein ziemlicher Irrtum wäre.
das kann doch der app wurscht sein bzw. soll auch wurscht sein. wofür ist denn sonst eine abstaktion gut? damit man sich mit den unteren schichten nicht abgeben und ständig das rad neuerfinden muss. braucht nur der zuständige treiber g'scheit cachen.
> Bei Kio ist mounten nicht notwendig, darum ist es nicht wirklich vergleichbar.
Gerade aufgestanden und noch nicht ganz wach? Natürlich ist bei Kio mounten nicht notwendig, aber wenn man es trotzdem tut (und dank fuse + kio-fuse auch kann), dann können alle Programme darauf zugreifen. Du kannst dann also z.B. mit vi direkt die Dateien über eine ssh-Verbindung editieren oder mit openoffice auf die Dateien einer windows-Freigabe zugreifen.
> Wünschenswerter wäre dass Kio die Kde nähe aufgibt und eine API für andere > Programme gibt (darauf kann dann ja eine kde oder gnome spezifische API > aufsetzen).
Kio ist nicht so extrem KDE-nah und kann schon lange auch von nicht-KDE-Programmen eingebunden werden. Die Gnome-Programmierer haben aber trotzdem was inkompatibles entwickelt.
> Wenn die dafür geschriebene Slaves dann auch noch mit Fuse mountbar wären, > das wäre überhaupt top.
Willkommen im Jahr 2005: http://wiki.kde.org/tiki-index.php?page=KIO+Fuse+Gateway kio-fuse gibt's übrigens schon seit mehr als 5 Jahren, bisher misste man aber immer selbst fuse in den Kernel patchen, absofort entfällt diese Hürde.
> Ich arbeite an einem anderen noch wichtigeren Projekt;) welches die > Konfiguration vereinheitlicht. (http://www.libelektra.org und > http://wiki.libelektra.org)
Nun ja, viel erfolg, aber mir reicht kfcg und ein übersichtlich gegliedertes /etc/ völlig aus.
Wünschenswerter wäre dass Kio die Kde nähe aufgibt und eine API für andere Programme gibt (darauf kann dann ja eine kde oder gnome spezifische API aufsetzen). Wenn die dafür geschriebene Slaves dann auch noch mit Fuse mountbar wären, das wäre überhaupt top.
Der Anfang ist schon gemacht, mal sehen, was daraus wird: http://freedesktop.org/Software/dvfs
> Neu im Kernel 2.6.14 ist ebenfalls ein generisches IEEE80211-Subsystem, > auf das auch die aktuellen Wireless-Treiber für Prism-Chipsätze und die > WLAN-Module von Centrino-Notebooks (ipw2100 und ipw2200) aufsetzen.
Nur ist der uralt und absolut broken und damit absolut unbenutzbar.
Blöde Besserwisserei, ich weiß. Aber ich möchte gerne wissen, was genau davon "broken" ist, denn es ist für mich wegen der Chipsätze durchaus interessant und wichtig. Könntest Du netterweise Dein Posting so modifizieren, dass klar wird, was genau "uralt, broken und unbenutzbar" ist? Meinst Du die Treiber oder die Prism-Chipsätze?
Wo stand in dem von mir zittiertem Teil etwas von Prism? Es geht im den ipw2[1,2]00 Treiber und das generische IEEE80211-Subsystem.
Nehme wir mal den ipw2100. Der ist in der Version 1.1.0 enthalten. Die ist uralt und funktioniert nicht mit halbwegs aktullem wpasupplicant. Damit ist es Essig mit WPA. Für den orginalen Treiber gibt es auf der sourceforge Seite einen patch. Wenn du jetzt denkst, super, probiere ich das mal, dann hast du dich zu früh gefreut. Es funktioniert nähmlich trotzdem nicht. Und ein altes wpasupplicant zu nehmen hilft dir auch nicht, denn...
Das Problem liegt wo anders. Der orginale Treiber kommt mit einem eigenen IEEE80211-Subsystem. Der im Kernel nicht. Der wurde modifiziert um mit dem generischen IEEE80211-Subsystem zu arbeiten. Und dabei haben sie den WPA Support zerbröselt.
Und ja, ich habe das versucht auf deren Maillingliste anzusprechen, nur das interessiert dort keinen.
der ipw2200 ist leider auch nur 1.0.0 und kann die zu neue Firmware bei mir nicht laden. Einen Downgrade werde ich angesichts der vielen gefixten Bugs seit 1.0.0 nicht mal versuchen.
Schade eigentlich, das bedeutet wohl, daß wir bis 2.6.15 warten müssen. Aber jetzt wo es unter 2 Monaten geht, dauert das ja nicht mehr so lange...
Zu dem ipw2[1-2]00 Treiber muss ich mich dem Gemecker anschließen!
Allerdings lassen sich sowohl das IEEE80211 Subsystem als auf die IPW Sourcen ohne Probleme in den 2.6.14er Kernel integrieren dann geht auch WPA wieder.
Das ist nun mal die stabile version, welche Version hätte denn sonst aufgenommen werden sollen? Die Version 1.0.6 von ipw2200 verliert alle paar Minuten die Verbindung zum Access Point, die Version 1.0.8 bringt das ganze System zum Absturz. Danke, muss nicht sein...
Ich habe einen S-ATA-Controller mit Silicon Image 3112A Chipsatz. Er wird auch erkannt, nur leider funktioniert er nicht, wenn ich eine Platte dranhänge: Dann gibt's einen IRQ-Fehler ("irq 3: nobody cared"), und das war's dann mit dem Booten. Ich hab schon endlos lange versucht, mit ACPI, ohne ACPI, mit APIC, ohne APIC, usw. Hat jemand noch eine Idee? Nachdem es mit 2.6.13 nicht ging und 2.6.14 ja offenbar keine Verbesserungen am sii_sata-Treiber bringt, schau ich derzeit etwas ratlos aus der Wäsche. Einen anderen S-ATA-Controller würde ich aber nur ungerne kaufen.
hab hier SuSE 9.3 und SuSE 10 (Kernel 2.6.13) laufen mit zwei SIL3112a und es gibt damit überhaupt keine Probleme. Ich denke das dein Problem woanders liegt.
Ich würde trotzdem auf den Controller tippen, denn ich habe ihn in zwei verschiedenen Rechnern ausprobiert, bei beiden das selbe Probleme. Der eine Rechner ist ein P3 850 mit Intel 440BX/ZX/DX Chipsatz, der andere ein Athlon XP 2200+ mit einem VIA KT400 Chipsatz.
kannst Du nicht die Firmware für den Sil 3112 updaten? Bei Onbord S-ATA Controllern ist diese meist im BIOS enthalten. Wenn es sich also um einen Onboard Sil 3112 Controller handeln sollte, dann das BIOS updaten.
Habe selbst so ein Dingens, auf dem Mainboard. Nach Firmware Updates tut erŽs.
was liegt den noch auf dem IRQ3 bei Dir? Und falls es sich um eine PCI Steckkarte mit Sil 3112 handelt, *noch mal gegen die Kristallkugel klopf* schon mal ausprobiert, diese Steckkarte in einen anderen PCI Slot zu stecken? Ach ja, da fällt mir noch ein, das man an so einen Sil 3112 doch zwei S-ATA Festplatten anschließen kann, an welchem S-ATA der beiden Anschlüsse steckt die Festplatte den? Schon mal getauscht? Ist die Festplatte eine mit "NCQ" (Native Command Queuing)?
Auf IRQ 3 ist sonst nichts. Es handelt sich in der Tat um eine PCI-Karte, auch tauschen der Position bringt nichts (außer dass sich der IRQ ändert. Im konkreten Fall war es dann IRQ 10, auf dem sonst auch nichts lag). Hab die Festplatte auch an beiden Anschlüssen des Controllers ausprobiert. Die Festplatte ist eine Western Digital Caviar WD2000JD, ob sie NCQ unterstützt konnte ich jetzt auf die Schnelle nicht herausfinden.
Es gibt im Kernel zwei Silicon Image Treiber. Einmal den unter der SCSI-Emulation (Symbol: SCSI_SATA_SIL) und den unter ATA ((Symbol: BLK_DEV_SIIMAGE). Wobei man tunlichst den SCSI-Treiber verwenden sollte, denn der ATA-Treiber ist ein einziger Zustand. Wenn beide als Modul kompiliert wurden ist darauf zu achten das sie beide nicht geladen sind (wenn es überhaupt geht, nicht probiert). Ich habe bei mir den SCSI-Treiber fest einkompiliert denn als Modul hat er sich recht seltsam verhalten, d.h. Festplatte nicht erkannt usw... Wenn das auch nichts bringt kannst es ja mal alternativ mit dem ATA-Treiber probieren. Ansonsten funktioniert bei mir der S-ATA-Controller wunderbar. Ich betreibe ihn mit dem Linux-Soft-Raid.
Gleichzeitig geladen sind beide nicht, der ATA-Treiber ging im Rechner mit dem Intel-Chipsatz (da steckt mittlerweile ein Promise-Controller drin), im anderen Rechner bleibt er leider beim Booten hängen (er sucht nach hde, genaue Fehlermeldung hab ich leider grade nicht da).
Neben den Aenderungen in den Schlagzeilen, enthaelt der Kernel jetzt auch 9P [1] support umd 9P fileserver ins VFS mounten zu koennen. Dadurch wird es moeglich, endlich das crappy NFS und FUSE wegzuschmeissen und stattdessen ein vernuenftiges Protokoll aus der Geburtsstaette von Unix zu verwenden...
ich wollt auch grade einen fuse vfs v9fs thread aufmachen also ich kenn mich von beiden nicht aus (geht fuse ueber netzwerk? tut es v9fs?) aber irgendwie erscheint mir beides doppelt gemoppelt,oder?
Von Johannes Rohr am Fr, 28. Oktober 2005 um 20:11 #
Auch Suspend-to-Disk kommt mit einer neuen Version. Auf Wunsch werden Daten beim Suspendieren verschlüsselt gespeichert.
Wo steht das im ChangeLog? In jedem Fall wäre es merkwürdig, wenn immer noch an der alten Implementierung im Kernel herumgewerkelt würde, wo doch Suspend2 sie längst überholt hat. Ich hoffe sehr, dass es baldmöglichst in den offiziellen Eingang findet, denn suspend2 ist die einzige suspend-to-disk-Implementierung, mit der ich jemals Erfolg gehabt habe. (und das auch erst seit kurzer Zeit, seit der "FileWriter" eingeführt wurde), das alte, derzeit im Kernel befindliche ist schlich und einfach obsolet.
Feste ABI Schnittstellen für Kernelmodule, so dass man z.B. einen neuen Serial-ATA-, Webcam-, Acpi-, wlan-,...-Treiber nachrüsten kann, ohne einen neuen Kernel installieren zu müssen.
Nein, sondern weil unterschiedliche Compiler mit unterschiedlichen Optimierungsflags aus demselben Kernelsource unterschiedliche ABIs generieren. Es ist also für die Kernel-Jungs gar nicht möglich, das ABI stabil zu halten. Es sei denn, der gcc wird verboten und wir haben nen fest vorgeschriebenen Compiler, der nicht geändert werden darf, wie die Windows-Jungs mit dem MSVC++-Compiler. Das wird aber nie passieren.
Von Papa Schlumpf am Sa, 29. Oktober 2005 um 10:53 #
Wieso?
Erstens wird für Kernel Module sowieso ausschließlich der gcc verwendet, und zweitens sind diese ausschließlich in C programmiert. Wie kann man damit inkompatible ABIs programmieren, wenn man nicht gerade solche Optionen verwendet, die in der gcc-docu gross und deutlich als inkompatibel markiert sind?
Von binärkompatibilität am Sa, 29. Oktober 2005 um 11:19 #
es ist einfach zu unflexibel wenn man eine api hat die sich nicht weiterentwickeln kann und immer kompatibilität zu den alten sachen haben muss. unter linux gibt es generell keine binärkompatibilität und das ist auch gut so. nur so kann man eine schnelle entwicklung gewährleisten. alles andere verlangsamt nur den entwicklungsprozess. ausserdem ist es ein grund mehr die programme bzw treiber unter eine open source lizenz zu stellen.
Gerade solche Optionen werden leider von SUSE und Fedora genutzt, nämlich z.B -mregparm=3, obwohl in der gcc-Doku explizit steht, dass bei Verwendung von -mregparm sich das ABI ändert. Weiterhin wird im Kernel an manchen Stellen von einer gewissen Anordnung der Funktionen ausgegangen. Und unterschiedliche gccs optimieren anders und ordnen so die Funktionen teilweise anders an, was bei hartkodiertem Zeugs, wie man es teilweise im Kernel findet, zu mächtigen Problemen führt. Es sind halt viele dreckige gcc-spezifische Hacks drin, was auch daran liegt, dass der gcc auf manchen Plattformen ohne diese Probleme macht, so z.B. der gcc < 4 auf ppc64.
BTW. Schon mal versucht, nen Kernel mit -O3 zu übersetzen?
Du scheinst nicht zu wissen, wovon du redest. Die ABI inkompatibilitäten des GCC beschränkten sich auf c++, aber auch wenn man kernelmodule für gcc 3.1+, gcc 3.3+ und gcc4.x anbieten müsste, wäre das immer noch 1000x besser, als die derzeitige Version, wo man für ein Kernelmodul schon pro Version einer Distribution mehrere varianten anbieten müsste (z.B. fc4 standard-kernel, fc4 updatekernel1, fc4 updatekernel2). Bei der derzeitigen Anzahl an Distributionen und deren Versionen kommt man da schnell in die hunderte.
soweit ich das getested habe (1-2 mal) liegt das nicht daran das sich der kernel ändert sondern daran das die module für jeden kernel an unterschiedlicher stelle im /lib verzeichniss gelagert werden viele module kann man einfach von einem baum in den anderen verschieben und sie funktionieren (nicht von 2.4 nach 2.6 aber sonst schon oft) ( getest hatte ich das glaub ich mit dem fglrx und dem ipw2200). dafür kann jedoch keiner garantieren. (und von gcc 3.1 zu gcc 4 ist sicher auch problematisch)
Wenn hier einer nicht weiß, wovon er redet, dann du. Denn g++ 3.3 erzeugt das gleiche C++-ABI wie der g++ 3.2, nicht wie der g++ 3.4.
Außerdem ändert sich das ABI auch beim Kernel, wenn man ihn mit unterschiedlichen Compilern bzw. Compilerflags kompiliert. Man denke nur an -mregparm. Große Distributionen wie SUSE oder Fedora sind es, die sowas bei ihren Standardkerneln benutzen, weshalb 4Front trotz Wrapper das Binärmodul für OSS/Linux in verschiedenen Variationen anbieten muss, da sonst deren Software wohl auf der Hälfte der Rechner nicht laufen würde.
Außerdem muss man nicht für jeden Updatekernel das Modul aktualisieren, wenn man nicht gerade Fedora einsetzt, wo bei jedem Kernelupdate rumexperimentiert wird (Arjan van de Ven hat gerne mal binärinkompatible Patches eingebunden, dank der es nicht mehr möglich war, die NVIDIA-Treiber zu nutzen, bevor man nicht den Kernel ohne die Patches neu kompiliert hat). Bei SUSE laufen die alten Module weiterhin. Auch wenn man nen Vanilla-Kernel einsetzt, ändern zumindest die Patch-Versionen nichts am ABI.
Weiterhin ist klar, dass sich das Kernel-ABI bei Nutzen vom Preemption im Kernel ändern muss. Es geht gar nicht anders.
Wenn man ein stabiles Kernel-ABI will, muss man sowas verbieten. Bei FreeBSD gibt es solche Spielereien wie Preemption oder einen Wechsel der Stackgröße (4KSTACKS), die nachträglich eingepflanzt werden, nicht.
Das Beste wäre eine Microkernelarchitektur, da man so gescheite Abstraktion erreicht. Nur müsste man dafür den Kernel neu schreiben und da kann man genauso gut GNU/Hurd nehmen.
Die Vorteile von Windows in Sachen Treiber sind ein Compiler, der solche Spielereien wie -mregparm=3 gar nicht zulässt und ein stabiles ABI erzeugt, sowie die Microkernelarchitektur, auch wenn bei Windows einiges im Kernelspace läuft, was nicht dort laufen müsste.
ganz easy: linux ist einem schnellen entwicklungsprozess unterlegen,die eigentlichen schnittstellen aendern sich also oft. prinzipiell ist es moeglich eine feste ABI ueber den eigentlichen schnittstellen zu haben, die halt immer entsprechend mappt. Nur die Kernelentwickler sind open source leute und haben da kein interesse oder keinte lust drauf oder irgendwie so, aber wenn es ein 3. schreibt haetten sie auch nix dagegen. nur es findet sich ja auch keine gruppe zusammen die sowas macht....aber die kernel entwickler seh ich da direkt eigentlich auch nicht in der pflicht. fuer die ganzen grossen firmen ist es doch ein leichtes ein kleines team zu bezahlen die die entsprechende ABI programmiert.
deine Aussage ist so falsch, daß es schon weh tut.
Es geht nicht um closed source Treiber.
Das Problem ist, eine ABI stabil zu halten.
Man müßte eine Abstraktionsschicht einführen, die im Lauf der Zeit immer mer Änderungen abfangen müßte und damit immer größer, fetter, träger und fehlerhafter würde.
Von Pinguinschlachter am Sa, 29. Oktober 2005 um 13:23 #
Dann würde es endlich mal ATI und NVidia-Treiber erstellt werden, die nicht nur bis zum nächsten Kernelupdate funktionieren. Das wollen die Linuxevangelisten natürlich nicht.
Du hast noch nie Code geschrieben, der ein 5 Jahre altes ABI implementieren muss, aber die neusten Features besitzen soll, an die bei der ABI-Spezifikation noch keiner gedacht hat?
Das hängt nur davon ab, wie durchdacht das ABI ist.
Oder denkst du wirklich, die MS Programmierer hatten beim Win9x Treibermodell daran gedacht, dass irgendwann mal DVB-T Karten erfunden werden, dass es diverse (Fake-)Hardware-Raid-Karten geben wird, oder Wlan-Karten?
Eine sinnvoll abstrahierte Treiberschnittstelle kann es über Jahre hinaus überflüssig machen, den Betriebsystemkernel updaten zu müssen.
Bei DVB-* baut jeder Hersteller sein eigenes Süppchen. Erst jetzt interessiert sich MS dafür, mal einen Standard einzuführen. Unter Linux gibt es hier schon seit langem eine Schnittstelle.
In Sachen WLAN liegt das an der NDIS-Abstraktionsschicht. Sowas klappt aber nur, wenn die Architektur selbst ordentlich durchdacht ist und viele Abstraktionsschichten beherbergt.
Andrew Tanenbaum hat schon vor Ewigkeiten behauptet: Linux is obsolete. Und er bezog sich auch darauf, dass Linux kein Microkernel ist. Und genau das wird Linux hier zum Verhängnis. Denn für eine wirklich saubere Architektur kommt man eigentlich nicht an nem Microkernel vorbei.
Wenn allerdings tatsächlich Interesse an einer sauberen Architektur besteht, warum entwickelt sich GNU/Hurd dann so langsam?
Es muss jetzt nicht unbedingt neue Hardware sein, die unter die alten Schnittstellen passen muss. Lass die Entwickler nur mal eine effizientere in-kernel-Speicherverwaltung entwickeln und einbauen, die gegenüber der alten dramatische Vorteile hat, allerdings völlig andere interne Schnittstellen mit sich bringt.
Entweder du änderst jetzt deinen Treiber oder jemand schreibt eine Umsetzungsschicht, die versucht, die Semantik der alten Schnittstelle möglichst gut auf die neue Schnittstelle umzusetzen. Funktioniert manchmal, vielleicht auch oft (wenn es nicht gerade um Kernel-, sondern eher Libc-Änderungen handelt), aber manchmal geht es nicht anderes. Entweder man bricht dann mit der Kompatibilität (und verschiebt dann die Problematik mit verschiedenen Versionen einer Schnittstelle in darauf aufbauenden Programme/Codeteile) oder lässt die geplante Änderung an der Schnittstelle bleiben und bringt keine Verbesserung an.
Sowas ist doch mit den Userland-Treibern angedacht, soweit ich das mitbekommen habe. Das ganze soll dann wohl so ähnlich funktionieren wie bei FUSE, habe ich mal gelesen. Aber nichts genaues weiß ich nicht.
Da eigentlich sowieso alle davon eine read/write/open/close API haben, müsste das doch möglich sein...
*träum*
Ich arbeite an einem anderen noch wichtigeren Projekt;) welches die Konfiguration vereinheitlicht. (http://www.libelektra.org und http://wiki.libelektra.org)
mfg Markus
und wsa is an mounten schlimm? so sehen es wenigstens alle apps! man kann ja mount so einrichten das user ihre user-space prozesse in ihren verzeichnissen mounten duerfen.
> orbit.
Dann braucht es ja eine ganze Menge. Auch kio braucht kaum das gesamte KDE/Qt System. Die ganzen Oberflächenelemente werden ja z.B. nicht benötigt.
Ich fände es aber auf jeden Fall auch gut, wenn gnom-vfs und kio zu einer Schicht verschmelzen würden, evtl. auch im Zusammenhang mit Fuse. Dann könnten alle Desktopumgebungen / Programme nutzen daraus ziehen.
aber als es die gnome-vfs definiert wurden, wurde hier einfach das Rad neu erfunden ohne tief erst einmal die KIO zu untersuchen. "Not invented here syndrom".
Da so vorgegangen wurde, ist natürlich das vereinheitlichen nun wieder ein Problem...
Die Strukturen sind leider sehr unterschiedlich.
Das Anfordern einen Slaves wird in KDE über DCOP gemacht.
Ist also alles nur ein Protokoll, also auch beliebig reimplementiertbar.
Soll das in KDE 4.0 nicht anders werden? Iirc soll da was Desktop übergreifendes zum Einsatz kommen und DCOP damit obsolet werden. Also können hier alle aufatmen und ein Flamewar ist nicht mehr nötig :-)
Ciao,
Christian
Mounten bedeutet es sieht aus wie lokale Dateien und Verzeichnisse.
D.h. eine Applikation würde davon ausgehen, daß sie zum Beispiel eine Datei synchron laden kann, weil es lokal eh schnell geht.
Was in diesem Fall dann ein ziemlicher Irrtum wäre.
braucht nur der zuständige treiber g'scheit cachen.
Um die GUI nicht zu blockieren arbeitet man eben mit einer asynchronen Abstraktion, zum Beispiel KIO oder GNOME-VFS
Aber natürlich steht es dir frei blockierende GUIs vorzuziehen, wenn dir mounten lieber ist.
Gerade aufgestanden und noch nicht ganz wach?
Natürlich ist bei Kio mounten nicht notwendig, aber wenn man es trotzdem tut (und dank fuse + kio-fuse auch kann), dann können alle Programme darauf zugreifen. Du kannst dann also z.B. mit vi direkt die Dateien über eine ssh-Verbindung editieren oder mit openoffice auf die Dateien einer windows-Freigabe zugreifen.
> Wünschenswerter wäre dass Kio die Kde nähe aufgibt und eine API für andere
> Programme gibt (darauf kann dann ja eine kde oder gnome spezifische API
> aufsetzen).
Kio ist nicht so extrem KDE-nah und kann schon lange auch von nicht-KDE-Programmen eingebunden werden. Die Gnome-Programmierer haben aber trotzdem was inkompatibles entwickelt.
> Wenn die dafür geschriebene Slaves dann auch noch mit Fuse mountbar wären,
> das wäre überhaupt top.
Willkommen im Jahr 2005:
http://wiki.kde.org/tiki-index.php?page=KIO+Fuse+Gateway
kio-fuse gibt's übrigens schon seit mehr als 5 Jahren, bisher misste man aber immer selbst fuse in den Kernel patchen, absofort entfällt diese Hürde.
> Ich arbeite an einem anderen noch wichtigeren Projekt;) welches die
> Konfiguration vereinheitlicht. (http://www.libelektra.org und
> http://wiki.libelektra.org)
Nun ja, viel erfolg, aber mir reicht kfcg und ein übersichtlich gegliedertes /etc/ völlig aus.
Der Anfang ist schon gemacht, mal sehen, was daraus wird: http://freedesktop.org/Software/dvfs
Also Symlinks in Directories... :-)
Wann endlich werden nicht dauernd die Räder mit noch ner Ecke mehr neu erfunden?
> auf das auch die aktuellen Wireless-Treiber für Prism-Chipsätze und die
> WLAN-Module von Centrino-Notebooks (ipw2100 und ipw2200) aufsetzen.
Nur ist der uralt und absolut broken und damit absolut unbenutzbar.
ttyler, t.k.
Subsystem (Neutrum) -> "das"
Wireless-Treiber (Maskulinum, Plural) -> "die"
Prism-Chipsätze ( " " ) -> "
WLAN-Module -> dito
Centrino-Notebooks -> dito
Blöde Besserwisserei, ich weiß. Aber ich möchte gerne wissen, was genau davon "broken" ist, denn es ist für mich wegen der Chipsätze durchaus interessant und wichtig.
Könntest Du netterweise Dein Posting so modifizieren, dass klar wird, was genau "uralt, broken und unbenutzbar" ist? Meinst Du die Treiber oder die Prism-Chipsätze?
Danke und viele Grüße!
Nehme wir mal den ipw2100. Der ist in der Version 1.1.0 enthalten. Die ist uralt und funktioniert nicht mit halbwegs aktullem wpasupplicant. Damit ist es Essig mit WPA. Für den orginalen Treiber gibt es auf der sourceforge Seite einen patch. Wenn du jetzt denkst, super, probiere ich das mal, dann hast du dich zu früh gefreut. Es funktioniert nähmlich trotzdem nicht. Und ein altes wpasupplicant zu nehmen hilft dir auch nicht, denn...
Das Problem liegt wo anders. Der orginale Treiber kommt mit einem eigenen IEEE80211-Subsystem. Der im Kernel nicht. Der wurde modifiziert um mit dem generischen IEEE80211-Subsystem zu arbeiten. Und dabei haben sie den WPA Support zerbröselt.
Und ja, ich habe das versucht auf deren Maillingliste anzusprechen, nur das interessiert dort keinen.
der ipw2200 ist leider auch nur 1.0.0 und kann die zu neue Firmware bei mir nicht laden. Einen Downgrade werde ich angesichts der vielen gefixten Bugs seit 1.0.0 nicht mal versuchen.
Schade eigentlich, das bedeutet wohl, daß wir bis 2.6.15 warten müssen. Aber jetzt wo es unter 2 Monaten geht, dauert das ja nicht mehr so lange...
Gruß, Kay
Allerdings lassen sich sowohl das IEEE80211 Subsystem als auf die IPW Sourcen ohne Probleme in den 2.6.14er Kernel integrieren dann geht auch WPA wieder.
Oct 29 08:07:51 gryffindor kernel: [17241795.016000] eth1: NETDEV_TX_BUSY returned; driver should report queue full via ieee_device->is_queue_full
zu. Und davon gibt es dann pro Tag 4000-5000 Einträge.
hab hier SuSE 9.3 und SuSE 10 (Kernel 2.6.13) laufen mit zwei SIL3112a und es gibt damit überhaupt keine Probleme.
Ich denke das dein Problem woanders liegt.
Viel Erfolg,
Bernd
kannst Du nicht die Firmware für den Sil 3112 updaten?
Bei Onbord S-ATA Controllern ist diese meist im BIOS enthalten.
Wenn es sich also um einen Onboard Sil 3112 Controller handeln sollte,
dann das BIOS updaten.
Habe selbst so ein Dingens, auf dem Mainboard.
Nach Firmware Updates tut erŽs.
Gruß, Fusselbär
was liegt den noch auf dem IRQ3 bei Dir?
Und falls es sich um eine PCI Steckkarte mit Sil 3112 handelt, *noch mal gegen die Kristallkugel klopf*
schon mal ausprobiert, diese Steckkarte in einen anderen PCI Slot zu stecken?
Ach ja, da fällt mir noch ein, das man an so einen Sil 3112 doch zwei S-ATA Festplatten anschließen kann,
an welchem S-ATA der beiden Anschlüsse steckt die Festplatte den? Schon mal getauscht?
Ist die Festplatte eine mit "NCQ" (Native Command Queuing)?
Gruß, Fusselbär
Hab die Festplatte auch an beiden Anschlüssen des Controllers ausprobiert. Die Festplatte ist eine Western Digital Caviar WD2000JD, ob sie NCQ unterstützt konnte ich jetzt auf die Schnelle nicht herausfinden.
Wenn selbst ein Debian Stable das ja immer als antik bezeichnet wird die Platten out of the Box erkennt muss der Fehler wo anders liegen.
Vielleicht wurde der Treiber aber auch schlicht, kaput optimiert.
Ansonsten funktioniert bei mir der S-ATA-Controller wunderbar. Ich betreibe ihn mit dem Linux-Soft-Raid.
[1] http://v9fs.sf.net
(hab mit kio-fuse gerade nur mit Userrechten den 1GByte gmx-Speicherplatz über webfav gemountet...)
Wo steht das im ChangeLog? In jedem Fall wäre es merkwürdig, wenn immer noch an der alten Implementierung im Kernel herumgewerkelt würde, wo doch Suspend2 sie längst überholt hat. Ich hoffe sehr, dass es baldmöglichst in den offiziellen Eingang findet, denn suspend2 ist die einzige suspend-to-disk-Implementierung, mit der ich jemals Erfolg gehabt habe. (und das auch erst seit kurzer Zeit, seit der "FileWriter" eingeführt wurde), das alte, derzeit im Kernel befindliche ist schlich und einfach obsolet.
Ich meine, was fehlt denn eigentlich noch?
Ich habe den Eindruck, dass der Kernel mittlerweile featureseitig ziemlich reif ist.
Das einzige was mir auf die Schnelle einfällt wäre eine 3-Tier Infrastruktur für den Desktopgebrauch. Aber auch das geht wohl im Userspace.
Grüße
Sascha
Es sei denn, der gcc wird verboten und wir haben nen fest vorgeschriebenen Compiler, der nicht geändert werden darf, wie die Windows-Jungs mit dem MSVC++-Compiler. Das wird aber nie passieren.
Erstens wird für Kernel Module sowieso ausschließlich der gcc verwendet, und zweitens sind diese ausschließlich in C programmiert. Wie kann man damit inkompatible ABIs programmieren, wenn man nicht gerade solche Optionen verwendet, die in der gcc-docu gross und deutlich als inkompatibel markiert sind?
Weiterhin wird im Kernel an manchen Stellen von einer gewissen Anordnung der Funktionen ausgegangen. Und unterschiedliche gccs optimieren anders und ordnen so die Funktionen teilweise anders an, was bei hartkodiertem Zeugs, wie man es teilweise im Kernel findet, zu mächtigen Problemen führt. Es sind halt viele dreckige gcc-spezifische Hacks drin, was auch daran liegt, dass der gcc auf manchen Plattformen ohne diese Probleme macht, so z.B. der gcc < 4 auf ppc64.
BTW. Schon mal versucht, nen Kernel mit -O3 zu übersetzen?
Denn g++ 3.3 erzeugt das gleiche C++-ABI wie der g++ 3.2, nicht wie der g++ 3.4.
Außerdem ändert sich das ABI auch beim Kernel, wenn man ihn mit unterschiedlichen Compilern bzw. Compilerflags kompiliert. Man denke nur an -mregparm. Große Distributionen wie SUSE oder Fedora sind es, die sowas bei ihren Standardkerneln benutzen, weshalb 4Front trotz Wrapper das Binärmodul für OSS/Linux in verschiedenen Variationen anbieten muss, da sonst deren Software wohl auf der Hälfte der Rechner nicht laufen würde.
Außerdem muss man nicht für jeden Updatekernel das Modul aktualisieren, wenn man nicht gerade Fedora einsetzt, wo bei jedem Kernelupdate rumexperimentiert wird (Arjan van de Ven hat gerne mal binärinkompatible Patches eingebunden, dank der es nicht mehr möglich war, die NVIDIA-Treiber zu nutzen, bevor man nicht den Kernel ohne die Patches neu kompiliert hat). Bei SUSE laufen die alten Module weiterhin.
Auch wenn man nen Vanilla-Kernel einsetzt, ändern zumindest die Patch-Versionen nichts am ABI.
Weiterhin ist klar, dass sich das Kernel-ABI bei Nutzen vom Preemption im Kernel ändern muss. Es geht gar nicht anders.
Wenn man ein stabiles Kernel-ABI will, muss man sowas verbieten. Bei FreeBSD gibt es solche Spielereien wie Preemption oder einen Wechsel der Stackgröße (4KSTACKS), die nachträglich eingepflanzt werden, nicht.
Das Beste wäre eine Microkernelarchitektur, da man so gescheite Abstraktion erreicht. Nur müsste man dafür den Kernel neu schreiben und da kann man genauso gut GNU/Hurd nehmen.
Die Vorteile von Windows in Sachen Treiber sind ein Compiler, der solche Spielereien wie -mregparm=3 gar nicht zulässt und ein stabiles ABI erzeugt, sowie die Microkernelarchitektur, auch wenn bei Windows einiges im Kernelspace läuft, was nicht dort laufen müsste.
Es geht nicht um closed source Treiber.
Das Problem ist, eine ABI stabil zu halten.
Man müßte eine Abstraktionsschicht einführen, die im Lauf der Zeit immer mer Änderungen abfangen müßte und damit immer größer, fetter, träger und fehlerhafter würde.
Und das will niemand, denn das kostet richtig.
Such mal die Archive von lkml durch.
Oder denkst du wirklich, die MS Programmierer hatten beim Win9x Treibermodell daran gedacht, dass irgendwann mal DVB-T Karten erfunden werden, dass es diverse (Fake-)Hardware-Raid-Karten geben wird, oder Wlan-Karten?
Eine sinnvoll abstrahierte Treiberschnittstelle kann es über Jahre hinaus überflüssig machen, den Betriebsystemkernel updaten zu müssen.
In Sachen WLAN liegt das an der NDIS-Abstraktionsschicht. Sowas klappt aber nur, wenn die Architektur selbst ordentlich durchdacht ist und viele Abstraktionsschichten beherbergt.
Andrew Tanenbaum hat schon vor Ewigkeiten behauptet: Linux is obsolete. Und er bezog sich auch darauf, dass Linux kein Microkernel ist. Und genau das wird Linux hier zum Verhängnis. Denn für eine wirklich saubere Architektur kommt man eigentlich nicht an nem Microkernel vorbei.
Wenn allerdings tatsächlich Interesse an einer sauberen Architektur besteht, warum entwickelt sich GNU/Hurd dann so langsam?
Es muss jetzt nicht unbedingt neue Hardware sein, die unter die alten Schnittstellen passen muss. Lass die Entwickler nur mal eine effizientere in-kernel-Speicherverwaltung entwickeln und einbauen, die gegenüber der alten dramatische Vorteile hat, allerdings völlig andere interne Schnittstellen mit sich bringt.
Entweder du änderst jetzt deinen Treiber oder jemand schreibt eine Umsetzungsschicht, die versucht, die Semantik der alten Schnittstelle möglichst gut auf die neue Schnittstelle umzusetzen. Funktioniert manchmal, vielleicht auch oft (wenn es nicht gerade um Kernel-, sondern eher Libc-Änderungen handelt), aber manchmal geht es nicht anderes. Entweder man bricht dann mit der Kompatibilität (und verschiebt dann die Problematik mit verschiedenen Versionen einer Schnittstelle in darauf aufbauenden Programme/Codeteile) oder lässt die geplante Änderung an der Schnittstelle bleiben und bringt keine Verbesserung an.
Aber nichts genaues weiß ich nicht.
Findet ihr nicht auch, dass Linus ein wenig zugenommen hat?
Aber mit fast 36 Jahren und Vater von 3 Töchtern setzt mann vieleicht etwas an :-)
Mann, der is ja jünger als ich --- Krise---
http://www.linux.de/linux/linus_torvalds.php3
von der Ausstrahlung ist er mir auch lieber als die Hack-Fresse von Billy-Boy
A.
;-)
Seit meinem Update auf 2.6.12.4 hab ich keinen Sound mehr bei nicht KDE Programmen.
Spiele usw
Bitte Helft mir.
Thx
Manuel