knasan

Linux and more

Archiv für das Schlagwort “funtoo”

Gentoo Linux support im Kernel

Eben wollte ich ein Gentoo Update einspielen und bemerkte das es schon wieder ein neuer Kernel Update gibt.
Erst gestern habe ich ein Kernel Update gemacht, was ich heute sah, erstaunte mich etwas, im Kernel gibt es jetzt Support für Gentoo Linux was wir systemd zu verdanken haben.

root@turanga ~ # eselect kernel set 2
root@turanga ~ # cd /usr/src/
root@turanga src # cp linux-3.10.6-gentoo/.config linux/
root@turanga src # cd linux
root@turanga linux # make oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf –oldconfig Kconfig
*
* Restart config…
*
*
* Gentoo Linux
*
Gentoo Linux support (GENTOO_LINUX) [Y/n] (NEW) y
Linux dynamic and persistent device naming (userspace devfs) support (GENTOO_LINUX_UDEV) [Y/n/?] (NEW) y
*
* Support for init systems, system and service managers
*
OpenRC, runit and other script based systems and managers (GENTOO_LINUX_INIT_SCRIPT) [Y/n/?] (NEW) y
systemd (GENTOO_LINUX_INIT_SYSTEMD) [N/y/?] (NEW)
#
# configuration written to .config
#
root@turanga linux #

Da ich Funtoo einsetzte und kein Gentoo kann ich momentan nicht auf systemd umsteigen, außer ich würde mir das aktuelle kmod ebuild besorgen, was bei Funtoo fehlt. Es sieht jedoch stark danach aus als würde man versuchen so weit und so lange es machbar ist, bei OpenRC zu bleiben. Ich bin gespannt ob wie lange das noch gut geht und ob am ende die Entwickler zusammenarbeiten oder jeder gegen jeden Programmiert.

Ob der und wie der Kernel Funktioniert weiß ich erst nach einem Neustart.

-Sandy

Advertisements

genfoo-tools, meine portage utils!

Ich hatte mal ein Script geschrieben das mir meine /etc/portage/package.keywords Datei in ein Verzeichnis Konvertierte. Es lag danach lange auf der Platte und schien in Vergessenheit zu geraten bis ich ein Beitrag auf gentooforum.de sah http://www.gentooforum.de/artikel/21118/packages-keywords-durchputzen-lassen-ist-das-m-glich.html?s=5bcd93f04f80b28ce377b28d287e352926658d62 .

Dort frage ein User nach, ob es denn möglich sei package.keywords zu putzen.
Ich wusste, da habe ich schon mal etwas geschrieben und schaute in meine Script Sammlung nach, „portkeyman“ (Portage Keyword Manger) gesucht und wieder gefunden.

Nun hatte ich zwei Möglichkeiten, das Script im Forum Posten und es erneut untergehen lassen oder doch lieber in Git verwalten. Ich beschloss mich, dieses Script auf mein Git zu legen, so das viele davon Profitieren können.

Nach kurzen Tests wurde mir klar, ich muss am Script noch etwas ändern. Ursprünglich war es eher als Hack gedacht um eine Lösung für mein damaliges Problem zu haben. Für eine Veröffentlichung war es noch nicht gut genug. So spendierte ich dieses Script eine kleine Hilfe und examples ein paar Fehlerkorrekturen und ab in Git.

Was mich noch störte, meine Kommentare die ich seit kurzem eingeführt habe wurden komplett Ignoriert. Also auch das noch schnell hinzugefügt.
Was auch lästig war, man musste immer angeben wo die packages.keywords liegt, deswegen habe gleich noch einen Default Path eingeführt. In der Regel liegt es ja immer unter /etc/portage/package.keywords als Datei oder Verzeichnis.

Hab das Script nun ein paar mal ausgeführt und es etwas einfacher, aber so dynamisch wie möglich umgeschrieben. Das Script erkennt nun ob man Root oder Normaler User ist und ändert den Logpath um nicht immer ein Logfile angeben zu müssen, was man aber natürlich noch kann.

