Fuchsia : le mystérieux OS de Google fera tourner des applications développées en Swift
Un langage supplémentaire après Go, Rust et Python

Le , par Patrick Ruiz, Chroniqueur Actualités
Fuchsia, le nouvel OS de Google dont la vidéo de présentation a filtré sur cette plateforme au mois de mai continue son bout de chemin de façon plus ou moins furtive. Si ce dernier dispose bien d’un dépôt sur une des plateformes de partage open source les plus en vue du moment, il faut bien souligner que la firme de Mountain View ne communique pas trop à son sujet. De récentes publications font cependant état de ce que Google s’intéresse au langage de développement Swift d’Apple.

À la réalité, la firme de Mountain View va au-delà de l’intérêt. À date, il existe un dépôt GitHub pour la prise en charge du langage Swift par le mystérieux système d’exploitation. L’information est de Zack Bowling de Google, l’un des développeurs qui ont travaillé sur le portage du langage Objective-C sur la plateforme Android. Des exemples de code d’applications développées en langage Swift pour l’OS Fuchsia sont fournis. Se référer aux liens dans les sources pour le détail. À noter que Swift vient allonger une liste de langages plus ou moins fournie avec Java, Dart, Go, Python, Rust et bien sûr C/C++ pour le développement d’applications natives, le système d’exploitation lui-même étant principalement développé en C/C++.


Swift est un langage de programmation développé par le géant de la marque à la pomme pour la création d’applications destinées aux systèmes d’exploitation iOS, macOS, tvOS et watchOS. La perspective de pouvoir compiler des applications développées en langage Swift pour la plateforme Fuchsia ne signifie aucunement qu’une application développée pour l’un des OS précités est de facto portable sur ce dernier. Noter à ce propos qu’il faudra retravailler les éléments d’interface utilisateur dont les bases de code sont maintenues sous licence propriétaire par Apple.

Si l’on fait le parallèle avec les PC, la prise en charge d’un nouveau langage de programmation par cet OS en développement ne peut qu’être une bonne chose. Dans ces conditions en effet, la plateforme devient plus attrayante pour les développeurs du fait de la liberté qui leur est accordée d’utiliser le langage avec lequel ils sont le plus à leur aise. Rien n’a pour le moment filtré sur le rôle que Google réserve effectivement à cet OS en gestation dans un écosystème où il retrouve au moins le très répandu Android et Chrome OS. Toutefois, d’après des confidences de développeurs, Fuchsia intègre l’API Mojo de Chromium.

Mojo permet le support d’applications Android sous Chrome OS. De plus, l’API serait le socle sur lequel le support des langages de programmation pris en charge repose. Il semble donc que Fuchsia est destiné à être un pont entre les plateformes logicielles que sont Android et Chrome OS. Vu sous cet angle il y a en effet du boulot. Fuchsia devrait corriger des soucis avec les applications Android qui, dit-on, s’exécutent uniquement via le shell sous Chrome OS. Il ne s’agit que d’hypothèses ; on demeure dans l’attente d’une communication de Google qui viendra lever le mystère qui entoure cet OS.

Sources

The Verge

GitHub

Codes source d’applications Swift pour Fuchsia

Votre avis

Quel commentaire faites-vous de la disponibilité du langage Swift sur Fuchsia ?

Voir aussi

Projet Fuchsia : Google serait en train de développer un nouvel OS destiné à faire tourner des appareils allant des objets connectés aux ordinateurs


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Christian Olivier Christian Olivier - Chroniqueur Actualités https://www.developpez.com
le 03/01/2018 à 5:18
Fuchsia OS de Google est désormais compatible avec le laptop Pixelbook
Ce qui semble indiquer que le développement de l’OS avance

Fuchsia OS devrait être, après Chrome OS et Android, le troisième système d’exploitation de l’entreprise technologique américaine Google. Les informations qui ont filtré jusqu’à présent ne permettent pas de déterminer de façon certaine le rôle final que la firme de Mountain View réserve à cet OS en gestation. Toutefois, les dernières annonces effectuées par la filiale d’Alphabet concernant la liste des appareils pris en charge par Fuchsia OS tendent à confirmer que cet OS pourrait bien équiper des ordinateurs portables haut de gamme.

