@robert_s:
Bitte richtig lesen ... ich schrieb ja eindeutig (und nicht ohne Absicht): "
dem Environment nach" und dort steht in dem anderen Thread der Eintrag "
Fritz_Box_HW220a".
Wagt man dann einen Blick in die "/etc/puma6_helper.sh" aus einer neueren Firmware (selbstverständlich aus einer, die nicht aus der 6590 stammt, auch das geht aus dem Rest meines Textes ja deutlich hervor), ist das nun einmal die Sicht des ARM-Cores:
Code:
[COLOR="#FF0000"]is_puma_arm()[/COLOR]
{
if [ "$CONFIG_PRODUKT" = Fritz_Box_HW199a ] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW204a ] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW213a ] || [COLOR="#FF0000"][ "$CONFIG_PRODUKT" = Fritz_Box_HW220a ][/COLOR] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW231a ] ; then
return 0
else
return 1
fi
}
[COLOR="#008000"]is_puma_atom()[/COLOR]
{
if [ "$CONFIG_PRODUKT" = Fritz_Box_HW199x ] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW204x ] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW213x ] || [COLOR="#008000"][ "$CONFIG_PRODUKT" = Fritz_Box_HW220x ][/COLOR] || [ "$CONFIG_PRODUKT" = Fritz_Box_HW231x ] ; then
return 0
else
return 1
fi
}
is_puma_na()
{
if [ "$CONFIG_DOCSIS_MODEM" = y ] ; then
# New Architecture
return 0
else
# Old Architecture
return 1
fi
}
is_puma6_arm()
{
if is_puma_arm && ! is_puma_na ; then
# PUMA6 ARM
return 0
else
# no PUMA6 ARM
return 1
fi
}
is_puma_na_arm()
{
if is_puma_arm && is_puma_na ; then
return 0
else
return 1
fi
}
is_puma6_atom()
{
if is_puma_atom && ! is_puma_na ; then
# PUMA6 ATOM
return 0
else
# no PUMA6 ATOM
return 1
fi
}
is_puma_na_atom()
{
if is_puma_atom && is_puma_na ; then
return 0
else
return 1
fi
}
is_puma6()
{
if is_puma_arm || is_puma_atom ; then
# PUMA6
return 0
else
# no PUMA6
return 1
fi
}
... zumindest nach dem bisherigen Stand der Firmware.
Wenn dann irgendwann mal klar ist, welchen Wert die ebenfalls zuvor angesprochene Variable "CONFIG_DOCSIS_MODEM" wirklich hat, dann kann man auch den Rest der Unterscheidungen in der gezeigten Shell-Datei nachvollziehen und damit die Frage nach der "New Architecture" beantworten.
Wobei ich das "i686" tatsächlich nicht gesehen habe und damit auch klar sein dürfte, daß der von mir zuvor nur vermutete Transfer wohl wirklich stattgefunden hat.
Ansonsten kann man bei einer Bemerkung "weil die Architektur A wohl eher keine Befehle aus Architektur B ausführt" auch mal auf der Nase landen - auch wenn hier eine Emulation (x86 auf ARM) eher unwahrscheinlich ist, ist das für die "Gegenrichtung" alles andere als "seltsam"; vielleicht noch auf so einem Consumer-Router, aber vermutlich auch nicht mehr lange.
- - - Aktualisiert - - -
Ansonsten habe ich leider keinen Zugriff auf das Intel CEFDK für den Puma6 ... ich kenne das aber zumindest von anderen Stellen so, daß der Chip-Hersteller seinerseits Kernel-Patches für verschiedene Versionen bereitstellt und der Hardware-Hersteller damit dann "seinen" Kernel patcht.
Wenn Intel das wirklich nur für 2.6.39 gemacht haben sollte (das ist ja die letzte 2.6er-Version überhaupt und die hat zumindest einige wichtige Änderungen an Bord, z.B. die komplette Abschaffung des "Big Kernel Lock") und tatsächlich anstelle von Patches (die man dann auf einen 3er-Kernel anpassen könnte, schließlich ist der erste 3er eigentlich nur die Umstellung der Nummerierung und er hätte auch 2.6.40 heißen können - in den neun Monaten von 2.6.39 zur 3.2 (das ist ein LTS-Zweig) wurde ja nicht alles komplett umgeschrieben) ein komplettes Source-Paket bereitstellt, was nun kein Hersteller erst per Differenzbildung in einen neueren 3er-Kernel integrieren will, dann könnte ich dieser Annahme folgen. Ansonsten hätte auch Arris/Motorola halt den Weg des 2.6.39-Kernel gewählt und seinerseits das veröffentlicht, was in dem konkreten Gerät eingesetzt wird ... und nicht direkt die (Patch-)Dateien aus einem Intel Development Kit.
Ich wäre aber schon deshalb verblüfft, wenn es von Intel (ausschließlich) einen kompletten Kernel-Tree geben sollte, weil dann Intel auch automatisch dafür zuständig wäre, bei einem (Security-)Problem an anderer Stelle im 2.6.39-Kernel neue Quellen bereitzustellen, damit die Hersteller ihrerseits das Problem angehen können. Das ist - nach dem was ich jedenfalls ansonsten kenne - ein eher ungewöhnliches Vorgehen ... auch wenn es natürlich das "Delegieren" der Verantwortung von Herstellern an den Chipsatz-Hersteller wesentlich erleichtern kann.
2.6.39 ist halt lange raus aus der "Maintenance" (da gibt es auch keinen "offiziellen" Maintainer, der noch die 2.6er wartet - es gab eben keine wirklich tiefgreifenden Veränderungen beim "Sprung" auf die neue Nummerierung) und selbst der bei den VR9-Modelle verwendete 3.10 als LTS-Version endet eigentlich irgendwann in diesem Jahr (noch vor dem 3.2-Zweig). Gerade bei den x86-Prozessoren dürfte es aber auch einiges an Verbesserungen in neuen Kernel-Versionen geben, die sich richtig positiv bemerkbar machen - das ist (oder war es zumindest mal) nun mal die primär unterstützte Plattform (gerade auch für Server und viele Performance-Verbesserungen zielten auf Serverbetrieb ab) - allerdings mögen sich beim Netzwerk-Stack tatsächlich Anpassungen für Offloading und Verbesserungen im Vanilla-Kernel ab und an mal ins Gehege kommen.
).