Um es einfach unter Gentoo oder Funtoo Installieren zu können habe ich ein Ebuild „genfoo-tools“ geschrieben. Bevor ich jedoch noch mehr portage-utils Scripte Veröffentliche möchte ich portkeyman um ein paar weitere Funktionen erweitern. Hinzufügen und entfernen von Keywords um ein Beispiel zu nennen. Ich überlege auch, einen Parameter einzuführen der das nicht in /tmp speichert sondern die Änderungen sofort im System erledigt.

Ich merke schon dass das Script vieles Automatisieren könnte oder schon tut, was man lang händisch erledigt hat. Daher würde mir ein completion Script noch gefallen, habe bisher nur eines geschrieben und bin noch nicht ganz durchgestiegen wie das genau Funktioniert. Sobald das Script in einer Phase ist wo man sagen kann, es hat alles was man sich wünscht, werde ich mir completion noch einmal ansehen.

Wer mag, darf das Script gerne Testen und mir seine Ideen oder Kritik Schreiben, schließlich soll es unsere Arbeit erleichtern. Ich Antworte auf jeden Fall, auch wenn es mal etwas länger dauert. Also nicht ungeduldig werden 😉

Das Ebuild findet ihr hier: https://github.com/knasan/ebuilds/tree/master/app-portage/genfoo-tools
und das Script selbst hier: https://github.com/knasan/genfoo-tools

-Sandy

Nutze deinen RAM

Warum man Ram statt Festplatte verwendet liegt eigentlich auf der Hand.
Ram ist 1000% schneller als eine Festplatte, sogar eine SSD muss sich hier geschlagen geben. Deswegen wollte ich mir ansehen, ob und wie es Möglich ist, StuntRally im Ram zu Spielen.

Als erstes versuchte ich mich an einer chroot Umgebung, diese war mir am Schluss viel zu groß und wirklich sauber hatte es noch nicht funktioniert. Bis mir eine Idee kam.

Der Kernel hängt ein Virtuelles Dateisystem unter /dev/shm ein. Dieses Dateisystem ist nichts anderes als ein teil des Arbeitsspeichers.

Ich erstellt ein Verzeichnis new_home in /dev/shm also Normaler User. Kopierte .config/stuntrally, .local/share/games/stuntrally und .cache/stuntrally hinein.

In einem Terminal exportierte ich nun meine Home Variable

export HOME=/dev/shm/new_home

und startete das Spiel.

Mir ist sofort aufgefallen, dass das Game viel flüssiger läuft.

Aus diesem Grund habe ich einen wrapper geschrieben, der alle Daten von Suntrally nach /dev/shm/ Synchronisiert und beim beenden wieder nach sein Home.

Mein Ebuild habe ich ein neues USE-Flag spendiert das diesen Wrapper auf Wunsch Installiert.

Für alle die gerne diesen Wrapper verwenden möchten, aber kein Gentoo/Funtoo nutzen, hier das wrapper-script.

suntrally_wrapper

#!/bin/bash

#-------------------------------------------------------------------------------
# Author: Sandy Marko Knauer
# Email: knamarksan@gmail.com
# URL: https://knasan.wordpress.com/2013/02/09/nutze-deinen-ram/
# Description: StuntRally synchronizes files to StuntRally in memory to execute.
# Version: 0.0.1
# License: GNU GPL-v3
#-------------------------------------------------------------------------------

tmpfs=$(grep -c "/dev/shm" /proc/mounts)

new_home="/dev/shm/$USER"_new_home
old_home="$HOME"

if [ $tmpfs = "0" ]; then
echo "/tmp is not as a tmpfs filesystem"
exit
fi

stuntrally_cache=".cache/stuntrally/"
stuntrally_config=".config/stuntrally/"
stuntrally_local=".local/share/games/stuntrally/"

mkdir -p $new_home || exit
mkdir -p $new_home/$stuntrally_cache || exit
mkdir -p $new_home/$stuntrally_config || exit
mkdir -p $new_home/$stuntrally_local || exit