La documentation en ligne du nouvel OS indique en effet que l’ordinateur portable de Google, le Pixelbook, est désormais pris en charge par Fuchsia OS, tout comme l’Acer Switch Alpha 12 et le NUC d’Intel avant lui. Google a créé une nouvelle page où l’entreprise explique comment installer le système d’exploitation Fuchsia sur le Pixelbook. Il faut préciser que cet appareil est le dernier ordinateur portable convertible de Google, qu’il tourne sous Chrome OS et affiche un prix de base de 1000 euros.


On peut aussi signaler qu’il existe un dépôt GitHub qui fait état de la prise en charge du langage Swift d’Apple par Fuchsia OS. Swift vient allonger une liste de langages supportés relativement fournie incluant Java, Dart, Go, Python, Rust et bien sûr C/C++ pour le développement d’applications natives. Cependant, la perspective de pouvoir compiler des applications développées en langage Swift pour la plateforme Fuchsia ne signifie aucunement qu’une application développée pour l’un des OS précités est de facto portable sur ce dernier.

Contrairement à Android et Chrome OS, Fuchsia n’est pas basé sur Linux. Il s’appuie sur un nouveau micronoyau appelé « Magenta » et développé par Google. Magenta est un micronoyau de taille moyenne caractérisé par sa capacité de s’adapter à différents types de systèmes de toutes tailles et formes (appareils embarqués, smartphones, ordinateurs…).

Fuchsia OS devrait intégrer l’API Mojo de Chromium qui permet le support d’applications Android sous Chrome OS. De plus, l’API serait le socle sur lequel le support des langages de programmation pris en charge repose. Fuchsia OS aurait été conçu pour équiper une nouvelle gamme de dispositifs modernes incluant des smartphones, des PC.

Il semble que ce système d’exploitation mystérieux de la firme de Mountain View soit destiné à être un pont entre les plateformes logicielles que sont Android et Chrome OS et qu’il vise les ordinateurs portables haut de gamme de la filiale d’Alphabet pour le moment. Cette annonce laisse également supposer que Google poursuit toujours le développement de ce système d’exploitation.

Source : Google Ressource

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Projet Fuchsia : Google serait en train de développer un nouvel OS destiné à faire tourner des appareils allant des objets connectés aux ordinateurs
Avatar de UndeadangerousK UndeadangerousK - Membre habitué https://www.developpez.com
le 03/01/2018 à 10:05
Même si green OS (comme Android, avant leur rachat en 2005) n'a pas été spécifiquement initié par Google, il reste très orienté Google. On pourrait presque dire que c'est aussi un OS Google.. Même s'il n'est pas maintenu. Du coup, ca fait 4 OS a leur actif.
Avatar de nhugodot nhugodot - Membre régulier https://www.developpez.com
le 07/01/2018 à 11:49
Java n'est sûrement pas supporté nativement par Fuschia: c'est justement parce que Java a été racheté par Oracle via le rachat de Sun que Google, poursuivi, harcelé, par Oracle, veut s'en défaire, comme il s'est défait de GWT, et a donc créé Go et Dart (hop, Java et Javascript à la poubelle, une page se tourne... idem C et C++ remplacés par Rust autant que possible: bienvenue dans le 21e siècle)

Quant à Swift, ce serait beau... On aurait ainsi Dart (avec Flutter) et Swift capables de tourner sur 2 OS... Mais comme alors Google aurait aussi accepté Swift sur Android pour nous faciliter la tâche, je ne vois pas pourquoi il l'accepte sur Fuschia et pas Android? Donc là aussi, j'ai un gros doute...
Avatar de Patrick Ruiz Patrick Ruiz - Chroniqueur Actualités https://www.developpez.com
le 13/04/2018 à 8:23
Fuchsia OS : C++ est-il plus avantageux que C pour le développement d’un microkernel ?
Le choix de Google divise

