/proc/acpi/event deprecated?
Alexander Griesser
2.6.24 enthält ein paar Konfigurationsoptionen für deprecated /proc/acpi
files. Prinzipiell ja recht nett, viele der Sachen wurden nach /sys aus-
gelagert und sind dort auch recht praktisch verwendbar.
Wenn ich allerdings alle deprecated /proc/acpi/ files entfernen lasse,
dann funktioniert mein acpid (1.0.6) nicht mehr und so wirklich wundert
es mich auch nicht, weil es steht ja bei der Kernelkonfiguration dabei
dass der Userspace Daemon sehr aktuell sein muss, damit das
funktioniert, aber vom acpid gibts mWn keine neuere Version und der
aktuelle braucht unbedingt /proc/acpi/event um die ACPI events
mitzukriegen.
Ideen?
Ah und weiß jemand, _WODURCH_ /proc/acpi/event ersetzt wurde? Es steht
zwar was von netlink sockets etc., kann mir aber nicht so wirklich
vorstellen, wie das dann am Filesystem ausschaut.
ciao,
Alex
Andreas Leitgeb
> Griass eich!
> 2.6.24 enthält ein paar Konfigurationsoptionen für deprecated /proc/acpi
> files.
> Wenn ich allerdings alle deprecated /proc/acpi/ files entfernen lasse,
> dann funktioniert mein acpid (1.0.6) nicht mehr ...
Mal die ganz bloede Frage von mir: warum laesst du den proc-acpi support
nicht einfach noch drin, so wie es meistens empfohlen ist, fuer die Faelle
wo man noch nicht die allerneuesten Userland-tools hat? :-)
Ein grep nach den gesuchten /proc/acpi/-eintraegen in
${kerneldir}/Documentation findet nichts?
(sehe den 2.6.24er noch nicht, isses ein "-rc"?)
Alexander Griesser
> Alexander Griesser <tu...@tuxx-home.at> wrote:
>> Griass eich!
>> 2.6.24 enthält ein paar Konfigurationsoptionen für deprecated /proc/acpi
>> files.
>
>> Wenn ich allerdings alle deprecated /proc/acpi/ files entfernen lasse,
>> dann funktioniert mein acpid (1.0.6) nicht mehr ...
>
> Mal die ganz bloede Frage von mir: warum laesst du den proc-acpi support
> nicht einfach noch drin, so wie es meistens empfohlen ist, fuer die Faelle
> wo man noch nicht die allerneuesten Userland-tools hat? :-)
Hab ich eh noch drin, sind ja ein paar andere Sachen auch noch, die
diese Files noch brauchen (z.B. xbattbar-acpi).
Alle selbstgestrickten Sachen baue ich gerade um (früher oder später
muss mans eh machen) und beim acpid dachte ich, dass es da vielleicht
schon irgendwo ein Upate gibt (also nicht unbedingt eine svn Version).
> Ein grep nach den gesuchten /proc/acpi/-eintraegen in
> ${kerneldir}/Documentation findet nichts?
Findet genug, vorallem aber das, was ich eh schon gesagt habe:
------------------ [ Documentation/feature-removal-schedule.txt ] ------
What: /proc/acpi/event
When: February 2008
Why: /proc/acpi/event has been replaced by events via the input layer
and netlink since 2.6.23.
Who: Len Brown <len....@intel.com>
------------------------------------------------------------------------
Ist ja alles recht und schön, aber mir sagt das leider nicht weiß gott
wie viel.
> (sehe den 2.6.24er noch nicht, isses ein "-rc"?)
Ja, -rc4 momentan.
ciao,
Alex
Thomas Ogrisegg
[...]
> Ideen?
So konfigurieren, dass die Dateien erhalten bleiben?
> Ah und weiß jemand, _WODURCH_ /proc/acpi/event ersetzt wurde? Es steht
> zwar was von netlink sockets etc., kann mir aber nicht so wirklich
> vorstellen, wie das dann am Filesystem ausschaut.
Gar nicht. Netlink ist ein Notifikationsprotokoll, ohne Dateisystem.
Macht auch durchaus mehr Sinn, weil es a) auch funktioniert wenn /proc
nicht gemounted wurde und b) wesentlich
einfacher/transparenter/generischer zu handhaben ist - im Gegensatz zu
procfs.
Alexander Griesser
> Alexander Griesser <tu...@tuxx-home.at> wrote on 2007-12-05:
> [...]
>> Ideen?
>
> So konfigurieren, dass die Dateien erhalten bleiben?
Ja, eh, aber man will ja zukunftsorientiert arbeiten und da ich mich
grad sowieso mit derartigen Sachen beschäftige wollt ich das auch gleich
angehen, wenns leicht geht.
>> Ah und weiß jemand, _WODURCH_ /proc/acpi/event ersetzt wurde? Es steht
>> zwar was von netlink sockets etc., kann mir aber nicht so wirklich
>> vorstellen, wie das dann am Filesystem ausschaut.
>
> Gar nicht. Netlink ist ein Notifikationsprotokoll, ohne Dateisystem.
OK und für Dummies heißt das jetzt was?
Der Kernel/ein Userspaceprogramm generiert irgendein Event irgendwo
und irgendwer greift das irgendwie ab?
> Macht auch durchaus mehr Sinn, weil es a) auch funktioniert wenn /proc
> nicht gemounted wurde und b) wesentlich
> einfacher/transparenter/generischer zu handhaben ist - im Gegensatz zu
> procfs.
Zugegeben, procfs parsing ist nicht immer einfach, aber inzwischen habe
ich mich schon daran gewöhnt. Naja, ich lass mich dann mal überraschen
wie das mit den netlink sockets aussehen wird, hie und da gibts ja
doch neue sinnvolle Änderungen. Hab mich übrigens noch immer nicht an
udev und Konsorten gewöhnt, obwohl mein System inzwischen udev verwendet
aber dazu habe ich persönlich nichts beigetragen ;)
Meine Netzwerkkarte ist jetzt halt eth4 statt eth0, aber damit kann ich
leben ;)
ciao,
Alex
Markus Raab
> Meine Netzwerkkarte ist jetzt halt eth4 statt eth0, aber damit kann ich
> leben ;)
Es sollte eine Datei geben, bei Debian Etch:
/etc/udev/rules.d/z25_persistent-net.rules
in der du Mac adressen basiert aussuchen kannst welche Mac welches eth*
bekommt.
mfg Markus
Tomas Carnecky
> Ja, eh, aber man will ja zukunftsorientiert arbeiten und da ich mich
> grad sowieso mit derartigen Sachen beschäftige wollt ich das auch gleich
> angehen, wenns leicht geht.
Falls du programierer bist oder abenteuer suchst:
http://marc.info/?t=119689005000004&r=1&w=2
git repo: http://neopsis.com/git/?p=acpid;a=summary
$ git clone git://neopsis.com/acpid
Have fun
>>> Ah und weiß jemand, _WODURCH_ /proc/acpi/event ersetzt wurde? Es steht
>>> zwar was von netlink sockets etc., kann mir aber nicht so wirklich
>>> vorstellen, wie das dann am Filesystem ausschaut.
>> Gar nicht. Netlink ist ein Notifikationsprotokoll, ohne Dateisystem.
>
> OK und für Dummies heißt das jetzt was?
> Der Kernel/ein Userspaceprogramm generiert irgendein Event irgendwo
> und irgendwer greift das irgendwie ab?
kernel generiert acpi events, und diese werden dann durch netlink
sockets oder /dev/input/eventX devices (oder auch andere wege) an
userspace programe welche interessiert sind geschickt.
/proc/acpi/event kann nur von einem process gelesen werden (typisch der
acpid), die neuen events werden an alle programe geschickt die
interessiert sind (eine art broadcast).
>> Macht auch durchaus mehr Sinn, weil es a) auch funktioniert wenn /proc
>> nicht gemounted wurde und b) wesentlich
>> einfacher/transparenter/generischer zu handhaben ist - im Gegensatz zu
>> procfs.
Dafuer gibts jetzt viele verschiedene wege wie ein acpi event das
userspace erreichen kann. Und das ist gar nicht standartisiert also
macht jeder acpi treiber was er will. Das macht es nicht gerade einfach
fuer den acpi daemon.
tom
Alexander Griesser
Aja, danke, jetzt isses wieder eth0. Dürfte bei der Migration vom alten
aufs neue Notebook passiert sein.
ciao,
Alex
Thomas Ogrisegg
> Thomas Ogrisegg wrote:
>> Alexander Griesser <tu...@tuxx-home.at> wrote on 2007-12-05:
>> [...]
>>> zwar was von netlink sockets etc., kann mir aber nicht so wirklich
>>> vorstellen, wie das dann am Filesystem ausschaut.
>> Gar nicht. Netlink ist ein Notifikationsprotokoll, ohne Dateisystem.
> OK und für Dummies heißt das jetzt was?
> Der Kernel/ein Userspaceprogramm generiert irgendein Event irgendwo
> und irgendwer greift das irgendwie ab?
Exakt. siehe netlink(7) [relevant sind idF: NETLINK_KOBJECT_UEVENT]
> Meine Netzwerkkarte ist jetzt halt eth4 statt eth0, aber damit kann ich
> leben ;)
Das laesst sich mit udev sehr einfach umschreiben. Siehe udev(7).