if [ -d $HOME/$stuntrally_cache ]; then
rsync -a --progress $HOME/$stuntrally_cache $new_home/$stuntrally_cache || exit
else
mkdir -p $HOME/$stuntrally_cache || exit
fi

if [ -d $HOME/$stuntrally_local ]; then
rsync -a --progress $HOME/$stuntrally_local $new_home/$stuntrally_local || exit
else
mkdir -p $HOME/$stuntrally_local || exit
fi

if [ -d $HOME/$stuntrally_config ]; then
rsync -a --progress $HOME/$stuntrally_config $new_home/$stuntrally_config || exit
else
mkdir -p $HOME/$stuntrally_config || exit
fi

export HOME=$new_home
/usr/bin/stuntrally

rsync -a $new_home/$stuntrally_local $old_home/$stuntrally_local --numeric-ids --progress --delete || ex>
rsync -a $new_home/$stuntrally_config $old_home/$stuntrally_config --numeric-ids --progress --delete || ex>
rsync -a $new_home/$stuntrally_cache $old_home/$stuntrally_cache --numeric-ids --progress --delete || ex>

rm -r $new_home

Hier nochmal ein direklink auf die Datei, da leider die Formatierung verloren geht. https://github.com/knasan/ebuilds/blob/master/games-sports/stuntrally/files/stuntrally_wrapper

StuntRally unterliegt der GNU/GPL-v3, deswegen habe ich mich auch für diese Lizenz entschieden.

-Sandy

Stuntrally Crash in Championship mode

Heute dachte ich mir ich teste Stuntrally Championship, eine Runde … Segmentation fault

Ups was ist das denn? Ein Bug in mein Ebuild?

Ich machte mich erstmal auf die Suche ob dieser Bug bekannt ist, ja ist er.
Im Forum von Stuntrally wurde ich fündig: http://forum.freegamedev.net/viewtopic.php?f=78&t=4089

Dies lies mich nicht los und wollte es genau wissen.
Beim Ebuild schreiben hatte ich festgestellt das Ogre nicht mit USE-Flag threads compiliert werden darf. Das Spiel lies sich nie starten deswegen hatte ich -threads für Ogre im Ebuild hart Maskiert.

Da dieser Bug etwas mit Multithreads zu tun hat, dachte ich mir es muss doch möglich sein Ogre mit threads nutzen zu können. Ich schaute mir die Ebuilds von Ogre und ein paar andere die in Abhängigkeit standen an. Nach kurzer Zeit stelle ich fest das sci-libs/fftw oft in Abhängigkeit stand und wenn threads gewählt ist mit dem USE-Flag mpi verlangt wurde.

Okay, erster test Ogre mit threads compiliert, Stuntrally crasht wie gewohnt.
Also fftw mit mpi USE-Flag compiliert, wow Stuntrally startete ohne zu murren, dachte mir gutes Zeichen.

Championship, eine Runde … Segmentation fault

Eine Runde Erholung zur belohnung dachte ich mir, dabei stellte ich fest dass das Game nicht mehr Ruckelt an stellen wo ich es eigentlich gewohnt war. Fast schon unheimlich, ich hatte mich so sehr an das Ruckeln gewöhnt das mir nun die Steuerung ohne Ruckeln etwas schwer gefallen ist.

Ich dachte immer, das dass Bild besser wurde als ich dev-cpp/asio hinzugefügt hatte, hier hatte ich mich getäuscht. Dieses Paket wurde von vdrift benötigt, aber nicht von Stuntrally.

Nochmal getestet, diesmal ohne dev-cpp/asio. Konnte keinen Unterschied feststellen, Stuntrally verwendet also dev-cpp/asio gar nicht. Zurück zu Championship, was ich heute ja unbedingt mal testen wollte. Wie im Forum Beschrieben stelle ich die Parameter der game.cfg in Section [ slim ] multi_tr = 1 auf 0.

Danach funktionierte Championship und das beste es läuft immer noch flüssig.