Les nouvelles de l’existence d’un mystérieux système d’exploitation en développement du côté de la firme de Mountain View ont commencé à filtrer sur cette plateforme il y a bientôt deux ans. Depuis, pas d’annonce officielle de la part de Google, mais une communication par dépôts interposés.

Ce qui serait le premier de tous est apparu sur GitHub. À date, ce dernier semble ne plus être disponible sur la plateforme d’hébergement et de gestion de développement des logiciels (ou a tout simplement été renommé). Il a toutefois laissé filtrer un certain nombre d’informations importantes à propos de cet OS, notamment, sur les supputations relatives au possible lien de filiation avec Linux. On sait depuis lors que Fuchsia est basé sur Magenta, un microkernel qui tire ses fondations du projet Little Kernel – affectueusement baptisé LK par les férus de programmation – et donc, ne dérive pas du noyau Linux.

Google l’a réitéré dans la nouvelle documentation accessible sur sa propre plateforme Git en déclarant que « Fuchsia n’est pas Linux. » Magenta, devenu Zircon par le truchement d’un changement de dénomination, adopte bien l’approche microkernel tandis que Linux est un noyau monolithique. Sur la question des usages réservés à Fuchsia, le lien de filiation donne des pistes.

« LK (Little Kernel) est un infime système d’exploitation qui vise des applications au sein de petits appareils embarqués, des chargeurs d’amorce et autres environnements au sein desquels des primitives comme les threads, les mutexes et les timers sont requis, tout en gardant à l’esprit de conserver une empreinte mémoire légère », lit-on sur le dépôt du projet dont Fuchsia tire ses sources. Fuchsia est donc conçu pour s’adapter à différents types de systèmes de toutes tailles et formes (systèmes embarqués, ordiphones, ordinateurs…).

Voilà de façon brossée ce que cache le mystérieux OS de Google. Des détails supplémentaires feront surface dans les jours à venir puisque certaines sections de la documentation demeurent grisées. Toutefois, un aspect déjà bien visible dans la doc actuelle divise énormément la communauté : Google a fait le choix du langage C++ au détriment du C pour coder le microkernel qui anime le système d’exploitation.


Les discussions sur les fils reddit battent leur plein à ce sujet. Google a implémenté l’allocation dynamique de mémoire et la gestion des exceptions au sein du microkernel, toutes choses qui justifient le choix du langage C++. Illustration avec cette portion du code source de l’interface de gestion de threads.

