{"id":3998,"date":"2014-04-05T02:43:47","date_gmt":"2014-04-05T01:43:47","guid":{"rendered":"http:\/\/www.blaess.fr\/christophe\/?p=3998"},"modified":"2014-05-03T03:24:35","modified_gmt":"2014-05-03T02:24:35","slug":"utiliser-un-appel-systeme-inconnu-de-la-libc","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2014\/04\/05\/utiliser-un-appel-systeme-inconnu-de-la-libc\/","title":{"rendered":"Utiliser un appel-syst\u00e8me inconnu de la libC"},"content":{"rendered":"

Lundi dernier, Linus a publi\u00e9 le nouveau noyau Linux 3.14<\/a>. Ce dernier contient de nombreuses nouveaut\u00e9s, dont un m\u00e9canisme d’ordonnancement temps r\u00e9el EDF<\/a> (Earliest Deadline First<\/em>) qu’il me tarde d’essayer. Pour cela deux nouveaux appels-syst\u00e8me sched_getattr()<\/code> et sched_setattr()<\/code> sont propos\u00e9s au programmeur, mais ils ne sont pas encore support\u00e9s par les biblioth\u00e8ques C actuelles. Qu’\u00e0 cela ne tienne, nous allons les invoquer directement…
\n\n
\nBien entendu, le contenu de cet article deviendra obsol\u00e8te dans quelques semaines – ou quelques mois tout au plus – car le support de sched_getattr()<\/code> et sched_setattr()<\/code> sera rapidement inclus dans les mises \u00e0 jours des biblioth\u00e8ques C, mais le principe global restera valable pour de futurs appels-syst\u00e8me.<\/p>\n

\"syscall\"<\/a>Les appels-syst\u00e8me impl\u00e9ment\u00e9s dans le noyau sont accessibles par l’interm\u00e9diaire de fonctions d’invocation qui se trouvent dans la biblioth\u00e8que C (par exemple GlibC). Lorsque celle-ci ignore l’existence d’appels-syst\u00e8me trop r\u00e9cents, il est toutefois possible de les invoquer directement par l’interm\u00e9diaire de la fonction syscall()<\/code>. Il est toutefois de notre ressort de conna\u00eetre le nombre et le type des param\u00e8tres attendus par le noyau. C’est ce que nous allons r\u00e9aliser ci-dessous.<\/p>\n

Installation du nouveau noyau<\/h1>\n

La premi\u00e8re \u00e9tape de cette exp\u00e9rience, consiste \u00e9videmment \u00e0 installer le nouveau noyau Linux.<\/p>\n

Voici pour m\u00e9moire les \u00e9tapes \u00e0 suivre sur une distribution de type Debian\/Ubuntu<\/p>\n

$ wget http:\/\/www.kernel.org\/pub\/linux\/kernel\/v3.x\/linux-3.14.tar.xz<\/a><\/strong>\n$ tar xJf linux-3.14.tar.xz<\/strong>\n$ cd linux-3.14<\/strong>\n$ cp \/boot\/config-<\/strong>???(le plus r\u00e9cent) .\/.config<\/strong>\n$ sudo make-kpkg --append-to-version -perso --initrd kernel_image<\/strong>\n$ cd ..<\/strong>\n$ sudo dpkg -i linux-image-3.14.0-perso*<\/strong>\n$ sudo reboot<\/strong><\/pre>\n
Protoypes des appels-syst\u00e8mes consid\u00e9r\u00e9s<\/h1>\n
En cherchant dans les sources du noyau, nous pouvons d\u00e9terminer les prototypes des appels-syst\u00e8mes que nous souhaitons invoquer.<\/p>\n
Pla\u00e7ons nous dans le r\u00e9pertoire des sources, puis recherchons le premier appel-syst\u00e8me.<\/p>\n
[linux-3.14]$ find . -type f | xargs grep sched_getattr<\/strong>\n.\/kernel\/sched\/core.c: * sys_sched_getattr - similar to sched_getparam, but with sched_attr\n.\/kernel\/sched\/core.c:SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct sched_attr __user *, uattr,\n.\/include\/linux\/syscalls.h:asmlinkage long sys_sched_getattr(pid_t pid,\n.\/include\/uapi\/asm-generic\/unistd.h:#define __NR_sched_getattr 275\n.\/include\/uapi\/asm-generic\/unistd.h:__SYSCALL(__NR_sched_getattr, sys_sched_getattr)\n[...]<\/pre>\n
L’appel est impl\u00e9ment\u00e9 dans le fichier kernel\/sched\/core.c<\/code> (seconde ligne de r\u00e9sultat) par la macro SYSCALL_DEFINE4<\/code>. Celle-ci indique que la fonction prendra quatre arguments.<\/p>\n
Le prototype est d\u00e9crit dans include\/linux\/syscalls.h<\/code> dont voici un extrait.<\/p>\n
asmlinkage long sys_sched_setscheduler(pid_t pid, int policy,\n                                        struct sched_param __user *param);\nasmlinkage long sys_sched_setparam(pid_t pid,\n                                        struct sched_param __user *param);\nasmlinkage long sys_sched_setattr(pid_t pid,\n                                        struct sched_attr __user *attr,\n                                        unsigned int flags);\n<\/strong>asmlinkage long sys_sched_getscheduler(pid_t pid);\nasmlinkage long sys_sched_getparam(pid_t pid,\n                                        struct sched_param __user *param);\nasmlinkage long sys_sched_getattr(pid_t pid,\n                                        struct sched_attr __user *attr,\n                                        unsigned int size,\n                                        unsigned int flags);<\/strong><\/pre>\n
Nous notons la pr\u00e9sence \u00e9galement du nouvel appel-syst\u00e8me sched_setattr()<\/code>. Ces deux fonctions prennent en argument un pointeur sur une structure sched_attr<\/code> sp\u00e9cifiquement d\u00e9finie pour elles. Recherchons sa d\u00e9claration…<\/p>\n
[linux-3.14]$ find . -name '*.h' | xargs grep sched_attr<\/strong>\n.\/include\/linux\/syscalls.h:struct sched_attr;\n.\/include\/linux\/syscalls.h:\t\t\t\t\tstruct sched_attr __user *attr,\n.\/include\/linux\/syscalls.h:\t\t\t\t\tstruct sched_attr __user *attr,\n.\/include\/linux\/sched.h: * This variant (sched_attr) is meant at describing a so-called\n.\/include\/linux\/sched.h: * This is reflected by the actual fields of the sched_attr structure:\n.\/include\/linux\/sched.h:struct sched_attr<\/strong> {\n.\/include\/linux\/sched.h:\t * Original scheduling parameters. Copied here from sched_attr\n.\/include\/linux\/sched.h:\t\t\t const struct sched_attr *);<\/pre>\n
Nous pouvons donc examiner cette structure dans include\/linux\/sched.h<\/code>.<\/p>\n
\/*\n * Extended scheduling parameters data structure.\n *\n * This is needed because the original struct sched_param can not be\n * altered without introducing ABI issues with legacy applications\n * (e.g., in sched_getparam()).\n *\n * However, the possibility of specifying more than just a priority for\n * the tasks may be useful for a wide variety of application fields, e.g.,\n * multimedia, streaming, automation and control, and many others.\n *\n * This variant (sched_attr) is meant at describing a so-called\n * sporadic time-constrained task. In such model a task is specified by:\n *  - the activation period or minimum instance inter-arrival time;\n *  - the maximum (or average, depending on the actual scheduling\n *    discipline) computation time of all instances, a.k.a. runtime;\n *  - the deadline (relative to the actual activation time) of each\n *    instance.\n * Very briefly, a periodic (sporadic) task asks for the execution of\n * some specific computation --which is typically called an instance--\n * (at most) every period. Moreover, each instance typically lasts no more\n * than the runtime and must be completed by time instant t equal to\n * the instance activation time + the deadline.\n *\n * This is reflected by the actual fields of the sched_attr structure:\n *\n *  @size               size of the structure, for fwd\/bwd compat.\n *\n *  @sched_policy       task's scheduling policy\n *  @sched_flags        for customizing the scheduler behaviour\n *  @sched_nice         task's nice value      (SCHED_NORMAL\/BATCH)\n *  @sched_priority     task's static priority (SCHED_FIFO\/RR)\n *  @sched_deadline     representative of the task's deadline\n *  @sched_runtime      representative of the task's runtime\n *  @sched_period       representative of the task's period\n *\n * Given this task model, there are a multiplicity of scheduling algorithms\n * and policies, that can be used to ensure all the tasks will make their\n * timing constraints.\n *\n * As of now, the SCHED_DEADLINE policy (sched_dl scheduling class) is the\n * only user of this new interface. More information about the algorithm\n * available in the scheduling class file or in Documentation\/.\n *\/\nstruct sched_attr<\/strong> {\n        u32 size;\n\n        u32 sched_policy;\n        u64 sched_flags;\n\n        \/* SCHED_NORMAL, SCHED_BATCH *\/\n        s32 sched_nice;\n\n        \/* SCHED_FIFO, SCHED_RR *\/\n        u32 sched_priority;\n\n        \/* SCHED_DEADLINE *\/\n        u64 sched_runtime;\n        u64 sched_deadline;\n        u64 sched_period;\n};<\/pre>\n
Num\u00e9rotation des appels-syst\u00e8me<\/h1>\n
Lorsque nous voudrons invoquer depuis un programme utilisateur ces nouveaux appels-syst\u00e8me, nous pourrons utiliser la fonction syscall()<\/code> de la biblioth\u00e8que C. N\u00e9anmoins celle-ci prend en argument le num\u00e9ro de l’appel-syst\u00e8me d\u00e9sir\u00e9, qu’il nous faut trouver dans les sources de Linux.<\/p>\n
Pour compliquer cette t\u00e2che, ce num\u00e9ro d\u00e9pend de l’architecture, et notre programme applicatif devra \u00eatre compil\u00e9 sp\u00e9cifiquement pour une cible donn\u00e9e. Les num\u00e9ros d’appel-syst\u00e8mes sont d\u00e9clar\u00e9s dans des fichiers d’en-t\u00eate, pr\u00e9fix\u00e9s de __NR_<\/code>.<\/p>\n
[linux-3.14]$ find arch  -type f | xargs grep __NR_sched_getattr<\/strong>\narch\/sparc\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t344\narch\/m68k\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t350\narch\/powerpc\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t356\narch\/ia64\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t\t1337\narch\/s390\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t346\narch\/x86\/include\/generated\/uapi\/asm\/unistd_64.h:#define __NR_sched_getattr 315\narch\/x86\/include\/generated\/uapi\/asm\/unistd_x32.h:#define __NR_sched_getattr (__X32_SYSCALL_BIT + 315)\narch\/x86\/include\/generated\/uapi\/asm\/unistd_32.h:#define __NR_sched_getattr 352\narch\/mips\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t\t(__NR_Linux + 350)\narch\/mips\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t\t(__NR_Linux + 310)\narch\/mips\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t\t(__NR_Linux + 314)\narch\/arm\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t\t(__NR_SYSCALL_BASE+381)\narch\/xtensa\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t\t\t335\narch\/parisc\/include\/uapi\/asm\/unistd.h:#define __NR_sched_getattr\t(__NR_Linux + 335)\n[linux-3.14]$ find arch  -type f | xargs grep __NR_sched_setattr<\/strong>\narch\/sparc\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t343\narch\/m68k\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t349\narch\/powerpc\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t355\narch\/ia64\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t\t1336\narch\/s390\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t345\narch\/x86\/include\/generated\/uapi\/asm\/unistd_64.h:#define __NR_sched_setattr 314\narch\/x86\/include\/generated\/uapi\/asm\/unistd_x32.h:#define __NR_sched_setattr (__X32_SYSCALL_BIT + 314)\narch\/x86\/include\/generated\/uapi\/asm\/unistd_32.h:#define __NR_sched_setattr 351\narch\/mips\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t\t(__NR_Linux + 349)\narch\/mips\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t\t(__NR_Linux + 309)\narch\/mips\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t\t(__NR_Linux + 313)\narch\/arm\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t\t(__NR_SYSCALL_BASE+380)\narch\/xtensa\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t\t\t334\narch\/parisc\/include\/uapi\/asm\/unistd.h:#define __NR_sched_setattr\t(__NR_Linux + 334)\n[linux-3.14]$<\/pre>\n
Nous avons donc, pour le couple sched_getattr()<\/code>\/sched_setattr()<\/code> les valeurs 352\/351 pour un PC x86 32 bits, 315\/314 pour un x86 64 bits, et ainsi de suite pour les autres architectures.<\/p>\n
Il nous manque une derni\u00e8re valeur, celle de la constante SCHED_DEADLINE<\/code> utilis\u00e9e pour choisir l’ordonnancement EDF.<\/p>\n
[linux-3.14]$ find include -name '*.h' | xargs grep SCHED_DEADLINE\ninclude\/linux\/sched.h: * As of now, the SCHED_DEADLINE policy (sched_dl scheduling class) is the\ninclude\/linux\/sched.h:\t\/* SCHED_DEADLINE *\/\ninclude\/linux\/sched\/deadline.h:#ifndef _SCHED_DEADLINE_H\ninclude\/linux\/sched\/deadline.h:#define _SCHED_DEADLINE_H\ninclude\/linux\/sched\/deadline.h: * SCHED_DEADLINE tasks has negative priorities, reflecting\ninclude\/linux\/sched\/deadline.h:#endif \/* _SCHED_DEADLINE_H *\/\ninclude\/generated\/autoconf.h:#define CONFIG_IOSCHED_DEADLINE 1\ninclude\/uapi\/linux\/sched.h:#define SCHED_DEADLINE      6<\/strong><\/pre>\n
Il s’agit donc de la constante 6<\/strong>.<\/p>\n
Impl\u00e9mentation des appels-syst\u00e8me dans un programme utilisateur<\/h1>\n
Attention !<\/strong> L’invocation directe des appels-syst\u00e8me est une source d’erreurs faciles, et donc potentiellement dangereuse pour votre syst\u00e8me et vos donn\u00e9es. Vous voici pr\u00e9venus \ud83d\ude09<\/p>\n
Nous allons impl\u00e9menter les invocations des appels-syst\u00e8me et la d\u00e9claration de la structure sched_param<\/code>, en prot\u00e9geant ce code par une compilation conditionnelle sur la constante SCHED_DEADLINE<\/code>. Ainsi lorsque les prochaines mises \u00e0 jour de la biblioth\u00e8que C viendront impl\u00e9menter ces fonctions, notre programme pourra continuer \u00e0 fonctionner, esp\u00e9rons-le, de mani\u00e8re transparente.<\/p>\n
En examinant l’impl\u00e9mentation de ces fonctions dans le noyau, nous pouvons voir que certaines suppositions sont faites sur le contenu des champs de la structure sched_attr<\/code> lorsque l’on choisit un ordonnancement SCHED_DEADLINE<\/code><\/p>\n