Wenn ihr also denkt das eure Grafikkarte das Game ohne Ruckeln packen sollte, dann versucht Stuntrally mal mit threads zu compiliern. Spassfaktor steigt wenn das Game nicht Ruckelt gewaltig in die höhe.

Das neue Ebuild liegt ab sofort auf meinem Github
https://github.com/knasan/ebuilds/tree/master/games-sports/stuntrally

Sandy

hard-masked USE-Flags

Ich bin schön des öfteren darauf gestoßen dass die USE-Fags 3dnow, 3dnowext, sse, sse2 und sogar vdpau hard-masked sind.
Warum das so ist, wusste ich bisher nicht. Heute bin ich zufällig auf eine Seite gestoßen warum 3dnow, 3dnowext, sse und sse2 maskiert sind.

Ursprünglich wurden die USE-Flags eingeführt, um die Unterstützung für ältere Prozessoren wie der Pentium I, der nichts mit diesen Flags anfangen kann, zu emulieren.
Derzeit unterstützen alle AMD64s die gleiche Kombination von erweiterten Befehlssätze, so gibt es keinen Grund zur Verwendung der genannten USE-Flags.
Deshalb sind diese USE-Flags hart maskiert in allen AMD64-Profilen.

Es bedeutet jedoch nicht das diese nicht verwendet werden können, man kann diese USE-Flags hart einschalten. Die Frage lautet nun, benötigt man diese?
Was sind die Vor bzw. Nachteile, darauf wird leider nicht eingegangen, es ist nur beschrieben warum diese Maskiert sind. Aber immer hin, nun kenne ich den Grund.

Assembler Optimisation

Modern x86 processors support special instruction sets like mmx, sse, SSE2 and 3DNow!. AMD64 also provides support for them, but in most cases, x86 assembler code is incompatible with AMD64 assembler. There are lots of packages that provide support through USE flags for these instruction sets. Originally, the USE flags were introduced to keep support for older processors such as the Pentium I that can’t handle such code. Currently, all AMD64s support the same combination of extended instruction sets, so there is no reason to make use of the mentioned USE flags. That’s why these USE flags are hard-masked in all AMD64-profiles. This doesn’t mean we don’t support the extensions themselves, instead, we hard-enable them.

The following USE flags are masked on AMD64:

mmx
mmx2
sse
sse2
3dnow
3dnowext

Quelle: http://devmanual.gentoo.org/archs/amd64/index.html

Es gibt zur Zeit vieles was ich an den USE-Flags nicht verstehe und hoffe das ich darüber mehr Informationen sammeln kann. Leider sind die Aussagen wie „X – Support for X11“ wenig aussage kräftig und es zum Beispiel um opengl geht. „opengl, gles1 und geles2“ Laut google gibt es schon gles3. Heißt es nun wenn man gles2 setzt kein gles3 bekommt? Ein USE-Flag für gles3 gibt es gar nicht – ist es der Standard? All solche dinge kosten oft etwas Zeit und diese Aufgabe werde ich mich demnächst kümmern und hier veröffentlichen.

http://www.khronos.org/opengles/

Da diese USE-Flags etwas mit Tuning zu tun haben, möchte ich nun wirklich etwas Zeigen was getuned ist.
In mein System sind zwei SSD, eine für mein HOME und die andere mein System. Zum Kompilieren verwende ich „ccache“ und meine MAKEOPTS ist auf „-j8“ gestellt.
Getestet habe ich libreoffice, was normal ca 60 Minuten dauert (etwas mehr oder weniger). Mit aktivem ccache und MAKEOPTS -j8, wenn libreoffice schon im cache liegt, dauert es nur noch 14 Minuten.
Aber was Passiert wenn man den Scheduler ändert? Auf diese Idee bin ich gekommen, da ich gelesen habe dass man für SSDs den Scheduler auf „noop“ setzen sollte. Hier die Resultate mit time gemessen.

cfg
real 14m11.091s
user 20m37.011s
sys 7m59.036s