Code cpp : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
// Copyright 2016 The Fuchsia Authors 
	// Copyright (c) 2008-2015 Travis Geiselbrecht 
	// 
	// Use of this source code is governed by a MIT-style 
	// license that can be found in the LICENSE file or at 
	// https://opensource.org/licenses/MIT 
  
	/** 
         * @file 
         * @brief  Kernel threading 
         * 
         * This file is the core kernel threading interface. 
         * 
         * @defgroup thread Threads 
         * @{ 
         */ 
	#include <kernel/thread.h> 
  
	#include <arch/exception.h> 
	#include <assert.h> 
	#include <debug.h> 
	#include <err.h> 
	#include <inttypes.h> 
  
	#include <kernel/atomic.h> 
	#include <kernel/dpc.h> 
	#include <kernel/mp.h> 
	#include <kernel/percpu.h> 
	#include <kernel/sched.h> 
	#include <kernel/stats.h> 
	#include <kernel/thread.h> 
	#include <kernel/timer.h> 
  
	#include <lib/counters.h> 
	#include <lib/heap.h> 
	#include <lib/ktrace.h> 
  
	#include <list.h> 
	#include <malloc.h> 
	#include <object/c_user_thread.h> 
	#include <platform.h> 
	#include <printf.h> 
	#include <string.h> 
	#include <target.h> 
	#include <vm/vm.h> 
	#include <zircon/types.h> 
  
	// kernel counters. TODO(cpu): remove LK-era counters 
	// The counters below never decrease. 
	// 
	// counts the number of thread_t succesfully created. 
	KCOUNTER(thread_create_count, "kernel.thread.create"); 
	// counts the number of thread_t joined. Never decreases. 
	KCOUNTER(thread_join_count, "kernel.thread.join"); 
	// counts the number of calls to suspend() that succeeded. 
	KCOUNTER(thread_suspend_count, "kernel.thread.suspend"); 
	// counts the number of calls to resume() that succeeded. 
	KCOUNTER(thread_resume_count, "kernel.thread.resume"); 
  
	/* global thread list */ 
	static struct list_node thread_list = LIST_INITIAL_VALUE(thread_list); 
  
	/* master thread spinlock */ 
	spin_lock_t thread_lock = SPIN_LOCK_INITIAL_VALUE; 
  
	/* local routines */ 
	static void thread_exit_locked(thread_t* current_thread, int retcode) __NO_RETURN; 
	static void thread_do_suspend(void); 
  
	static void init_thread_struct(thread_t* t, const char* name) { 
	    memset(t, 0, sizeof(thread_t)); 
	    t->magic = THREAD_MAGIC; 
	    strlcpy(t->name, name, sizeof(t->name)); 
	    wait_queue_init(&t->retcode_wait_queue); 
	} 
  
	static void initial_thread_func(void) TA_REQ(thread_lock) __NO_RETURN; 
	static void initial_thread_func(void) { 
	    int ret; 
  
	    /* release the thread lock that was implicitly held across the reschedule */ 
	    spin_unlock(&thread_lock); 
	    arch_enable_ints(); 
  
	    thread_t* ct = get_current_thread(); 
	    ret = ct->entry(ct->arg); 
  
	    thread_exit(ret); 
	} 
  
  
	/** 
         * @brief  Create a new thread 
         * 
         * This function creates a new thread.  The thread is initially suspended, so you 
         * need to call thread_resume() to execute it. 
         * 
         * @param  name            Name of thread 
         * @param  entry           Entry point of thread 
         * @param  arg             Arbitrary argument passed to entry() 
         * @param  priority        Execution priority for the thread. 
         * @param  stack_size      Stack size for the thread. 
         * @param  alt_trampoline  If not NULL, an alternate trampoline for the thread 
         *                         to start on. 
         * 
         * Thread priority is an integer from 0 (lowest) to 31 (highest).  Some standard 
         * prioritys are defined in <kernel/thread.h>: 
         * 
         *  HIGHEST_PRIORITY 
         *  DPC_PRIORITY 
         *  HIGH_PRIORITY 
         *  DEFAULT_PRIORITY 
         *  LOW_PRIORITY 
         *  IDLE_PRIORITY 
         *  LOWEST_PRIORITY 
         * 
         * Stack size is typically set to DEFAULT_STACK_SIZE 
         * 
         * @return  Pointer to thread object, or NULL on failure. 
         */ 
	thread_t* thread_create_etc( 
	    thread_t* t, 
	    const char* name, 
	    thread_start_routine entry, void* arg, 
	    int priority, 
	    void* stack, void* unsafe_stack, size_t stack_size, 
	    thread_trampoline_routine alt_trampoline) { 
	    unsigned int flags = 0; 
  
	    if (!t) { 
	        <span style="font-family: monospace; padding: 2px; background: #ddd; display: inline-block">t = malloc(sizeof(thread_t));  // allocation dynamique …</span>	        
                    if (!t) 
	            return NULL; 
	        flags |= THREAD_FLAG_FREE_STRUCT; 
	    } 
  
	    init_thread_struct(t, name); 
  
	    t->entry = entry; 
	    t->arg = arg; 
	    t->state = THREAD_INITIAL; 
	    t->signals = 0; 
	    t->blocking_wait_queue = NULL; 
	    t->blocked_status = ZX_OK; 
	    t->interruptable = false; 
	    t->curr_cpu = INVALID_CPU; 
	    t->last_cpu = INVALID_CPU; 
	    t->cpu_affinity = CPU_MASK_ALL; 
  
	    t->retcode = 0; 
	    wait_queue_init(&t->retcode_wait_queue); 
  
	    sched_init_thread(t, priority); 
  
	    /* create the stack */ 
	    if (!stack) { 
	        if (THREAD_STACK_BOUNDS_CHECK) { 
	            stack_size += THREAD_STACK_PADDING_SIZE; 
	            flags |= THREAD_FLAG_DEBUG_STACK_BOUNDS_CHECK; 
	        } 
	        t->stack = malloc(stack_size); 
	        if (!t->stack) { 
	            if (flags & THREAD_FLAG_FREE_STRUCT) 
	                free(t); 
	            return NULL; 
	        } 
	        flags |= THREAD_FLAG_FREE_STACK; 
	        if (THREAD_STACK_BOUNDS_CHECK) { 
	            memset(t->stack, STACK_DEBUG_BYTE, THREAD_STACK_PADDING_SIZE); 
	        } 
	    } else { 
	        t->stack = stack; 
	    } 
  
	#if __has_feature(safe_stack) 
	    if (!unsafe_stack) { 
	        DEBUG_ASSERT(!stack); 
	        DEBUG_ASSERT(flags & THREAD_FLAG_FREE_STACK); 
	        t->unsafe_stack = malloc(stack_size); 
	        if (!t->unsafe_stack) { 
	            free(t->stack); 
	            if (flags & THREAD_FLAG_FREE_STRUCT) 
	                free(t); 
	            return NULL; 
	        } 
	        if (THREAD_STACK_BOUNDS_CHECK) { 
	            memset(t->unsafe_stack, STACK_DEBUG_BYTE, THREAD_STACK_PADDING_SIZE); 
	        } 
	    } else { 
	        DEBUG_ASSERT(stack); 
	        t->unsafe_stack = unsafe_stack; 
	    } 
	#else 
	    DEBUG_ASSERT(!unsafe_stack); 
	#endif 
  
	    t->stack_size = stack_size; 
  
	    /* save whether or not we need to free the thread struct and/or stack */ 
	    t->flags = flags; 
  
	    if (likely(alt_trampoline == NULL)) { 
	        alt_trampoline = initial_thread_func; 
	    } 
  
	    /* set up the initial stack frame */ 
	    arch_thread_initialize(t, (vaddr_t)alt_trampoline); 
  
	    /* add it to the global thread list */ 
	    THREAD_LOCK(state); 
	    list_add_head(&thread_list, &t->thread_list_node); 
	    THREAD_UNLOCK(state); 
  
	    kcounter_add(thread_create_count, 1u); 
	    return t; 
	}


Pour les uns, ces décisions ne se justifient pas pour plusieurs raisons. Primo, elles ne respectent pas les canons de développement de ce type de noyau. « Je me serais attendu à ce qu’ils respectent les propriétés des microkernel connues depuis les années ’90 : pas d’allocation dynamique de mémoire au sein du noyau – toute la mémoire requise est allouée au démarrage », lit-on. Secundo, l’allocation dynamique de mémoire est susceptible de rendre le noyau du système d’exploitation perméable à des attaques par déni de service. Enfin, l’implémentation des exceptions est susceptible de le rendre plus lent et gourmand en ressource mémoire.

L’allocation dynamique de mémoire est cependant susceptible d’avoir des avantages dans le contexte du développement d’un microkernel pour une autre tranche d’intervenants reddit. « Il faut de la mémoire pour contenir les métadonnées relatives à un processus. Il en faut pour gérer les ressources liées aux autres services. Le passage de données entre ces services requiert également de la mémoire », lit-on en guise de réponse à la question sur l’utilité d’un gestionnaire de mémoire au sein d’un microkernel. Ce groupe d’intervenants reddit est également d’avis que Google a opté pour C++ en raison de la disponibilité de bibliothèques de type, ainsi que pour son typage plus poussé que le C, toutes choses qui peuvent également permettre une gestion efficiente des exceptions.

Sources

Google Git

Reddit

Et vous ?

Quelles raisons selon vous devraient motiver un développeur à choisir le langage C++ plutôt que le C dans le cadre du développement d’un noyau de système d’exploitation ?

Quel commentaire faites-vous de la décision de Google de faire usage du langage C++ au détriment du C pour coder le noyau de ce système d’exploitation ?

L’implémentation de l’allocation dynamique de mémoire et des exceptions a-t-elle sa place au sein d’un microkernel ? Si oui, quelle serait la façon la plus efficiente de la mettre en œuvre ?

Avez-vous déjà eu à choisir entre les langages C et C++ dans le cadre du développement d'un noyau ? Partagez votre expérience

Voir aussi

Fuchsia : le nouvel OS mystérieux de Google se concrétise en images, il serait destiné aux téléphones et aux ordinateurs personnels modernes
Avatar de vayel vayel - Inactif https://www.developpez.com
le 13/04/2018 à 9:23
on peut faire un kernel avec quasi n'importe quel langage...
Il y'a forcément la partie boot de coder en assembleur (x86,arm,sparc...) mais le reste peut être fait en C,C++,Python...

Je m’étais amuser a faire un noyaux en python en partant de la base Pépin et en virant le maximum de code c par du python

un excellent tutoriel pour créer son propre OS, c'est même potentiellement le seul qui soit aussi accessible (n'importe quel débutant en herbe peut créer son OS avec)
http://a.michelizza.free.fr/pmwiki.p...=TutoOS.TutoOS
et en plus il est français sans faute d'orthographe, que demander de plus

Le choix entre C/C++ est un faux débat, le plus intéressant c'est allocation statique ou dynamique.

Pour ma part j'opterais pour du tous dynamique, j'aime les structures flexible comme les listes doublement chainé par exemple plus pratique qu'un tableau statique.
L’avantage je dirais c'est moins de bug donc moins "d'écrans bleu", surtout si il font des try catch pass qui est préférable si on cherche la stabilité à un exit 1

Concernant l'aspect consommation mémoire/cpu on est en 2018, même l'embarqué le plus modeste aujourd'hui peut faire tourner du java...
Quand je vois les smartphones sortir avec 8GB de ram, je pense que c'est une problématique du passé
Avatar de stef-13013 stef-13013 - Membre habitué https://www.developpez.com
le 13/04/2018 à 9:24
Bon la, en même temps, si on regarde rapidement juste la portion de code du post, cela ressemble plus à du "C++ as better C"
qu'à du C++ pur et dur (classes, template, STL, ...)

Pourquoi pas...
Avatar de archqt archqt - Membre averti https://www.developpez.com
le 13/04/2018 à 10:02
Bonjour,
le C++ tiend la route en embarqué, je ne vois donc pas le soucis à l'utiliser. Après les exceptions et la gestion mémoire à voir, mais cela sera plus sécurisant au niveau gestion que la même chose en C.
Bonne journée
Avatar de - https://www.developpez.com
le 13/04/2018 à 10:40
Si à partir d'une modélisation, UML ou merise ou ALM ou autres il est possible d'obtenir du code source C et C++ quelques soit la complexité "objet/code.source" de celui, alors je veux bien croire qu'il y aura une égalité voir même au moins une équivalence de code source...

Sachant que le compilateur est souvent le même, au stade d'équivalent, le résultat au linkage devrait donc être le même...
Avatar de robertledoux robertledoux - Membre habitué https://www.developpez.com
le 13/04/2018 à 10:52
Du "void" pour éviter que la fonction ne prenne une infinité d'argument (chose qui n'est pas nécessaire en C++), du "malloc" pour allouer de la mémoire, utilisation de structures, pas de pointeur sur fonction dans les structures, ... bref c'est clairement du C et même pas du C objet. Pas de débat possible la dessus.

Par contre, oui la partie allocation dynamique est intéressante et c'est une approche plutôt sexy de la chose, à voir ce que ça donne sur des systèmes embarqués "anémiques" en terme de puissance.
Avatar de - https://www.developpez.com
le 13/04/2018 à 11:01
Citation Envoyé par Patrick Ruiz Voir le message
[...] ordiphones [...]
Jipété !!!
Contacter le responsable de la rubrique Accueil