noop
real 12m36.266s
user 19m59.285s
sys 7m33.866s

deadline
real 12m40.719s
user 20m2.532s
sys 7m36.524s

Es gibt derzeit diese drei Scheduler, cfg, noop und deadline. Der Scheduler kann während des betrieb gewechselt werden, dieser überlebt jedoch keinen Neustart des Systems.
Da der Scheduler in /sys/block/FESTPLATTE/queue/schedule gesetzt werden muss, kann dieser nicht in sysctl.conf gesetzt werden, sysctl ist nur dafür ausgelegt das /proc zu ändern.
Möchte man den Scheduler seiner Wahl beim hochfahren aktivieren gibt es drei Möglichkeiten.

1. Man schreibt sich ein eigenes Init Skript (schlechte idee)
2. Man kompiliert einfach den Kernel so, dass der Standard Scheduler nicht „cfq“ sondern ein anderer ist. Machbar, kostet aber mehr Zeit. Diese IDEE ist aber nur bedingt schlecht, denn manche Scheduler sind für Datenbank-Zugriff besser geeignet und könnte auf einem Server durchaus Sinn machen.
3. Man verwendet ein Bash Script (was kein init Skript ist) der einfach per echo den Scheduler beim hochfahren des Rechners setzt. Hierfür gibt es in Gentoo/Funtoo das Verzeichnis /etc/local.d.

Einfach diesen Code in einer Datei Speichern unter /etc/local.d und ausführbar machen. Schon hat man seinen Scheduler seiner Wahl per Default 🙂

#!/bin/sh
echo noop > /sys/block/sda/queue/scheduler
echo noop > /sys/block/sdb/queue/scheduler

Es kommt auch mal vor, das ein anderer Scheduler benötigt wird. Auch hierfür gibt es eine einfache Lösung.
Dieses Script nach /usr/local/sbin Speichern, ich nannte es switch_scheduler.

#!/bin/sh

if [ -z $1 ]; then
echo "cfq, noop or deadline"
exit
fi

echo $1 > /sys/block/sda/queue/scheduler
echo $1 > /sys/block/sdb/queue/scheduler

Als Root, ist es nun ganz einfach Möglich auf einen anderen Scheduler zu wechseln. Dieses Script ist natürlich total dumm, da nicht geprüft wird ob es den angegeben Scheduler überhaupt existiert.
Es ist durchaus denkbar, einen Schuduler aus dem Kernel zu werfen und somit existiert diese nicht. Auf einer komplexen überprüfung habe ich auch verzichtet, da nun der Scheduler geschrieben werden kann, der auch existiert.

Welche Scheduler das System unterstütz bekommt man mit cat raus.

cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

Der zur Zeit verwendete Scheduler wird hier in eckigen Klammern gelistet.

Wird der Scheduler nicht vom System unterstützt bekommt man eine Fehlermeldung, ansonsten passiert nichts

sudo switch_scheduler hallo
/usr/local/sbin/switch_scheduler: line 8: echo: write error: Invalid argument
/usr/local/sbin/switch_scheduler: line 9: echo: write error: Invalid argument

Oder auf Deutsch

udo switch_scheduler hallo
/usr/local/sbin/switch_scheduler: Zeile 8: echo: Schreibfehler: Das Argument ist ungültig.
/usr/local/sbin/switch_scheduler: Zeile 9: echo: Schreibfehler: Das Argument ist ungültig.

Es kann sich also lohnen, mal zu testen wie sich die Scheduler im Alltag verhalten. Beim Kompilieren hat eindeutig noop bei mir gewonnen.
Diesen habe ich auch mal auf Default gesetzt. Selbst beim Spiel stuntrally merke ich keinen unterschied. Dies kann aber an meiner SSDs zusammen hängen.
Wenn ich denke, hm ist irgendwie langsam, wechsel ich zu cfq, dieser ist in der Regel der Default Scheduler.

Viel Spaß beim Testen.

knasan

Beitragsnavigation

%d Bloggern gefällt das: