depot: update recipe hashes

Without this patch, the text area would mistakenly delete the characters
types after placing the cursor with the mouse as soon as shift is used
as modifier.

VERSION

@@ -1 +1 @@
-19.05
+20.02

depot/cnuke/pubkey

@@ -12,19 +12,19 @@ sCaRvwPZdRCDDdhObkgkMlYROVNdC7ju8jZmB4n5O/5N7Ll7/RVhUWD7KeJu1UTM
 oNEmhxEMrEcYcHFt8N8YVtJleRMVnsrZBNxOkFnpsPZr02XIQKfYi5tqSaBQZ47h
 TTtXP3+FEaU+EoJprWqH55Sh97Fg6vuBJEmcGJeMGudFrypTzwqnM22DHwARAQAB
 tCdKb3NlZiBTw7ZudGdlbiA8Y251a2VAZGVwb3QuZ2Vub2RlLm9yZz6JAlQEEwEI
-AD4WIQSFq6G0496kOfRE2qnpSz5BlOa1+AUCWpAOsgIbAwUJA8JnAAULCQgHAgYV
-CAkKCwIEFgIDAQIeAQIXgAAKCRDpSz5BlOa1+NGTEACg69FezAbc9Rzeb7j66NwW
-3x/Zpi/jbmezMEtCZqAOcR8HJ7C0DN8gmCWPPB6oxAEeyL/i2cUb+9F0fTD6N7OL
-TSOH75mNlyB9b8D2HdDILnLy4ClEitEOHFLMnlP58PGVtUNgbmsiM6cLLQtlJKvg
-1xHlBTG9Ic8qgBcd808lLSC1XWN+nufVYBTE2RHNZqGeIWqPG5z1eW/JJO4M3V3j
-MAw1p5Rpf9G6iWNxURutQOl/ii+97IKmHXX7N6ZRzawMGkOCAGNk1xeI71wCrALv
-i3m7NmXb6XIJjD88hO5xfjjRO/0Gcw3vdmTXcVNzM1TvWj8ZsU6XjnMvNxa4LHqh
-MxWuHlX0cAeCOzo1LJZ54f13hJ3YlTCrv68UIoNGRVi1LEbpE0sU0Ycdbw7ur2Gt
-8Brx5WXv3hXTL8s3fmJzYU3/cFDfXjnaRiMWcNYdvckdHy6R7zPTk1NOvmfkolnO
-W73ivdbonXpn0YqRGo2L76GdahLaVYn2gEeisqHnyeBCvI2snI+dMlEK0YNFrEkP
-wgtWnF131Oorn0HMS6mpjcq4su4s5d84KCMGevFnW69oBRG27Bk/fJQiv2dSqkZg
-+3TnyNApg1G7Bp5uD83mOvJWKdTWAntCJSQGbg1dmEsOBG+Bu7EE5LVBoMH3h/LQ
-GB7c5NpgNIFQ2DZy2vkOI7kCDQRakA6yARAAws48PKN3BQPEM0M4kTO57/OqwGrA
+AD4CGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AWIQSFq6G0496kOfRE2qnpSz5B
+lOa1+AUCXk6dFAUJB4D1YgAKCRDpSz5BlOa1+JHXEACyB6vfzfuyo8fu1IaGrloC
+qUUuSfhdleF1tPhZQn9W92bEEoXPfqFUuiNaxeFIXonyiD7wJYdcowdIb6CiNWrx
+B8yjDQ7yb08sDLlL821I93kByy24Er5hY3QEMuEL3qv8YD/6Bh36Q0aoTXqQXMuQ
+3AcHp0JI932Oez3q+gEdW7CUe40N9LaTx0A7ZTHe0i8IELkUPFtDg8xibOjZhBMR
+vlxNUtzQVvC5kT5Wt0w6ZFKPGJguFylaE+TcsTNtiLNS4Z8PmRPgygrWotmprELo
+2/py/VMxgQb7p4LFj+sNmU9x3ulFO3Efb9cVZVjBMYx5xh83ZiLZ3PvK43Eo+7nm
+kYQhPinAjNmqng4/ZdQFrayFMkZc4oKCqV6BaYnybbsSn2ZEwVQqpDMeswWXTf9k
+qC6DONz3ETtyzBEF8cHDpy+BwHRXx+pysGLhIvHS9C3M91j8oXvogZRbw/dEKGX2
+eWes7nsdHeTbyRJunCCnsXDm0Js8cZcqj3Eu3Kpeu2CbgJGD+ajOel2RSMo2mFtg
+OoRWjCibWHDSeUS+LGtspDpry+4VYwm4KBdcyEgiXnE8WDb/xk/hZgJCr2814AJC
+RPpXoIZdFiwSP46vgoAnHynPbGTmE/Wt+F9Y2cn/dz6rmg5ynS8AKuTOUSoAKEUV
+J20mBJpkSx7Cc95AGE8K/LkCDQRakA6yARAAws48PKN3BQPEM0M4kTO57/OqwGrA
 AMlxnB3n+AP7rtZEC2L548+3pfg7Ub45Oq1X0ySxgPhV15CDUEK69pgs0JhphMbM
 DyaUp04DyQWFhdueAqQVFnKvg6nZm/WIJF1VYEc0/q6Ramsdv2cWdxFBkFHYsH3P
 G2bXCZZAEO6eJI8cdmBH6+bVptky/AybzBLztp1ruWlj+rm79qULmW7zJfxYwL1U
@@ -35,18 +35,18 @@ kAVN0Y0H9EGSEoVyKwS1DErzcBgajPKWedKlmjU1uIzupRWn5oqetVbNfZ3Z/EJ/
 HdMCX0PN1kxg4WoI9mkP/moly1yopVOTTLJwvC2C85NQUmxyZeb4h9O7toFczBxn
 7pV9Eprm/xRcO3ZEEpmdM7gR3+R3PpxkjgPIZAn9il32VYzdT3eQmDZ8sKC0qASG
 ik2if34YnAggGmsrVB0nzT9fZR7CQq2IR7eohczLJRl+n7USQMgRweF+sl9PcbDT
-aC0b0i+VveSEBOEAEQEAAYkCPAQYAQgAJhYhBIWrobTj3qQ59ETaqelLPkGU5rX4
-BQJakA6yAhsMBQkDwmcAAAoJEOlLPkGU5rX4QjEQAIJF78XjvGomhafMsWlcd7fP
-/j45B+KIpyruc7wHtLqWibi+YoDuvtG4m1/4Ckcz5qNrV0f5nQojEAeCSCh7Sl+s
-yAJ9tmP1XET29DJq1t0iMsu+RDCLhdOfL/Wi/YJARtDloYbDlD8Rc/JnL2aOx2W/
-Ybajj2lloxSDxKCnzCh1aZixie1YaQSm8ErshT2k4qTx48D3mRoBLAYyzdEbLkl3
-ZBGDQy3Xk/miJ/hsj6L3w3G2YjMywZZZEjgDSUgSJ6MazBTgMmbCy1/0YGh7rNF7
-iUoWyDZq4qiDGNAI695I6tas7s4X2dhZn10xgbJoa5Dq2rqQLek+ErEsr3DFYN53
-7e9H0vJ9ydXB7piRJ9bxVFBng5CX9677IN5k9T/0lvcZWAFnDcHiMkIjIrTQ1Y04
-WkG6DMVvzLD+PKA07cZLf692rsrbfpP4sGj8X6baWh58mGAMMwZ2Dy07grsi73qI
-p/H4r4c/xRsH6nTbvb40zLfqcCz1xOTEcDtflYGMoeshu/H2EoruNMFi3c/9WO2G
-3zrSOUenWFSiacbsh8HVE9HUFGddBTB3SrLddO5vvvi15OvGI4aWpnkW+9s4107h
-jE0d0+c/Xm4AS0T59OGj/cd45k/vRe5vaPhQobZ6hXBzkKWPVt5uH8xbROiGiqdR
-jMuaeWIldeJ60aeu39Dh
-=JE0L
+aC0b0i+VveSEBOEAEQEAAYkCPAQYAQgAJgIbDBYhBIWrobTj3qQ59ETaqelLPkGU
+5rX4BQJeTp05BQkHgPWHAAoJEOlLPkGU5rX4RRAQAKSsr//mEXy6iQyoqaxJ796s
+ljaoqsmT4ly/+0k9diX1+/wkulSkj4/fL2fDvRQK2cU1i6mYJVugN5swqXvp8WF8
+scnDS/H75v/3Z+clTlsMjZ4qI0PmXYDpcvp5+zU85USEjOxpHmIKvQGflZ0NMvkI
+uo2ZC6F4xnB5iizx9Ebm0gGAiKKEJ8ID/LLhJmOtidnGc3322SUVXIl4+ue9KgpO
+hTBjx5UdIQ+21uSRf+zv3ZQH/KA/08iNyD20fIiUZKfEoeovlW8SipoO/pf/+1DE
+WSiJqL3K7T3ixkC4oWSp7tbo2MWU247PItxTnnGF+KjwbkzpPwyPYPHT5Ed3XEZV
+e39r9xUzdvYKKDCNDToDFsh4bm4hq7xXgnTwAbF6hw0iyBK02ZB6FKJsF/ZJi8gC
+Ni4d3Lb54CV/Z7nAqMFbTa6KT8o9fc0Bw6tgX2ch7SRWU70yVGYmQzrdRsOtDkIV
+iYA05JozwwsIcJQS7hBVnsqgD/huYLd+y7iCUgw35NdQ5764jzVlUpYtFO0NFrM6
+QSKnnFFRiwr3+ZqIja2SGW455uP1hsl2ccA4Rdp/JRuEI6ojIo0R+JBpcMeqdv9d
+HcNsAoZkrm/cQfIwlyKsU4/dEFL09kEtv7x/aO2ImqjAZ5xT3ml+4kFGEn7M7rsc
+M6R6fgkYrVo1GhjXTlCL
+=4bj4
 -----END PGP PUBLIC KEY BLOCK-----

depot/mstein/download

@@ -0,0 +1 @@
+https://depot.genode.org

depot/mstein/pubkey

@@ -0,0 +1,51 @@
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+
+mQINBFuhfGYBEADOj0EW/U2O3koeGIuNGDuBDSzkYjncoBrrPN1z69hgK349xiP7
+ZwrPBA0kJ3ctLcRQcOEDF5XJzjByuNk3JV6MuKFqwy2i9dDTHkv5pv7Na/R3L2CM
+k79weVahjPllt9nnbSMMtYH0eL187EhLW9owd0CY9wDj1lhLISHpyKvb9vwiUAwQ
+i+xypGgU+Qvf8BmfTDdjfP0n+Iw31z+R3xiHhWmhrs9gID2XVtGZIy9NQQrijJYS
+1Hp8hjgH9Fzmj0GkxUI+2mEqLeEp6wBmmo+7PRzc+iRYJNocyRxDbmdE0eyh3P93
+QABzZiWTU+Feq0MYa1FK55uFCFHe6MSFLq33CGYMzQ9oFQHjuEX1KqJT/OoumPgN
+iEb8Bt3XmqiI8GejafLKIW8gO8tYLABdrEpFelnyXy12IIOpOwb8GrxFUEu8+bDb
+Fc0YkV7cZ4NH2Kq/6/Or30gCA2XUpqhDNSxA6jer35a3ZzvgXvcRkNR/oOt+qt/3
+u9ew+e6Xjque0PRWzdavVlKdYWzSV8umVw5DGgQj/rSn+8spog/5w1lElyUa/5Yx
+Z+1bvOIyXPg+tTLimWtGRZQorak1sMsLMDqQck9SwOQWpSmVGsJ14uWXSMaZjdj9
+4rHSSymYlcQWP8t9lfPf6/ZSH8574PbbJSe71UXcWWznSGprSt2QQAQ7NwARAQAB
+tCtNYXJ0aW4gU3RlaW4gPG1hcnRpbi5zdGVpbkBnZW5vZGUtbGFicy5jb20+iQI+
+BBMBAgAoBQJboXxmAhsDBQkDwmcABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAK
+CRDJZVRAR8NPkiTSD/9xiUVNgKTkmH9WRdCcaHuyhKoQI6CsWnMOW5OZ+gVXPc9U
+LapQ5Wymb+yGE8Uyn4EJnwdEa8TdWztMs3TNtK5vh1Pk1lKmtKcblBiDrUPEURhR
+mUBoUkMe2VDXyN27e0lkbxcFJ0HrYnhvb72Yfnw6B3XMa/NIhbOU3ttB/tVR6Kjl
+YVDtTokfILQc07Ai+TqkqNARtPGntHAn9qFvPLNKI31c+Xw/QGZbVPNFW1QAYBiO
+5dqsSwKaouapHAb0GBmU0fAfJZNcvwt9Ph7WDXU9Ce3LZmIshGW7Gzm7EGdf4VS6
+k4OtEWZhZHRnl9/sBJ2UlQU0tFs3ow53aDZQIa4FKd4JKabBeRgDUKCGEyfoNKCq
+NKkLZaR/kFA9EqTPZSIXPLYIzIlSFoL3LVDOc5O7hDT9vXaubdZeAfE9VcHDdm3u
+usW034F0zbsuu4G83qZ6QhDOp0UhujfSU+BDkH0I+OfFyVkQAmy69J3byi7Iluno
+OcZM13rbe30jzyyyWAnjHicAt8tNwCLMmnIRvYT9ELqywID0Zzxkct61eJQ6L6aq
+/DnUD9Kq0OwdxC1wMGtimX5eUnN7S7y5+TMRepJnWcTtgrLBVqwRrvSLnsKVd4Gb
+Bu3dSs+BxMV1UcyU0KWwDPY2D7k8SGgeH7IEPo/JiGO8RrWYJRac9qel9egMYbkC
+DQRboXxmARAAoaRH/xgKvp0QrNFJZBW12SdXT4h1nXglbpZd+bUl738LqM2JSIC5
+Qq7t2DUtOiL9UxqvRgAIjkVLR+hHJBZyuPOP5Ebaf3Mr7eAdmCx2TMsHZPKBLnTy
+EqeUcnPwThNKcUaGsQYlkxIQAJtPzy3YBuDCYnzzSi6KzP3VC8szHsXcPo2DeKWI
+m9BbMMSQkB3m0fz8W3ar/64RDoubRWRJ07b7q4WUb4jPvql+Tz+Gv5x3qm8g6m1j
+uD+U5OhGCe3m5/MsI2JYdWXEwif8YD59gylsj3LJIu3i4SkR8aS+x6n3LIvdSCOt
+P3To87wfoSqBWWObVe/vOHRXqpzEF6T/ih/rkhUFzrHNMziTPsujBazm82AUZ6xi
+2TddbdSAK+ZpSPQjyyRflNyNgv0iu6P3BnBgv0Xcuf2RsDMBDjdvHtX0lXkPMB+r
+6jgxl0faV6UktH5R2d4Zt9i0/vWlZZd0MDylPNQDiKs+qSIX3ntfUUaPdEJqYAwM
+gloXr3cZtsVh+Yoqt8pa4x0x6kqez+oyBUFf6y1FCKYq2H/QfPRkF/DrfZS+7jXW
+iAX8PcrDceCN6Dr10/g5LPWXQOHUWxCu7FEYoYJsVXst4N0FnCOCe/OGYIhMteSV
+IJJvNS4qwXZKKZ+cmuT9skEQ6zsLV9+VDYMwVqXB4wTp4EwT2pCp6LEAEQEAAYkC
+JQQYAQIADwUCW6F8ZgIbDAUJA8JnAAAKCRDJZVRAR8NPktRiD/9qjH6uuT1y5uNA
+4E8u6/vxZGsyBG57dtnQ0KQbcsZSrUxMiDTtMMrklsl2vtut/XDroajm+d2eaQ4K
+j0h285VRkT5xJ79JaIQ8oyzRWBtpENy0iLUm7CmqCMuH8VFifZyEBYZgR/K+9ago
+WwF3sk0QP0WJTFqIZajKK0Lo5Juk8DCXjvtkvGNytHkZ2vEkiZ9m7Eq0AjQnts5T
+PdHkob7Z8fu0KfUMoCUtb+TzNyMYOVGE6uTfo8wKvbhwzUWSymZkrecx73XUUmew
+MdZ2WzwGdUMXwcBZ4LvgrZVg+LKxR1lyJ+qbIUpDKXCZGGH2VZVaQspgnx2Yt0EI
+Zl2ELMrTq5IcOkxtblEZpQkwaXszqUDNO43ezp/PmbTRWChoM/k3RAbp9rvoYx93
+UChyRXpJRaqDxK502k3BSnOfmolpQvxTMKtLZO50URa0F0F4qD2csns4QrqOWsGr
+qPqVKcLn8Q/yMW9fm5+xX+ZHICKk64GAB0YyHcw9lOWekLhGzZV1KnD5ID6+5E0B
+nsWZB6PDqLM+/ykXh0rcN8DWwZvhimI5/dOEIWIkADKT8WGwh+2JnRyimhxYdaiH
+ul1BvZAYqF1FVXAHd0u48MssLywGGbW4fH8D9SM+LFpP4+8oYFLNgH1OreMENuag
+i47EaxpnQUgIt8PZ/gL3LeiGs8SNpw==
+=flyM
+-----END PGP PUBLIC KEY BLOCK-----

depot/skalk/pubkey

@@ -6,26 +6,26 @@ spm0DdNCEVfUbIQUstbSNt1kDGIlqPvZmoRj5YwDECW6ULG8jTWhaAz9SybJCE86
 jLPzZHjKtVhCVO1X0ogSxvvYGemUpqVCLfKcIb1TucieKKCrnjiHwp0XZ41DWqSb
 kBwWW2YQMEsw8JNGNTfCCUFf6+1l4mMixtv2sEqFiH1wQJ0c4gSa4iSYZ+eNmzJ0
 B13K8kONOctSg3NYZz/dC1aUzLOTkgJHqEPHABEBAAG0KVN0ZWZhbiBLYWxrb3dz
-a2kgPHNrYWxrQGRlcG90Lmdlbm9kZS5vcmc+iQFUBBMBCAA+FiEEI2X1/oP+p+Ls
-2L28qrC4CLnp/P8FAlrQZGACGwMFCQPCZwAFCwkIBwIGFQgJCgsCBBYCAwECHgEC
-F4AACgkQqrC4CLnp/P9kKQgAxc11eDhYkMVg9cuipFoqtV5lY9aT2qkocZ28IhbF
-LXhy9lcn5FlxZSVdkzJQ5tUf4nSuhhMb6z3r8edaOebcYAyFk0DTymNpcEyT2XHd
-lsOcInhfU423m1tCNHdmxtv9HERtj2zS1KNkjWxY6xsqfEw1eDfUvdS3K9KpUqc6
-vWZwsPd9EHxW3mzWJS3lrSAnNsCwtdmiqB9045Yss4KednMcN6qxE+uHppQ+25Ib
-5ZICpiVqOJ+eQXeY3kRx84lfZJr3uFdn00RSU5fn0uol8ZZYX9tQd9SC1GIlkyYj
-HxNLKNVaYzF1nnmR1s7cpY6PUAYbt0im6kd4VJ1wQcWTnrkBDQRaU+QuAQgAuame
+a2kgPHNrYWxrQGRlcG90Lmdlbm9kZS5vcmc+iQFUBBMBCAA+AhsDBQsJCAcCBhUI
+CQoLAgQWAgMBAh4BAheAFiEEI2X1/oP+p+Ls2L28qrC4CLnp/P8FAl4XHPUFCQ0p
+OkcACgkQqrC4CLnp/P8bAgf/ToUKzXMGdRXpB+xIBbOxuu8xVdLRj+5cm7cjZRiy
+N0ulrzAlaZqrfqb5rTujPDjakmVSBVRIi8zWlzU7y67fevTFdi/Q9xeLgbqP3cWU
+UgUJs03cdacFIamSIO//I9gaImZ2kpUcA6Nj+N+jPepRgUBzljsJG8678ndicA0e
+Yio4uAvZY9JmsWGn48rmkqshPf9lag4GUnXn+R/AFKCts55kOiPekux3pJBhmrLJ
+TdLgdAzlzGQfHxQbz3oVK4yE19ReAd6rnpW06oK4KfiWrgCmaEk1quirDNfIMDfr
+nwe6571TY5is0f9zJjJgP8ogLUMI3n54OvwMezUMz+bLbbkBDQRaU+QuAQgAuame
 2VDCgNmiwu+QmWyNN4jzbE7+VNmDr37HO9lZRIROC4eACPOGfUL03jLGvUn7rrxQ
 JK+Pit6gXXCoIWDhCMNRSZKho416KJZWxF2jxKBKGQ7DtWaTR3YOzSf0ka9DZSrp
 wG22xS0Uf1U/0ZBIf24LbyUDFLc8zt4eey2D9AHm+9vCf7wnf8TV6SNIXRz3wj7d
 VqoZLXRTT7twBSaNahLhNtg7fhS8Nu6/THuwXpNKPAvAsgJRTGk7kmrKj5P7rOZA
 rNHC1pvK1EWJJi2onHOmCzBccKRp9SeQlj+ddqG6seZhEnRYG6l7uhkyNZoyvKxO
-Fguc5g8Xf37VyuRMfwARAQABiQE8BBgBCAAmFiEEI2X1/oP+p+Ls2L28qrC4CLnp
-/P8FAlpT5C4CGwwFCQPCZwAACgkQqrC4CLnp/P/IOAf+LnQVtU7aHh4AZDsi1wXq
-KBo5l6r3G8tC/S0HEf8nnWMUio2/mwVrkbuTvBeKrcQ/mXFHHAG8YCAIHPgR7T0y
-2L6l2PL4HoXiLD8EwJ0sWZu2waxuxcTX+bb1i3Xm3squnqDtCX3pyoXWx0GVgrz9
-7I/zitxeER+35ScaZ+JAAcNW59LpiV1SdIXqbtrw5QBJBuZUp0bvnzCNvdZLhnhb
-gWfwPEfcXFt5K87iTmfMFJOJpbUrEz/NWE9gOBCBjqxW0wVb+IWr0oFWvfxjuBq7
-IW9DezwkN1wAavP6g7+B4esCD6SRq+3CCzbT1By3X2h3SevU8tHkCSA3cIKgWdyD
-2A==
-=IsaH
+Fguc5g8Xf37VyuRMfwARAQABiQE8BBgBCAAmAhsMFiEEI2X1/oP+p+Ls2L28qrC4
+CLnp/P8FAl4XHW4FCQ0pOsAACgkQqrC4CLnp/P/xGggAhMz6NH1dYiFtc9+3vkAW
+bZ10MDvxdgyU+G1a0BVYVo2ZXkhJlb2yg5MEeL1MZ6cUtM7MR1OL0U1jayfdcTfr
+kkUi2a35BdvKRpxc3hcc4i2CdDxdx+IGrBa75P+vIKFj8WIvwABgRJNVzY1Oq6Lq
+zKPUpVPug80Hch++Kv6l1DEpcoXlGaI8Z1dWfAjYQ7HJF/YJNHloKwxa1mXo/l/S
+qQSFHB23IN682ANm8iEUphuvJVbOw4mubpCEpmJvIhEBeesgXfB503nniOsshq+9
+1bNZ3CFv/ylnj5sy5VzU0lfW/TrHiW4OOOSbX8mCSvcqN2mhjcu6r4olV0fWPrrV
+Lg==
+=H+8g
 -----END PGP PUBLIC KEY BLOCK-----

doc/challenges.txt

@@ -16,17 +16,6 @@ research projects on Genode.
 Applications and library infrastructure
 #######################################
 
-:GNU Privacy Guard:
-
-  The [https://gnupg.org/ - GNU Privacy Guard] (GNUPG) is the most widely
-  used Free-Software implementation of the OpenGPG standard. It comprises a
-  rich set of tools for encryption and key management. For many forthcoming
-  application scenarios of Genode such as package management and email
-  communication, GNUPG is crucial. Hence, it should be ported to Genode. Such
-  a port may leverage Genode's fine-grained component architecture to strongly
-  separate network-exposed functionality, the storage of key material, and the
-  cryptographic functions.
-
 :VNC server implementing Genode's framebuffer session interface:
 
   With 'Input' and 'Framebuffer', Genode provides two low-level interfaces
@@ -50,24 +39,6 @@ Applications and library infrastructure
   integrated in the operating system, i.e., in the form of Genode components
   or a set of Genode VFS plugins.
 
-:Tiled window manager:
-
-  At Genode Labs, we pursue the goal to shape Genode into an general-purpose
-  operating system suitable for productive work. The feature set needed to
-  achieve this goal largely depends on the tools and applications daily used by
-  the Genode engineers. As one particularly important tool for being highly
-  productive, we identified a tiled user interface. Currently, all developers
-  at Genode Labs embrace either the Ion3 window manager or the tiled Terminator
-  terminal emulator. Hence, we desire to have a similar mode of user
-  interaction on Genode as well. The goal of this challenge is to identify the
-  most important usage patters and the implementation of a tiled GUI that
-  multiplexes the framebuffer into a set of tiled and tabbed virtual
-  framebuffers.
-
-  Related to this work, the low-level 'Framebuffer' and 'Input' interfaces
-  should be subject to a revision, for example for enabling the flexible change
-  of framebuffer sizes as needed by a tiled user interface.
-
 :Interactive sound switchbox based on Genode's Audio_out session interface:
 
   Since version 10.05, Genode features a highly flexible configuration concept
@@ -116,6 +87,11 @@ Applications and library infrastructure
   of communicating threads as captured on the running system. The tool should
   work on a selected kernel that provides a facility for tracing IPC messages.
 
+  The underlying light-weight tracing infrastructure is
+  [https://genode.org/documentation/release-notes/19.08#Tracinghttps://genode.org/documentation/release-notes/19.08#Tracing - already in place].
+  The Qt-based tracing tools would complement this infrastructure with
+  an interactive front end.
+
 :Ports of popular software:
 
   Genode features a ports mechanism to cleanly integrate 3rd-party software.
@@ -127,6 +103,18 @@ Applications and library infrastructure
   have available on Genode is available at
   [http://usr.sysret.de/jws/genode/porting_wishlist.html].
 
+:Native Open-Street-Maps (OSM) client:
+
+  When using Sculpt OS, we regularly need to spawn a fully fledged web
+  browser in a virtual machine for using OSM or Google maps. The goal
+  of this project would be a native component that makes maps functionality
+  directly available on Genode, alleviating the urge to reach for a SaaS
+  product. The work would include a review of existing OSM clients regarding
+  their feature sets and the feasibility of porting them to Genode.
+  Depending on the outcome of this review, an existing application could
+  be ported or a new component could be developed, e.g., leveraging Genode's
+  Qt support.
+
 
 Application frameworks and runtime environments
 ###############################################
@@ -135,18 +123,18 @@ Application frameworks and runtime environments
 
   [http://openjdk.java.net/ - OpenJDK] is the reference implementation of the
   Java programming language and hosts an enormous ecosystem of application
-  software. The goal of this line of work is the ability to run this
-  software directly on Genode. The centerpiece of OpenJDK is Hotspot - the
-  Java virtual machine implementation, which must be ported to Genode.
-  The initial port should suffice to execute simple example programs that
-  operate on textual input. Since Genode has the FreeBSD libc readily
-  available, OpenJDK's existing POSIX backends can be reused. The next step
-  is the creation of Genode-specific native classes that bridge the gap
-  between the Java world and Genode, in particular the glue code to
-  run graphical applications as clients of Genode's GUI server. Since
-  OpenJDK has been ported to numerous platforms (such as Haiku), there
-  exists a comforting number of implementations that can be taken as
-  reference.
+  software.
+
+  Since
+  [https://genode.org/documentation/release-notes/19.02#Showcase_of_a_Java-based_network_appliance - version 19.02], 
+  Genode features a port of OpenJDK that allows the use of Java for networking
+  applications.
+
+  The next step would be the creation of Genode-specific native classes that
+  bridge the gap between the Java world and Genode, in particular the glue
+  code to run graphical applications as clients of Genode's GUI server. Since
+  OpenJDK has been ported to numerous platforms (such as Haiku), there exists
+  a comforting number of implementations that can be taken as reference.
 
 :Android's ART VM natively on Genode:
 
@@ -155,22 +143,6 @@ Application frameworks and runtime environments
   removed from the trusted computing base of Android, facilitating the use of
   this mobile OS in high-assurance settings.
 
-:Rust bindings for the Genode API:
-
-  Rust is a low-level systems programming language that ensures memory
-  safety without employing a garbage collector. It thereby challenges C++
-  as the go-to programming language for high-performance and low-level code.
-  Since
-  [http://genode.org/documentation/release-notes/16.05#New_support_for_the_Rust_programming_language - version 16.05],
-  Genode supports the use of the Rust programming language within
-  components. However, to unleash the potential of this combination,
-  Genode's API must become available to native Rust code. The intermediate goal
-  of this project is the implementation of an example server, e.g., a
-  component that provides a terminal-session interface. Thereby, we
-  will encounter the problems of bootstrapping and configuration of the
-  component, the provisioning of signal handlers and session objects, and
-  memory management.
-
 :Go language runtime:
 
   Go is a popular language in particular for web applications. In the past,
@@ -222,6 +194,33 @@ Application frameworks and runtime environments
   development is [http://halvm.org - HalVM] - a light-weight OS runtime for
   Xen that is based on Haskell.
 
+:Xlib compatibility:
+
+  Developments like Wayland notwithstanding, most application software on
+  GNU/Linux systems is built on top of the Xlib programming interface.
+  However, only a few parts of this wide interface are actually used today.
+  I.e., modern applications generally deal with pixel buffers instead of
+  relying on graphical drawing primitives of the X protocol. Hence, it seems
+  feasible to reimplement the most important parts of the Xlib interface to
+  target Genode's native GUI interfaces (nitpicker) directly. This would
+  allow us to port popular application software to Sculpt OS without
+  changing the application code.
+
+:Bump-in-the-wire components for visualizing session interfaces:
+
+  Genode's session interfaces bear the potential for monitoring and
+  visualizing their use by plugging a graphical application
+  in-between any two components. For example, by intercepting block
+  requests issued by a block-session client to a block-device driver,
+  such a bump-in-the-wire component could visualize
+  the access patterns of a block device. Similar ideas could be pursued for
+  other session interfaces, like the audio-out (sound visualization) or NIC
+  session (live visualization of network communication).
+
+  The visualization of system behavior would offer valuable insights,
+  e.g., new opportunities for optimization. But more importantly, they
+  would be extremely fun to play with.
+
 
 Virtualization
 ##############
@@ -237,21 +236,6 @@ Virtualization
   is normally not possible. Also, complex Genode scenarios (like Turmvilla)
   could be prototyped on GNU/Linux.
 
-:VirtualBox on top of seL4:
-
-  The [https://sel4.systems - seL4 microkernel] is a modern microkernel that
-  undergoes formal verification to prove the absence of bugs. Since version
-  4.0, the kernel supports virtualization support on x86-based hardware.
-  Genode has experimental support for seL4 that allows almost all Genode
-  components to be used on top of this kernel. VirtualBox is an exception
-  because it closely interacts with the underlying kernel (like NOVA) to
-  attain good performance. We have shown that VirtualBox can be executed
-  within a protection domain of the NOVA microhypervisor. The goal of this
-  project is the application of this approach to the virtualization
-  interface of seL4. The result will be a VM hosting environment that
-  ensures the separation of virtual machines via the formally verified
-  seL4 kernel.
-
 :Xen as kernel for Genode:
 
   Using Xen as kernel for Genode would clear the way to remove the
@@ -294,22 +278,25 @@ Virtualization
   the project bears the opportunity to explore the provisioning of the
   KVM interface based on Genode's VFS plugin concept.
 
+:Hardware-accelerated graphics for virtual machines:
+
+  In
+  [https://genode.org/documentation/release-notes/17.08#Hardware-accelerated_graphics_for_Intel_Gen-8_GPUs - Genode 17.08],
+  we introduced a GPU multiplexer for Intel Broadwell along with support
+  for Mesa-based 3D-accelerated applications.
+  While designing Genode's GPU-session interface, we also aimed at supporting
+  the hardware-accelerated graphics for Genode's virtual machine monitors like
+  VirtualBox or Seoul, but until now, we did not took the practical steps of
+  implementing a virtual GPU device model.
+
+  The goal of this project is the offering of a virtual GPU to a Linux guest
+  OS running on top of Genode's existing virtualization and driver
+  infrastructure.
+
 
 Device drivers
 ##############
 
-:Isochronous USB devices:
-
-  Genode's USB driver supports bulk and interrupt endpoints. Thereby, most
-  USB devices like USB storage, user input, printers, and networking devices
-  can be used. However, multi-media devices such as cameras or audio
-  equipment use isochronous endpoints, which are not supported. The goal
-  of this line of work is the support of these devices in Genode. The topic
-  touches the USB driver, the USB session interface, an example implementation
-  of a USB client driver (using the session interface) for a device of choice,
-  and - potentially - the enhancement of Genode's USB-pass-through mechanism
-  for VirtualBox.
-
 :Sound on the Raspberry Pi:
 
   The goal of this project is a component that uses the Raspberry Pi's
@@ -318,18 +305,6 @@ Device drivers
   backend, the new driver will make the sound of all SDL-based games
   available on the Raspberry Pi.
 
-:Framebuffer for UEFI and Coreboot:
-
-  By moving away from the legacy BIOS boot mechanism, it is time to
-  reconsider closely related traditional approaches such as the use of
-  the VESA BIOS extensions for accessing the frame buffer. On UEFI or
-  Coreboot systems, there exist alternative ways to initialize and
-  access the framebuffer in a hardware-independent way. On the course of
-  this project, we will explore the available options and create dedicated
-  Genode driver components that use the modern mechanisms.
-  For reference, the current state of Genode's UEFI support is documented
-  in [https://github.com/genodelabs/genode/issues/2242 - Issue 2242].
-
 :Data Plane Development Kit (DPDK):
 
   Genode utilizes the network device drivers of the iPXE project, which
@@ -357,8 +332,22 @@ Platforms
   Genode functionality such as its native GUI, lwIP, and Noux, many protocol
   stacks can effectively be removed from the Linux kernel.
 
-  The goal of this project is to evaluate how small the Linux kernel can get
-  when used as a microkernel.
+  In 2018, Johannes Kliemann pursued this topic to a state where Genode
+  could be used as init process atop a customized Linux kernel.
+  [https://lists.genode.org/pipermail/users/2018-May/006066.html - His work]
+  included the execution of Genode's regular device drivers for VESA and
+  PS/2 as regular Genode components so that Genode's interactive demo
+  scenario ran happily on a laptop. At this time, however, only parts of
+  his results were merged into Genode's mainline.
+
+  The goal of this project is to follow up on Johannes' work, bring the
+  [https://github.com/genodelabs/genode/pull/2829 - remaining parts] into
+  shape for the inclusion into Genode, and address outstanding topics, in
+  particular the handling of DMA by user-level device drivers. Further down
+  the road, it would be tempting to explore the use of
+  [https://en.wikipedia.org/wiki/Seccomp - seccomp] as sandboxing mechanism
+  for Genode on Linux and the improvement of the Linux-specific implementation
+  of Genode's object-capability model.
 
 :Support for the HelenOS/SPARTAN kernel:
 
@@ -381,34 +370,46 @@ Platforms
   kernel is used for Mac OS X, it could represent an industry-strength
   base platform for Genode supporting all CPU features as used by Mac OS X.
 
-:Linux process containers for supporting Genode`s resource trading:
+:Genode on the Librem5 phone hardware:
 
-  Even though the Linux version of Genode is primarily meant as a development
-  platform, there exist interesting opportunities to explore when combining
-  Genode with Linux, in particular Linux' process containers.
-  Linux process containers provide a mechanism to partition physical resources,
-  foremost CPU time, between Linux processes. This raises the interesting
-  question of whether this mechanism could be used for a proper implementation
-  of Genode's resource trading on Linux.
-  [http://lwn.net/Articles/236038/ - Process containers introduction...]
+  Even though there exists a great variety of ARM-based SoCs, Genode
+  primarily focuses on the NXP i.MX family because it is - in contrast
+  to most SoCs in the consumer space - very liberal in terms of
+  good-quality public documentation and reference code, and it scales
+  from industrial to end-user-facing use cases (multi-media).
+
+  The [https://puri.sm/products/librem-5/ - Librem5] project - with its
+  mission to build a trustworthy mobile phone - has chosen the i.MX family as
+  the basis for their product for likely the same reasons that attract us.
+
+  To goal of this work is bringing Genode to the Librem5 hardware.
+  For the Librem5 project, Genode could pave the ground towards new use cases
+  like high-security markets where a regular Linux-based OS would not be
+  accepted. For the Genode community, the Librem5 hardware could become an
+  attractive mobile platform for everyday use, similar to how we developers
+  use our Genode-based [https://genode.org/download/sculpt - Sculpt OS] on our
+  laptops.
+
+
+System management
+#################
+
+:Remote management of Sculpt OS via Puppet:
+
+  [https://en.wikipedia.org/wiki/Puppet_(company)#Puppet - Puppet] is a
+  software-configuration management tool for administering a large amount
+  of machines from one central place. Genode's
+  [https://genode.org/download/sculpt - Sculpt OS] lends itself to such
+  an approach of remote configuration management by the means of the
+  "config" file system (for configuring components and deployments) and
+  the "report" file system (for obtaining the runtime state of components).
+  The project would explore the application of the Puppet approach and tools
+  to Sculpt OS.
 
 
 Optimizations
 #############
 
-:Low-latency audio streaming:
-
-  Genode comes with an audio streaming interface called 'Audio_out' session.
-  It is based on a shared-memory packet stream accompanied with asynchronous
-  data-flow signals. For real-time audio processing involving chains of Genode
-  components, streams of audio data must be carried at low latency, imposing
-  constraints to buffer sizes and the modes of operation of the audio mixer and
-  audio drivers. The goal of this project is to create a holistic design of the
-  whole chain of audio processing, taking thread-scheduling into account. A
-  particular challenge is the mixed output of real-time (small buffer, low
-  latency) and non-real-time (larger buffer to compensate jitter, higher
-  latency) audio sources.
-
 :De-privileging the VESA graphics driver:
 
   The VESA graphics driver executes the graphics initialization code provided

doc/getting_started.txt

@@ -53,14 +53,15 @@ architecture independent from the underlying base platform, in this case Linux.
 To give Genode a try, build and execute a simple demo scenario via:
 
 ! cd build/x86_64
-! make KERNEL=linux run/demo
+! make KERNEL=linux BOARD=linux run/demo
 
 By invoking 'make' with the 'run/demo' argument, all components needed by the
 demo scenario are built and the demo is executed. This includes all components
 which are implicitly needed by the base platform. The base platform that the
-components will be executed upon on is selected via the 'KERNEL' variable. If
-you are interested in looking behind the scenes of the demo scenario, please
-refer to 'doc/build_system.txt' and the run script at 'os/run/demo.run'.
+components will be executed upon on is selected via the 'KERNEL' and 'BOARD'
+variables. If you are interested in looking behind the scenes of the demo
+scenario, please refer to 'doc/build_system.txt' and the run script at
+'os/run/demo.run'.
 
 
 Using platforms other than Linux
@@ -112,7 +113,7 @@ steps are required:
 # Uncomment the following line in 'x86_32/etc/build.conf'
   ! REPOSITORIES += $(GENODE_DIR)/repos/libports
 # Build and execute the demo using Qemu
-  ! make -C build/x86_32 KERNEL=okl4 run/demo
+  ! make -C build/x86_32 KERNEL=okl4 BOARD=pc run/demo
 
 The procedure works analogously for the other base platforms. You can, however,
 reuse the already created build directory and skip its creation step if the

doc/news.txt

@@ -4,6 +4,161 @@
                                ===========
 
 
+Genode OS Framework release 20.02 | 2020-02-28
+##############################################
+
+| With version 20.02, Genode makes Sculpt OS fit for running on i.MX 64-bit
+| ARM hardware, optimizes the performance throughout the entire software stack,
+| and takes the next evolutionary step of the user-facing side of Sculpt OS.
+
+Without any doubt, Sculpt OS has been the driving motivation behind most
+working topics featured by the new release. One particularly exciting line
+of work is the enabling of Sculpt on i.MX-based 64-bit ARM hardware, which
+touched the framework on all levels, from the boot loader, over the kernel,
+device drivers, libraries, system management, up to the application level.
+The work goes as far as supporting Sculpt OS as a hypervisor platform for
+hosting Linux in a virtual machine.
+
+As a second Sculpt-related development, we strive to make the user-visible
+side of the operating system better approachable and more logical. With this
+background, the current release comes with a profound redesign of the
+administrative user interface of Sculpt OS. An updated downloadable system
+image will follow soon.
+
+Also related to Sculpt are an updated audio driver based on OpenBSD 6.6,
+the support of virtual desktops, and performance optimization of the
+Seoul virtual machine monitor on x86 hardware.
+
+Regarding the framework API, the release introduces a new library for
+building multi-component applications. It aims to bring the benefits of
+Genode's unique security architecture from the operating-system level to the
+application level.
+
+These topics are only the tip of the iceberg. For the complete picture,
+please consult the
+[https:/documentation/release-notes/20.02 - release documentation of version 20.02...]
+
+
+Road Map for 2020 | 2020-01-20
+##############################
+
+| In 2019, we will be concerned about dwarfing the barrier of entry into
+| the Genode world.
+
+Following the last year's leitmotif of "bridging worlds", we turn our
+attention to the removal of the hurdles faced by aspiring developers and
+users. During the annual road-map
+[https://lists.genode.org/pipermail/users/2019-December/006987.html - discussion]
+on our mailing list, we identified four tangible approaches towards that
+goal. First, making Sculpt OS more user friendly. Second, reinforcing trust in
+Genode by fostering the framework's high quality. Third, making the tooling
+around Genode a joy to use. And finally, the illustration of Genode's
+versatility in the form practical use cases.
+
+Besides this overall theme, we plan to continue our commitment to the
+NXP i.MX SoC family, revisit Genode's low-latency audio support, and
+extend the cultivation of Ada/SPARK within (and on top of) Genode.
+
+More background information about the new road map and a rough schedule are
+presented at our official [https:/about/road-map - road-map page].
+
+
+Genode OS Framework release 19.11 | 2019-11-28
+##############################################
+
+| Following this year's theme of "bridging worlds", Genode 19.11 adds the
+| ability to use popular build tools like CMake for application development,
+| introduces a new virtual-machine monitor for 64-bit ARM, and enhances
+| POSIX compatibility. As another highlight, it features the first version
+| of our custom block-device encrypter.
+
+Block-device encryption is a feature often requested by users of our Sculpt OS.
+Until now, we deliberately left this topic unaddressed because we felt that a
+profound answer was beyond our expertise. However, during the past year, we
+dived deep into it. The result is the prototype for a new block encrypter that
+encrypts data but also protects integrity and freshness. For us, the
+implementation of the encrypter is especially intriguing because - with about
+7000 lines of code - it is Genode's first non-trivial component written in the
+[https://en.wikipedia.org/wiki/SPARK_(programming_language) - SPARK]
+programming language.
+
+The second major addition is a new virtual machine monitor (VMM) for 64-bit
+ARM platforms such as the NXP i.MX8. It leverages the
+[https://genode.org/documentation/articles/arm_virtualization - proof of concept]
+we developed in 2015 for ARMv7, which we pursued as a technology exploration.
+In contrast, our aspiration with the new VMM is a product-quality solution.
+
+In our [https://genode.org/about/road-map - road map] for 2019, we stated
+the "bridging of worlds" as our overall theme for this year. On that account,
+the current release moves the project forward on two levels. First, by
+successively increasing the scope of POSIX compatibility, we reduce the
+friction when porting existing application software to Genode. We managed
+to bridge several gaps in our POSIX support that we considered as impossible
+to cover some years ago. In particular, we identified ways to emulate certain
+POSIX signals, ioctl calls, and fork/execve semantics. This way, popular
+software such as bash, coreutils, or Vim can now be executed as regular
+Genode components with no additional runtime environment (like Noux or a VMM)
+required.
+
+At a higher level, the current release introduces new tooling especially
+geared at the development and porting of application software. Compared to
+Genode's regular development tools, which were designed for whole-system
+development, the new tool called Goa relieves the developer from the
+complexity of Genode's custom build system and instead promotes the use of
+popular commodity solutions like CMake.
+
+These and more topics are described in the
+[https:/documentation/release-notes/19.11 - release documentation of version 19.11...]
+
+
+Genode OS Framework release 19.08 | 2019-08-28
+##############################################
+
+| Genode 19.08 puts emphasis on practical concerns ranging from
+| keyboard layouts, over system-time management, to remote system
+| administration. It also continues our commitment to the 64-bit ARM
+| i.MX8 SoC, comes with Qt5 version 5.13, and improves POSIX compatibility.
+
+The summer release of Genode addresses a variety of topics when using Genode
+and Sculpt OS in practice. The confrontation with the real world prompted us
+to develop new concepts for managing system time, keyboards layouts, and
+copy-and-paste. For using Sculpt OS on the road, a new application VM for
+accessing captive portals smoothes the experience of connecting to public WiFi
+networks.
+
+Besides the practical focus, the new release continues our commitment to the
+64-bit ARM i.MX8 platform through new kernel support, device drivers, and test
+coverage. Further topics include SMBIOS support for commodity PC hardware, a
+new tracing tool, enhanced POSIX compatibility, and a major update of Qt5 to
+version 5.13.
+
+The complete picture is presented in the
+[https:/documentation/release-notes/19.08 - release documentation of version 19.08...]
+
+
+Sculpt OS release 19.07 | 2019-07-09
+####################################
+
+| Version 19.07 of the Sculpt operating system improves overall performance
+| and introduces copy and paste between terminals, virtual machines, and
+| graphical applications.
+
+The most prominent user-visible feature of Sculpt OS 19.07 is the ability
+of copy and paste text between terminals, graphical applications, and
+virtual machines. Our unique take on this feature is described in
+a [https://genodians.org/nfeske/2019-07-03-copy-paste - dedicated article].
+
+Under the hood, Sculpt 19.07 benefits from the massive infrastructure
+improvements that came with
+[https://genode.org/documentation/release-notes/19.05 - Genode 19.05],
+yielding a smoother user experience compared to earlier versions.
+
+The new release can be obtained from the
+[https://genode.org/download/sculpt - Sculpt download page] and is
+accompanied by updated
+[https://genode.org/documentation/articles/sculpt-19-07 - documentation].
+
+
 Genode OS Framework release 19.05 | 2019-05-29
 ##############################################
 

doc/release_notes-19-08.txt

@@ -0,0 +1,681 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 19.08
+              ===============================================
+
+                               Genode Labs
+
+
+
+The stated theme of this year's [https://genode.org/about/road-map - road map]
+is "bridging worlds", which expresses our ambition to smoothen the practical
+use of Genode-based systems such as Sculpt OS. The current release pays
+tribute to this ambition by addressing a great number of practical concerns:
+How to accommodate the staggering variety of keyboard layouts out there?
+(Section [Flexible keyboard layouts])
+How can the system gracefully respond when confronted with exotic USB devices?
+(Section [Storage-stack improvements])
+How to set the system time from within the system? How does SNTP fit in here?
+(Section [General system time concept])
+How to approach the remote administration of the system?
+(Section [Enhanced SSH terminal])
+How to copy and paste text securely between mutually distrusting subsystems?
+(Section [Clipboard])
+Or how to overcome the captive portal of a Hotel WiFi with Sculpt OS?
+(Section [Disposable VM for handling captive portals])
+By providing answers to those questions, we believe to make Genode - and Sculpt
+OS in particular - generally more useful.
+
+As another take on "bridging worlds", we continue our effort to bring the rich
+Sculpt OS software stack to the 64-bit ARM world, in particular to our most
+loved SoC family, namely NXP i.MX. Section [64-bit ARM and NXP i.MX8] reports
+on our progress in this direction.
+
+Under the hood, there are a few exciting developments that will greatly reduce
+the effort of running existing software on Genode. In particular, Genode's
+(entirely optional) C runtime has gained the ability to emulate the
+traditional execve and fork mechanisms.
+(Section [Consolidation of the C runtime and Noux]) This will eventually
+alleviate the need for our present noux runtime environment to the benefits of
+better performance and increased flexibility.
+
+Further highlights of Genode 19.08 are a major update of Qt5 to version 5.13
+(Section [Updated Qt5]) and the continuation of our kernel-agnostic
+virtualization story (Section [Virtualization]).
+
+
+Flexible keyboard layouts
+#########################
+
+Genode is used worldwide in a multilingual context beyond Germany and common
+technical realms of English. Therefore, we had to address localized
+keyboard-input handling for quite some time now and introduced the
+_input-filter_ component in
+[https://genode.org/documentation/release-notes/17.02#Input-event_filter - 17.02].
+The component merges input streams and applies several forms of input
+transformations, in particular the application of keyboard layouts to
+supplement the input-event stream with character events.
+
+But as we are by no means localization experts, our solution, while performing
+a solid job for selected layouts, also had some quirks and rough edges when it
+came to French or even Swiss German. First, our oversimplified notion of
+[https://en.wikipedia.org/wiki/Caps_Lock - Caps Lock] as _just a pressed Shift_
+_key_ is plain wrong but part of all our character-generator configurations.
+We just missed this drawback because none of our developers uses Caps Lock
+regularly. Further, US English and Germany layouts work very well without
+[https://en.wikipedia.org/wiki/Dead_key - dead keys], but crossing any German
+border (except the Austrian) is impossible without support for key sequences
+composing special characters. The French keyboard layout in Genode tried to
+alleviate the lack of compose sequences by adding an additional Circumflex
+modifier and character mapping, which unfortunately is not standard.
+
+[image keyboard_stack]
+
+Beginning at this state of affairs, we researched common practice in
+international keyboard-input handling, sought a quasi-standard source for
+layout configurations, and addressed the drawbacks mentioned before. During
+our research we found out that no current implementation is void of critique
+and, therefore, decided to look more into X11/XKB as our open-source
+quasi-standard solution, but always had an eye on the proprietary world.
+
+The handling of key events in X11/XKB happens on three layers.
+
+:Key codes: On the key-code layer, the device driver programs the
+  keyboard and generates a stream of key-code (i.e., scan-code)
+  events, which represent the physical location of the actual key on
+  the keyboard.
+
+:Key symbols: These key codes are mapped to key symbols, which
+  represent the label imprinted on the key. So, the key code producing
+  US English _Q_ (QWERTY keyboard) generates _A_ on a French keyboard
+  (AZERTY). Modifiers like Shift, AltGr, and Caps Lock are included in
+  the key-symbol mapping. Additionally, some layouts map key codes to
+  dead key symbols, which start the before-mentioned compose
+  sequences. Key repeat is also implemented as key-symbol repeat
+  actually.
+
+:Characters: On top of this stack, the key symbols are mapped to
+  characters represented as Unicode codepoints or UTF-8 strings.
+  The procedure obviously includes key symbols that have no character
+  representation (e.g. Control and Alt). Key symbols forming a valid compose
+  sequence generate characters on this level (e.g., dead-key circumflex plus
+  e generates ê).
+
+We limited our research to Western keyboard-input handling and only had a
+blink into the direction of Chinese-Japanese-Korean (CJK) and advanced input
+methods (IM). This simplification is supported by the fact that CJK can also
+be based on the mechanisms mentioned with some limitations only. Nevertheless,
+we do not expect to never touch this topic again.
+
+After doing our homework of keyboard-input handling, we worked on squeezing
+all available layout information out of X11/XKB, which resulted in a small
+tool residing in _tool/xkb2ifcfg_. For those wondering, the name is just a
+silly acronym for _XKB to input-filter_ _configuration_ that pays tribute to
+the boringness of this task. After building the tool by a run of 'make' in the
+tool path, it can be used as follows. Please make sure you have libxkbcommon
+development packages installed beforehand.
+
+! xkb2ifcfg generate <layout> <variant> <locale>
+!
+! xkb2ifcfg generate us euro       en_US.UTF-8
+! xkb2ifcfg generate de nodeadkeys de_DE.UTF-8
+
+If the parameter combination is available, xkb2ifcfg prints a input-filer
+chargen configuration for the selected layout to standard output. Valid
+'layout' and 'variant' options can be figured out from the LAYOUTS section in
+'man 7 xkeyboard-config', where 'variant' strings are depicted in parentheses
+after the layout (e.g., 'us(euro)'). The 'locale' option has the standard
+locale syntax (see /usr/share/i18n/locales). The tool needs all three
+parameters to gather the correct key-map and compose-sequence information. The
+generated chargen configurations include '<map>' and '<key>' nodes
+corresponding to significant modifier states and '<sequence>' nodes (described
+later). For simplicity of the generator, the '<key>' nodes always use the
+'code="..."' attribute, but also have a comment with the UTF-8 character
+appended.
+
+! <key name="KEY_MINUS" code="0x00df"/>   <!-- ß -->
+
+Last, we addressed the improvement of the input-filter character generator and
+the actual chargen configuration files in Genode. Therefore, we specified the
+modifier configuration assumed by the standard chargen files as '<mod1>'
+corresponds to Shift, '<mod2>' to Control, '<mod3>' to AltGr, and '<mod4>' to
+Caps Lock.
+
+! <mod1> <key name="KEY_LEFTSHIFT"/> <key name="KEY_RIGHTSHIFT"/> </mod1>
+! <mod2> <key name="KEY_LEFTCTRL"/>  <key name="KEY_RIGHTCTRL"/> </mod2>
+! <mod3> <key name="KEY_RIGHTALT"/> </mod3> <!-- AltGr -->
+! <mod4> <rom name="capslock"/> </mod4>
+
+As outlined above, the '<key>' nodes generated by xkb2ifcfg always use the
+'code' attribute for the Unicode codepoint. Because of this and because UTF-8
+also refers to codepoints, we deprecated the 'b0/b1/b2/b3' attributes for
+character definition with this release.
+
+The chargen is also extended by the '<sequence>' configuration node. A
+sequence node permits the definition of dead-key/composing character
+sequences. With such sequences, the character is not generated instantly on
+key press but only after the sequence is completed. If an unfinished sequence
+can't be completed due to an unmatched character, the sequence is aborted and
+no character is generated. We support sequences of up to four characters at
+the moment.
+
+For example, the French AZERTY
+[https://docs.microsoft.com/en-us/globalization/keyboards/kbdfr.html - keyboard layout]
+has a dead key for Circumflex Accent _^_ right of the _P_ key (which is
+bracket left _[_ on US keyboards). When Circumflex is pressed no visible
+character should be generated instantly but the accent must be combined with a
+follow-up character (e.g., Circumflex plus _a_ generates _â_).
+
+Dead keys can be defined in the '<key>' nodes of any '<map>' by using
+codepoints not used for direct output, for example, Combining Diacritical
+Marks beginning at U+0300. The French Circumflex example can be configured
+like follows.
+
+! <mod1>
+!   <key name="KEY_LEFTSHIFT"/> <key name="KEY_RIGHTSHIFT"/>
+! </mod1>
+! <map>
+!   <key name="KEY_Q"         code="0x0061"/> <!-- a -->
+!   <key name="KEY_LEFTBRACE" code="0x0302"/> <!-- dead_circumflex -->
+! </map>
+! <map mod1="true">
+!   <key name="KEY_Q"         code="0x0041"/> <!-- A -->
+! </map>
+! <sequence first="0x0302" second="0x0061" code="0x00e2"/> <!-- â -->
+! <sequence first="0x0302" second="0x0041" code="0x00c2"/> <!-- Â -->
+
+Fortunately, the configuration is automatically generated by xkb2ifcfg, but
+admittedly quite extensive. Therefore, we manually amended the chargen
+configurations before adding them to Genode, which also gave us the chance to
+apply some adjustments like follows for AltGr in Swiss German.
+
+! <map mod1="false" mod2="false" mod3="true" mod4="false">
+!   <key name="KEY_1" code="0x00a6"/> <!-- ¦ (*) -->
+!   <key name="KEY_4" code="0x00b0"/> <!-- ° (*) -->
+!   <key name="KEY_5" code="0x00a7"/> <!-- § (*) -->
+! </map>
+
+
+Beside the advanced input methods mentioned before, there are still loose ends
+we are going to address in the upcoming releases. For example, the current key
+handling in our Qt5 back end maps localized key symbols incorrectly (think
+AZERTY vs. QWERTY) in combination with shortcuts like Ctrl-A.
+
+
+64-bit ARM and NXP i.MX8
+########################
+
+64-bit ARM support in our custom base-hw kernel
+-----------------------------------------------
+
+By introducing rudimentary Raspberry Pi 3 support on top of the Fiasco.OC
+kernel in the previous release, the first ARM 64-bit support has entered the
+Genode OS framework. We continued pursuing the ARM 64-bit path and introduce
+support for Raspberry Pi 3 as well as the i.MX8 evaluation kit (EVK), this
+time using our own base-hw kernel.
+
+Noteworthy additions in the base-hw kernel are support for the AARCH64 system
+level architecture, and the use of the modern GIC v3 interrupt controller on
+top of the i.MX8 EVK board. In comparison to the GICv2, GICv3 adds support for
+more than eight CPUs, more than 1020 interrupt IDs, and offers fast register
+access to the CPU interface, instead of memory-mapped I/O access. Minor
+changes had to be made to the page-table implementation of ARMv7 with Large
+Physical Address Extension (LPAE) to re-use it for ARMv8. Moreover, the
+internal kernel API for TLB maintenance needed to be changed slightly for all
+ARM platforms.
+
+We expanded our regular testing infrastructure with two AARCH64 platforms,
+namely Raspberry Pi 3 via Qemu and the NXP i.MX8 EVK board as physical
+hardware. Both platforms are driven with a single CPU core only at the moment.
+
+
+Network driver for i.MX7 and i.MX8
+----------------------------------
+
+We updated the 'fec' network driver to version 4.16.3, which adds support for
+i.MX7 and i.MX8 SoCs. This makes i.MX8 a viable platform for Genode-based
+networking scenarios.
+
+
+Enhanced packaging and test infrastructure for ARMv8
+----------------------------------------------------
+
+Besides the improved base-hw kernel, we enabled additional infrastructure for
+ARMv8 platforms. For example, noux packages - like _coreutils_, _bash_ - are
+now available, the standard C++ library is in place, and support for Genode's
+port of the Linux TCP/IP stack is enabled.
+
+Additionally, ARMv8 is now regularly tested within our nightly
+_depot_autopilot_ runs.
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+Tracing
+=======
+
+Support for fast tracing has been built into Genode for a long time. However,
+the stakes to take advantage of this feature remained high because convenience
+functions were not in place. With the current release, we added the support
+for easy trace setups through a VFS plugin. The plugin is called _vfs_trace_
+and can be mounted into a Genode component as follows:
+
+!<config>
+!  <vfs>
+!    <trace ram=32MB/>
+!  </vfs>
+!</config>
+
+This configuration will create a trace file system at the root of the VFS. The
+_ram_ attribute is mandatory and determines the maximum size of all trace
+buffers. The file system forms a recursive directory structure that represents
+the parent/child relationship of running components, whereas the leaf
+directories represent single threads within a component. Each leaf directory
+currently contains three files:
+
+:'enable': Start or stop the tracing of a thread by writing "true" or "false"
+  into the file.
+
+:'buffer_size': Allows for the configuration of the trace-buffer size for the
+  thread in the usual Genode format (e.g. 5M, 512K, 1024).
+
+:'trace_buffer': This read-only file contains the current content of the trace
+  buffer. Each trace entry can only be read once, after that only new entries
+  appear. "tail -f" can also be used to display continuous output.
+
+As an example, tracing is started by writing _true_ to the _enable_ file:
+
+! echo "true" > enable
+
+The trace buffer can then be displayed using Unix tools like _tail_
+
+! tail -f trace_buffer
+
+which provides a continuous output.
+
+Additionally, we have added the _trace_ function to _base/log.h_ that
+facilitates identical functionality as _Genode::log_
+
+! Genode::trace("Tracepoint value: ", value);
+
+In order to enable tracing, the parent must provide the "TRACE" service. For a
+real world example on Sculpt OS, please refer to this
+[https://genodians.org/ssumpf/2019-06-18-trace_fs - Genodians article].
+
+With the _vfs_trace_ plugin in place, we removed the outdated _trace_fs_.
+
+
+Consolidation of the C runtime and Noux
+=======================================
+
+On our [https://genode.org/about/road-map#August_-_Release_19.08 - road map],
+we vaguely hinted at our plan for the "consolidation" of the noux runtime,
+which is actually meant as a polite way of announcing that we are going to
+remove it. We introduced the
+[https://genode.org/documentation/release-notes/11.02#Noux_-_an_execution_environment_for_the_GNU_userland - Noux runtime]
+in 2011 as a way to execute command-line-based GNU software directly on
+Genode. It has served us well over the years and is - in fact - a crucial
+ingredient of Sculpt OS and other system scenarios such as the Genodians.org
+web server. Noux supplements Genode with two valuable assets, namely a
+flexible and expandable virtual file system (VFS) layer, and the
+implementation of the
+[https://genode.org/documentation/release-notes/12.02#Noux_support_for_fork_semantics - Unix way]
+to spawn applications ('fork' and 'execve').
+
+In the
+[https://genode.org/documentation/release-notes/17.02#Enhanced_VFS_infrastructure - meantime],
+noux' VFS implementation has become independent from the noux runtime and is
+now prominently employed by Genode's C runtime and the VFS server component.
+Genode's C runtime became more and more complete, alleviating the use of noux
+as POSIX compatibility layer except for programs that depended on a working
+implementation of 'fork' and 'execve'.
+
+The current release fills this remaining gap in Genode's C runtime by
+providing 'fork', 'execve', and cousins such as 'wait4' and 'getpid' as
+regular parts of the libc. This will eventually make noux redundant.
+
+Note that this change does *NOT* make Genode reliant on POSIX. The C runtime
+including the Unix features are entirely optional.
+
+As one stepping stone of this undertaking, noux applications, which previously
+had to be compiled for noux, have become binary compatible with the regular C
+runtime. So one can execute programs like 'bash' directly as a Genode
+component without any friction.
+
+There are a few collateral improvements of Genode's dynamic linker and the C
+runtime on the account of the new 'fork' and 'execve' implementation. E.g., in
+addition to the already supported 'stdin', 'stdout', and 'stderr'
+configuration, the libc can be instructed to initialize arbitrary file
+descriptors as follows:
+
+! <config>
+!   ...
+!   <libc ...>
+!     <fd id="3" path="/dev/log" writeable="yes" readable="no" seek="10"/>
+!     ...
+!   </libc>
+! </config>
+
+The libc-based implementation of 'fork' and 'execve' can be tried out via
+the new _ports/run/bash.run_ script. Note that there are still a number of
+limitations such as the lack of signal and ioctl handling. Pipes are not
+supported, and shebangs ('#!') are not interpreted yet. That said, once those
+missing pieces come into place, we can fade out the use of noux within Genode.
+
+
+General system time concept
+===========================
+
+Briefly speaking, up to now there has been no notion of an overall concept of
+system time in Genode. Components that need to have access to some kind of
+real time are either configured locally, e.g., libc-based components access a
+configured "device" (/dev/rtc), which just might be an inline file system
+containing an artificial timestamp or the VFS RTC plugin, while other
+components query some RTC session directly. Most of the time, this session is
+provided by the 'rtc_drv' on x86 machines, which is somewhat costly as reading
+the RTC via I/O ports takes time and is therefore done scarcely. For example,
+the libc will query an RTC source only once and uses this initial value to
+interpolate the current time. However, for executing long-running components,
+it will be necessary to adjust the clock to compensate for any occurring clock
+drift or to correct a misconfigured clock in general. In addition it is
+desirable to be able to use a remote time source, e.g., an NTP-server, to
+synchronize the system time.
+
+To address this, we came up with the following concept:
+
+[image system_rtc]
+
+The new "System RTC" component, located at
+_repos/libports/src/server/system_rtc_, acts as proxy for the RTC service in
+front of the actual RTC driver. It uses the driver to get the initial RTC
+value and then uses a timer session (via the timeout framework) to locally
+interpolate the time. In contrast to querying the RTC driver, querying the
+System RTC is fast.
+
+The RTC driver and the System RTC are bundled up together in the new
+_drivers-rtc-pc_ package. The runtime of this package requests two ROM modules
+used to update the RTC value. The first one, named 'system_set_rtc', is used
+to update the proxy component while the second one, called 'hw_set_rtc', is
+used by the RTC driver to write the value into the battery-backed RTC. A
+separate component, potentially accessing a remote time source, may generate
+these ROMs to adjust the time in the package's runtime.
+
+The new native *SNTP* client at _repos/libports/src/app/sntp_client_ is such a
+component. It periodically requests the current time from a given SNTP server
+and generates a report. The report produced by the component contains the time
+as UTC/GMT. Depending on the system policy, it can be used to update the time
+of the System RTC and/or instruct the driver to set the RTC value.
+
+To propagate such changes to RTC values, the RTC session was enhanced by the
+new 'set' signal. A client of the session can install a signal handler to
+adapt its own time when necessary. Based on this, the time back end of the
+libc was changed to instantiate a watch handler for the RTC device, which,
+when triggered, will cause the libc to re-read the RTC value.
+
+This constellation should, under normal operation, allow for second to
+sub-second granularity updates of the overall system time and avoid drifting
+away from network time.
+
+
+Accessing SMBIOS tables
+=======================
+
+The System Management BIOS (SMBIOS) is a specification that allows for reading
+management information produced by the BIOS of a system as a collection of
+data structures in memory. It has the potential to eliminate the need for the
+operating system to probe hardware for discovering present devices and their
+characteristics. Nowadays, the SMBIOS specification is implemented widely in
+PC systems, which includes modern UEFI systems as well. The data structures
+are referred to as _tables_ or _records_ by public documentation.
+
+The new native SMBIOS decoder at _os/src/app/smbios_decoder_ can be used on
+x86 to parse SMBIOS tables and report gathered information in a human-readable
+way. Besides general table information like number and size of structures,
+etc., the component supports complete parsing of SMBIOS structures of types
+"BIOS", "System", and "Baseboard".
+
+The component is free from any code for acquiring an SMBIOS table through
+means like the bootloader or BIOS information. It expects a table to be
+present through a regular Genode ROM session with a 'smbios_table' label. This
+way, the underlying system is required to find, select, and save the raw table
+on startup and create a ROM module out of it. This is currently achieved on
+NOVA and base-hw through an interplay of kernel, the core component, and the
+ACPI driver and was tested for legacy BIOSes as well as UEFI systems.
+
+
+Clipboard
+=========
+
+Genode introduced a principle copy-and-paste mechanism already
+[https://genode.org/documentation/release-notes/15.11#Copy_and_paste - four years ago].
+However, originally created as a part of a tech demo, the mechanism remained
+unused in our day to day Genode work. This changed now. We took the
+integration of copy-and-paste support in Sculpt OS as an opportunity to revive
+and refine the existing mechanism and supplement it with the features needed
+to make it practical for daily use. We believe that the result aligns ease of
+use nicely with security. The concept is described in a
+[https://genodians.org/nfeske/2019-07-03-copy-paste - dedicated article]
+at Genodians.org.
+
+On a technical level, the existing clipboard component has received a new
+option that allows for dynamic information-flow policies based on user
+interactivity (keyboard focus, activity). When setting the config attribute
+'match_labels="yes"', the clipboard performs plausibility checks for copy and
+paste operations against the focus of the Nitpicker GUI server. All aspects of
+the clipboard policy - including information-flow policies - have become
+reconfigurable.
+
+To make window-manager clients compatible with the clipboard's dynamic policy,
+the window manager got enhanced with the ability to proxy the interaction with
+the clipboard. GUI clients in turn - in particular the graphical *terminal* -
+became able to interact with the clipboard. With the '<config>' attribute
+'copy="yes"' specified, the terminal allows the user to select text to be
+reported to a "clipboard" report. The selection mode is activated by holding
+the left shift key. While the selection mode is active, the text position
+under the mouse pointer is highlighted and the user can select text via the
+left mouse button. Upon release of the mouse button, the selection is
+reported. Vice versa, with the '<config>' attribute 'paste="yes"' specified,
+the terminal allows the user to paste the content of a "clipboard" ROM session
+to the terminal client by pressing the middle mouse button.
+
+Finally, we integrated those new abilities into Sculpt OS and into several
+installable packages, including virtual machines, the noux-system package,
+and graphical Qt5-based applications.
+
+
+Enhanced SSH terminal
+=====================
+
+This release paves the way for remotely managing Genode devices over SSH.
+Until now, only interactive SSH sessions were supported. It is now possible to
+execute commands from a remote SSH client. E.g., 'ssh noux@localhost -p 5555
+"ls -hal /bin/"'. For non-interactive sessions, ssh_terminal requires a helper
+component. This component is responsible to create the environment for the
+command to run in. You can find an example for such a component at
+_gems/src/test/exec_terminal_. It starts noux in a sub init and executes the
+provided command inside of it. The new _ssh_exec_channel.run_ script gives a
+demonstration on how this feature can be used.
+
+This work is a contribution by Sid Hussmann of
+[https://gapfruit.com - Gapfruit]. Thanks for this great new feature!
+
+
+Storage-stack improvements
+==========================
+
+The desire of one Genode developer to exchange data via Iomega ZIP drives
+between an Atari Falcon and Sculpt OS called for a number of small
+improvements across several components of the storage stack.
+
+First, the USB-block driver has been changed to exit on an initialization
+failure instead of waiting for another (supported) device. This change enables
+the Sculpt manager to detect such conditions and release the USB device
+hardware by removing the driver component. Such a failed initialization may
+happen with exotic USB-storage devices such as ZIP drives. With the device
+released, however, it can be assigned to a virtual machine to access it using
+a guest OS with a broader support of devices.
+
+Second, the USB-block driver received new support for issuing the SCSI
+START-STOP command at initialization time, thereby overcoming the ZIP-drive
+initialization failure.
+
+Third, we enhanced the part-block component with the ability to parse AHDI
+partition schemes and detect the GEMDOS variant of FAT as used by Atari TOS.
+
+Fourth, we enabled the Rump VFS plugin to access GEMDOS file systems. The
+GEMDOS variant is readily supported by NetBSD's "msdos" file-system driver.
+However, it must explicitly be enabled by a mount flag. Hence, we added the
+principle ability for passing mount flags to NetBSD file-system drivers and
+enabled the MSDOSFSMNT_GEMDOSFS flag based on the VFS plugin's config
+attribute 'gemdos="yes"'.
+
+With these changes in place, data can now be exchanged directly between
+Atari-formatted disks and Sculpt OS. That said, advanced use cases such as
+media changes at runtime are not covered yet.
+
+
+Updated Ada/SPARK runtime
+=========================
+
+Genode's Ada/SPARK runtime is developed and maintained by
+[https://componolit.com - Componolit]. Thanks for this excellent
+collaboration!
+
+The updated Componolit Ada runtime 1.1.0 increases the proof coverage and
+cleans up the source-code structure. SPARK mode is now enabled wherever
+possible and unneeded abstractions have been removed. Furthermore, the 64-bit
+addition and subtraction have been proven to be free of runtime errors.
+As a new feature, the runtime now supports the use of inline assembly in Ada.
+
+The removal of unneeded features such as the incomplete threading support for
+the secondary stack has greatly reduced the runtime's complexity while keeping
+the current functionality available. Also GNAT.IO has been removed as its
+implementation was incomplete and complex. A simpler replacement has been
+introduced with 'Componolit.Runtime.Debug'.
+
+Unrelated to Genode, the runtime now supports [https://muen.sk/ - Muen] and
+the API/ABI of the runtime has been separated from the GNAT ABI.
+
+
+Libraries and applications
+##########################
+
+Updated Qt5
+===========
+
+We updated our Qt5 port to the latest upstream version 5.13.0. Before
+preparing the 'qt5' port, please make sure to build and install the updated
+Qt5 host tools with the 'tool/tool_chain_qt5' script.
+
+
+Virtualization
+==============
+
+As follow-up of our work on the
+[https://genode.org/documentation/release-notes/19.05#Kernel-agnostic_virtual-machine_monitors - kernel agnostic virtual-machine monitor interface]
+on x86, we added principle support to run our port of VirtualBox on
+Genode/Fiasco.OC. We write _principle_ support, since we managed to get the
+VMM running with Fiasco.OC, but unfortunately not all features required by the
+VMM are available using the Fiasco.OC kernel, e.g., guest FPU registers, PDPTE
+registers, and task-priority support. In practice this means that the VMs with
+Windows and Linux come up to a certain point but will fail later whenever the
+guest state runs out of synchronization between VMM and hardware. In contrast,
+the Seoul VMM runs fine on Fiasco.OC since it does not depend on the mentioned
+missing features.
+
+Our main working items have been the completion of transfer of the available
+guest registers and control flow synchronization improvements between VMM and
+Fiasco.OC kernel. Additionally, the usage of priorities for VirtualBox's
+pthreads in the VMM had to be disabled. Finally, some tests for VirtualBox
+with Genode/Fiasco.OC are enabled for nightly regular testing now.
+
+As a side topic, we added support for using the VirtualBox
+[https://forums.virtualbox.org/viewtopic.php?f=2&t=82299&start=15 - CPU profile]
+feature, which allows for presenting a different CPUID to the VM than the one
+of the real CPU. This can help when running Windows 7 on a Kaby Lake or newer
+CPU, which are considered _unsupported hardware_ and reason enough not to
+receive security updates from Microsoft. The feature can be used on Genode by
+adding the 'CpuProfile' attribute to the '<CPU>' XML node in the .vbox file,
+like:
+
+! <CPU CpuProfile="Intel Core i7-5600U">
+
+
+Disposable VM for handling captive portals
+==========================================
+
+It is common that WiFi networks require the user to interact with a specific
+web page before gaining access to full network functionality. Such captive
+portal pages are completely individual to the accessed network and not limited
+in the use of common web techniques. Therefore, their handling is best be done
+using a fully-featured web browser like Mozilla Firefox.
+
+This is where, in a Genode-based desktop system like Sculpt, a disposable VM
+for hosting a minimal browser setup becomes desirable. Its goal is to unlock a
+network for the native Genode surroundings with as little inconvenience as
+possible just to be thrown away afterwards without any side effects on the
+system.
+
+Now, one could use the Firefox appliance VM of Sculpt (see the
+[https://genode.org/documentation/release-notes/18.05 - release notes] or the
+[http://genodians.org/alex-ab/2019-03-06-disposal-browser-vm - Genodians article])
+for this. But this VM aims for a long-term browsing experience which, in the
+context of mere captive-portal handling, brings some drawbacks like a much
+higher RAM consumption or the required sessions for USB detection and shared
+folders.
+
+Furthermore, in the captive portal VM, there's no need for managing windows or
+browser tabs. The one browser tab needed can always be shown in fullscreen. It
+is also unnecessary for the browser to maintain a content cache or remember
+user data. This can reduce resource consumption.
+
+[image captive_portal_vm]
+
+The VM we came up with is provided as package for Sculpt by Martin Stein
+(depot user 'mstein'). You'll possibly need to manually add Martin's
+[https://github.com/genodelabs/genode/tree/master/depot/mstein - depot key and download location]
+to your Sculpt depot directory. After enabling this user, the captive portal
+VM can be found in the Sculpt menu under "Depot -> mstein -> Virtual
+Machines -> vbox5-nova-captive-portal".
+
+The VM is based on a TinyCore 10 Linux with Xserver, i3 WM, and a tailored
+Firefox browser. The package runtime doesn't need access to your file system,
+it merely loads some ROMs into a RAM FS, so, it will completely forget any
+changes made during a session. Therefore, it's also safe to simply remove an
+instance via the Leitzentrale component-view once you don't need it anymore.
+The guest additions are also included to make the VM window resizable.
+
+
+Build system and tools
+######################
+
+At Genode Labs, we have used _tool/autopilot_ for the steering of tests in our
+Continuous Integration workflow for almost a decade now. This implied various
+improvements over the years and with the completion of our work on
+[https://genode.org/documentation/release-notes/19.05#Unified_build_directories_for_ARM - unified build directories]
+it was time to amend this handy tool once again. Unified build directories
+support building all components for one CPU architecture in one directory
+saving the build server from the redundant work we previously had with
+board-specific directories. With the new notion of boards during builds, the
+definition of the target platform when integrating Genode system scenarios is
+now a triplet of _CPU architecture_, _board_, and _kernel_. This is reflected
+in the new '-t <architecture-board-kernel>' command line option, which
+instructs autopilot to generate a build directory for _architecture_ and
+execute tests for the _board-kernel_ combination.
+
+! autopilot -t x86_64-pc-sel4 -t x86_64-pc-nova -r run/log
+
+The known options for '-k kernel' and '-p platform' are still supported with
+the small change that the platform must now be defined as
+_architecture-board_.
+
+! autopilot -p x86_64-pc -k sel4 -k nova -r run/log
+
+Autopilot now also documents the hidden feature to propagate custom 'RUN_OPTs'
+via the 'RUN_OPT_AUTOPILOT' environment variable to the run tool executed.
+Besides that, the tool always appends 'RUN_OPT' with '--autopilot'.
+
+! RUN_OPT_AUTOPILOT="--depot-dir /data/depot" autopilot ...
+

doc/release_notes-19-11.txt

@@ -0,0 +1,815 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 19.11
+              ===============================================
+
+                               Genode Labs
+
+
+
+On our [https://genode.org/about/road-map - road map] for this year, we stated
+"bridging worlds" as our guiding theme of 2019. The current release pays
+tribute to this ambition on several accounts.
+
+First, acknowledging the role of POSIX in the real world outside the heavens
+of Genode, the release vastly improves our (optional) C runtime with respect
+to the emulation of POSIX signals, execve, and ioctl calls. With the line of
+work described in Section [C runtime with improved POSIX compatibility], we
+hope to greatly reduce the friction when porting and hosting existing
+application software directly on Genode.
+
+Second, we identified the process of porting or developing application
+software worth improving. Our existing tools were primarily geared to
+operating-system development, not application development. Application
+developers demand different work flows and tools, including the freedom to use
+a build system of their choice.
+Section [New tooling for bridging existing build systems with Genode]
+introduces our new take on this productivity issue.
+
+Third, in cases where the porting of software to Genode is considered
+infeasible, virtualization comes to the rescue. With the current release, a
+new virtual machine monitor for the 64-bit ARM architecture enters the
+framework. It is presented in Section [Virtualization of 64-bit ARM platforms].
+
+As another goal for 2019, we envisioned a solution for block-level device
+encryption, which is a highly anticipated feature among Genode users. We are
+proud to present the preliminary result of our year-long development in
+Section [Preliminary block-device encrypter].
+
+
+Preliminary block-device encrypter
+##################################
+
+Over the past year, we worked on implementing a block-device encryption
+component that makes use of the
+[https://en.wikipedia.org/wiki/SPARK_(programming_language) - SPARK]
+programming language for its core logic. In contrast to common
+block-device encryption techniques where normally is little done besides
+the encryption of the on-disk blocks, the _consistent block encrypter (CBE)_
+aims for more. It combines multiple techniques to ensure integrity -
+the detection of unauthorized modifications of the block-device -
+and robustness against data loss. Robustness is achieved by keeping snapshots
+of old states of the device that remain unaffected by the further operation of
+the device. A copy-on-write mechanism (only the differential changes to the
+last snapshot are stored) is employed to maintain this snapshot history with
+low overhead. To be able to access all states of the device in the same manner,
+some kind of translation from virtual blocks to blocks on the device is needed.
+Hash-trees, where each node contains the hash of its sub-nodes, combine the
+aspect of translating blocks and ensuring their integrity in an elegant way.
+During the tree traversal, the computed hash of each node can be easily checked
+against the hash stored in the parent node.
+
+The CBE does not perform any cryptography by itself but delegates
+cryptographic operations to another entity. It neither knows nor cares about
+the used algorithm. Of all the nodes in the virtual block device (VBD), only
+the leaf nodes, which contain the data, are encrypted. All other nodes, which
+only contain meta-data, are stored unencrypted.
+
+Design
+------
+
+As depicted in Figure [cbe_trees], all information describing the various
+parts of the CBE is stored in the superblock. The referenced VBD is a set of
+several hash trees, each representing a certain device state including the
+current working state. Only the tree of the current working state is used to
+write data to the block device. All other trees represent snapshots of older
+states and are immutable. Each stored device state has a generation number
+that provides the chronological order of the states.
+
+As you can see, in the depicted situation, there exist four device states - the
+snapshot with generation 3 is the oldest, followed by two newer snapshots and
+generation 6 that marks the working state of the virtual device. The tree with
+generation 6 is the current working tree. Each tree contains all changes done
+to the VBD since the previous generation (for generation 6 the red nodes). All
+parts of a tree that didn't change since the previous generation are references
+into older trees (for generation 6 the gray nodes). Note that in the picture,
+nodes that are not relevant for generation 6 are omitted to keep it manageable.
+The actual data blocks of the virtual device are the leaf nodes of the trees,
+shown as squares.
+
+[image cbe_trees]
+
+Whenever a block request from the client would override data blocks in
+generation 6 that are still referenced from an older generation, new blocks for
+storing the changes are needed. Here is where the so-called _Free Tree_ enters
+the picture. This tree contains and manages the spare blocks. Spare blocks are
+a certain amount of blocks that the CBE has in addition to the number of blocks
+needed for initializing the virtual device. So, after having initialized a
+virtual device, they remain unused and are only referenced by the Free Tree.
+Therefore, in case the VBD needs new blocks, it consults the Free Tree (red
+arrow).
+
+In the depicted situation, writing the first data block (red square) would
+require allocating 4 new blocks as all nodes in the branch leading to the
+corresponding leaf node - including the leaf node itself - have to be written.
+In contrast, writing the second data block would require allocating only one
+new block as the inner nodes (red circles) now already exist. Subsequent write
+requests affecting only the new blocks will not trigger further block
+allocations because they still belong to the current generation and will be
+changed in-place. To make them immutable we have to create a new snapshot.
+
+The blocks in generation 5 that were replaced by the change to generation 6
+(blue nodes) are not needed for the working state of the virtual device
+anymore. They are therefore, in exchange for the allocated blocks, added to
+the Free Tree. But don't be fooled by the name, they are not free for
+allocation yet, but marked as "reserved" only. This means, they are
+potentially still part of a snapshot (as is the case in our example) but the
+Free Tree shall keep checking, because once all snapshots that referenced the
+blue blocks have disappeared, they become free blocks and can be allocated
+again.
+
+To create a new snapshot, we first have to make all changes done to the VBDs
+working state as well as the Free Tree persistent by writing all corresponding
+blocks to the block-device. After that, the new superblock state is written to
+the block-device. To safeguard this operation, the CBE always maintains several
+older states of the superblock on the block device. In case writing the new
+state of the superblock fails, the CBE could fall back to the last state that,
+in our example, would contain only generations 3, 4, and 5. Finally, the
+current generation of the superblock in RAM is incremented by one (in the
+example to generation 7). Thereby, generation 6 becomes immutable.
+
+A question that remains is when to create snapshots. Triggering a snapshot
+according to some heuristics inside the CBE might result in unnecessary
+overhead. For instance, the inner nodes of the tree change frequently during a
+sequential operation. We might not want them to be re-allocated all the time.
+Therefore, the creation of a snapshot must be triggered explicitly from the
+outside world. This way, we can accommodate different strategies, for
+instance, client-triggered, time-based, or based on the amount of data
+written.
+
+When creating a snapshot, it can be specified whether it shall be disposable
+or persistent. A disposable snapshot will be removed automatically by the CBE
+in two situations, either
+
+* When there are not enough usable nodes in the Free Tree left to
+  satisfy a write request, or
+* When creating a new snapshot and all slots in the superblock that might
+  reference snapshots are already occupied.
+
+A persistent snapshot, or quarantine snapshot, on the other hand will never be
+removed automatically. Its removal must be requested explicitly.
+
+During initialization, the CBE selects the most recent superblock and reads the
+last generation value from it. The current generation (or working state
+generation) is then set to the value incremented by one. Since all old blocks,
+that are still referenced by a snapshot, are never changed again, overall
+consistency is guaranteed for every generation whose superblock was stored
+safely on disk.
+
+Implementation
+--------------
+
+Although we aimed for a SPARK implementation of the CBE, we saw several
+obstacles with developing it in SPARK right from the beginning. These obstacles
+mainly came from the fact that none of us was experienced in designing
+complex software in SPARK. So we started by conducting a rapid design-space
+exploration using our mother tongue (C++) while using only language features
+that can be mapped 1:1 to SPARK concepts. Additionally, we applied a clear
+design methodology that allowed us to keep implementation-to-test cycles
+small and perform a seamless and gradual translation into SPARK:
+
+* _Control flow_
+
+  The core logic of the CBE is a big state machine that doesn't block. On each
+  external event, the state machine gets poked to update itself accordingly.
+  C++ can call SPARK but SPARK never calls C++. The SPARK code therefore
+  evolves as self-contained library.
+
+* _Modularity_
+
+  The complex state machine of the CBE as a whole is split-up into smaller
+  manageable sub-state-machines, working independently from each other. These
+  modules don't call each other directly. Instead, an additional superior
+  module handles the interplay. This is done by constantly iterating over all
+  modules with the following procedure until no further progress can be made:
+
+  # Try to enter requests of other modules into the current one
+  # Poke the state machine of the current module
+  # The current module may have generated requests - Try to enter them into
+    the targeted modules
+  # The current module may have finished requests - Acknowledge them at the
+    modules they came from
+
+  Each module is represented through a class (C++) respectively a package with
+  a private state record (SPARK).
+
+* _No global state_
+
+  There are no static (C++) or package (SPARK) variables. All state is kept in
+  members of objects (C++) respectively records (SPARK). All packages are pure
+  and sub-programs have no side-effects. Therefore, memory management and
+  communication with other components is left to OS glue-code outside the
+  core logic.
+
+This approach worked out well. Module by module, we were able to translate the
+C++ prototype to SPARK without long untested phases, rendering all regression
+bugs manageable. In Genode, the CBE library is currently integrated through
+the CBE-VFS plugin. Figure [cbe_modules] depicts its current structure and the
+integration via VFS plugin.
+
+[image cbe_modules]
+
+The green and blue boxes each represent an Ada/SPARK package. The translation
+to SPARK started at the bottom of the picture moving up to the more abstract
+levels until it reached the Library module. This is the module that handles
+the interplay of all other modules. Its interface is the front end of the CBE
+library. So, all green packages are now completely written in SPARK and
+together form the CBE library. Positioned above, the CXX library in blue is
+brought in by a separate library and exports the CBE interface to C++. This
+way, the CBE can also be used in other environments including pure SPARK
+programs. The CXX Library package is not written in SPARK but Ada and performs
+all the conversions and checks required to meet the preconditions set by the
+SPARK packages below.
+
+At the C++ side, we have the VFS plugin. Even at this level, the already
+mentioned procedure applies: The plugin continuously tries to enter requests
+coming from the VFS client (above) into the CBE (below), pokes the CBE state
+machine, and puts thereby generated block/crypto requests of the CBE into the
+corresponding back-ends (left). This process is repeated until there is no
+further progress without waiting for an external event.
+
+Current state
+-------------
+
+In its current state, the CBE library is still pretty much in flux and is not
+meant for productive use.
+
+As the Free Tree does not employ copy-on-write semantics for its meta-data, a
+crash, software- or hardware-wise, will corrupt the tree structure and renders
+the CBE unusable on the next start.
+
+This issue is subject to ongoing work. That being said, there are
+components that, besides being used for testing, show how the interface of the
+CBE library lends itself to be integrated in components in different ways. At
+the moment, there are two components making use of the CBE library as
+block-device provider.
+
+The first one is the aforementioned CBE-VFS plugin. Besides r/w access to the
+working tree and r/o access to all persistent snapshots, it also provides a
+management interface where persistent snapshots can be created or discarded.
+Its current layout is illustrated by Figure [cbe_vfs]. The VFS plugin
+generates three top directories in its root directory. The first one is the
+_control_ directory. It contains several pseudo files for managing the CBE:
+
+[image cbe_vfs]
+
+:'key': set a key by writing a string into the file.
+:'create_snapshot': writing 'true' to this file will attempt to create
+  a new snapshot. (Eventually the snapshot will
+  appear in the 'snapshots' directory if it could be
+  created successfully.)
+:'discard_snapshot': writing a snapshot ID into this file will discard
+  the snapshot
+
+The second is the 'current' directory. It gives access to the current
+working tree of the CBE and contains the following file:
+
+:'data': this file represents the virtual block device and gives
+  read and write access to the data stored by the CBE.
+
+The third and last is the 'snapshots' directory. For each persistent snapshot,
+there is a sub-directory named after the ID of the snapshot. This directory,
+like the 'current' directory, contains a 'data' file. This file, however,
+gives only read access to the data belonging to the snapshot.
+
+The CBE-VFS plugin itself uses the VFS to access the underlying block device.
+It utilizes the file specified in its configuration. Here is a '<vfs>'
+snippet that shows a configured CBE-VFS plugin where the block device is
+provided by the block VFS plugin.
+
+! <vfs>
+!  <dir name="dev">
+!   <block name="block"/>
+!   <cbe name="cbe" block="/dev/block"/>
+!  </dir>
+! </vfs>
+
+An exemplary ready-to-use run script can be found in the CBE repository
+at _run/cbe_vfs_snaps.run_. This run script uses a bash script to
+automatically perform a few operations on the CBE using the VFS plugin.
+Afterwards it will drop the user into a shell where further operations
+can be performed manually, e.g.:
+
+! dd if=/dev/zero of=/dev/cbe/current/data bs=4K
+
+The second component is the CBE server. In contrast to the CBE-VFS plugin,
+it is just a simple block-session proxy component that uses a block connection
+as back end to access a block-device. It provides a front-end block session to
+its client, creates disposable snapshots every few seconds, and uses the
+'External_Crypto' library to encrypt the data blocks using AES-CBC-ESSIV. The
+used key is a plain passphrase. The following snippet illustrates its
+configuration:
+
+! <start name="cbe">
+!  <resource name="RAM" quantum="4M"/>
+!  <provides><service name="Block"/></provides>
+!  <config sync_interval="5" passphrase="All your base are belong to us"/>
+! </start>
+
+The _run/cbe.run_ run script in the CBE repository showcases the use of the
+CBE server.
+
+Both run scripts will create the initial CBE state in a RAM-backed
+block device that is then accessed by the CBE server or the CBE-VFS
+plugin.
+
+The run-script and the code itself can be found on the
+[https://github.com/cnuke/cbe/tree/cbe_19.11 - cbe/cbe_19.11] branch on
+GitHub. If you intend to try it out, you have to checkout
+the corresponding
+[https://github.com/cnuke/genode/tree/cbe_19.11 - genode/cbe_19.11]
+branch in the Genode repository as well.
+
+Future plans
+------------
+
+Besides addressing the current shortcomings and getting the CBE library
+production-ready so that it can be used in Sculpt, there are still
+a few features that are currently unimplemented. For one we would like
+to add support for making it possible to resize the VBD as well as the
+Free Tree. For now the geometry is fixed at initialization time and cannot
+be changed afterwards. Furthermore, we would like to enable re-keying,
+i.e., changing the used cryptographic key and re-encrypting the tree
+set of the VBD afterwards. In addition to implementing those features, the
+overall tooling for the CBE needs to be improved. E.g., there is currently
+no proper initialization component. For now, we rely on a component
+that was built merely as a test vehicle to generate the initial trees.
+
+
+Virtualization of 64-bit ARM platforms
+######################################
+
+Genode has a long history regarding support of all kinds of
+virtualization-related techniques including
+[https://genode.org/documentation/release-notes/9.11#Paravirtualized_Linux_on_Genode_OKL4 - para-virtualization],
+[https://genode.org/documentation/articles/trustzone - TrustZone],
+hardware-assisted virtualization on
+[https://genode.org/documentation/articles/arm_virtualization - ARM],
+[https://genode.org/documentation/release-notes/13.02#Full_virtualization_on_NOVA_x86 - x86],
+up to the full virtualization stack of
+[https://genode.org/documentation/release-notes/14.02#VirtualBox_on_top_of_the_NOVA_microhypervisor - VirtualBox].
+
+We regard those techniques as welcome stop-gap solutions for using non-trivial
+existing software stacks on top of Genode's clean-slate OS architecture. The
+[https://genode.org/documentation/release-notes/19.05#Kernel-agnostic_virtual-machine_monitors - recent]
+introduction of a kernel-agnostic interface to control virtual machines (VM)
+ushered a new level for the construction respectively porting of
+virtual-machine monitors (VMM). By introducing a new ARMv8-compliant VMM
+developed from scratch, we continue this line of work.
+
+The new VMM builds upon our existing proof-of-concept (PoC) implementation for
+ARMv7 as introduced in release
+[https://genode.org/documentation/release-notes/15.02#Virtualization_on_ARM - 15.02].
+In contrast to the former PoC implementation, however, it aims to be complete
+to a greater extent. Currently, it comprises device models for the following
+virtual hardware:
+
+* RAM
+* System Bus
+* CPU
+* Generic Interrupt Controller v2 and v3
+* Generic Timer
+* PL011 UART (limited)
+* Pass-through devices
+
+The VMM is able to load diverse 64-bit Linux kernels including
+Device-Tree-Binary (DTB) and Initramfs. Currently, the implementation uses a
+fixed memory layout for the guest-physical memory view, which needs to be
+reflected by the DTB used by the guest OS. An example device-tree source file
+can be found at _repos/os/src/server/vmm/spec/arm_v8/virt.dts_. The actual VMM
+is located in the same directory.
+
+Although support for multi-core VMs is already considered internally, it is
+not yet finished. Further outstanding features that are already in development
+are Virtio device model support for networking and console. As the first - and
+by now only - back end, we tied the VMM to the ARMv8 broadened Kernel-agnostic
+VM-session interface as implemented by Genode's custom base-hw kernel. As a
+side effect of this work, we consolidated the generic VM session interface
+slightly. The RPC call to create a new virtual-CPU now returns an identifier
+for identification.
+
+The VMM has a strict dependency on ARM's hardware virtualization support
+(EL2), which comprises extensions for the ARMv8-A CPU, ARM's generic timer,
+and ARM's GIC. This rules out the Raspberry Pi 3 board as a base platform
+because it does not include a GIC but a custom interrupt-controller without
+hardware-assisted virtualization of interrupts. To give the new VMM a try, we
+recommend using the run script _repos/os/run/vmm_arm.run_ as a starting point
+for executing the VMM on top of the i.MX8 Evaluation Kit board.
+
+
+New tooling for bridging existing build systems with Genode
+###########################################################
+
+Genode's development tools are powerful and intimidating at the same time.
+Being designed from the perspective of a whole-systems developer, they put
+emphasis on the modularity of the code base (separating concerns like
+different kernels or system abstraction levels), transitive dependency
+tracking between libraries, scripting of a wide variety of system-integration
+tasks, and the continuous integration of complete Genode-based
+operating-system scenarios. Those tools are a two-edged sword though.
+
+On the one hand, the tools are key for the productivity of seasoned Genode
+developers once the potential of the tools is fully understood and leveraged.
+For example, during the development of Sculpt OS, we are able to
+change an arbitrary line of code in any system component and can test-drive
+the resulting Sculpt system on real hardware within a couple of seconds.
+As another example, the almost seamless switching from one OS kernel to
+another has become a daily routine that we just take for granted without
+even thinking about it.
+
+On the other hand, the sophistication of the tools stands in the way of
+application developers who are focused on a particular component instead
+of the holistic Genode system. In this case, the powerful system-integration
+features remain unused but the complexity of the tools and the build system
+prevails. Speaking of build systems, this topic is ripe of emotions
+anyway. _Developers use to hate build systems._ Forcing Genode's build
+system down the throats of application developers is probably not the best
+idea to make Genode popular.
+
+This line of thoughts prompted us to re-approach the tooling for Genode from
+the perspective of an application developer. The intermediate result is a new
+tool called Goa:
+
+:Goa project at GitHub:
+
+  [https://github.com/nfeske/goa]
+
+Unlike Genode's regular tools, Goa's work flow is project-centered. A project
+is a directory that may contain source code, data, instructions how to
+download source codes from a 3rd party, descriptions of system scenarios, or
+combinations thereof. Goa is independent from Genode's regular build system.
+It combines Genode's package management (depot) with commodity build systems
+such a CMake. In addition to building and test-driving application software
+directly on a Linux-based development system, Goa is able to aid the process
+of exporting and packaging the software in the format expected by Genode
+systems like Sculpt OS.
+
+At the current stage, Goa should be considered as work in progress. It's a new
+approach and its success is anything but proven. That said, if you are
+interested in developing or porting application software for Genode, your
+feedback would be especially valuable. As a starting point, you may find the
+following introductory article helpful:
+
+:Goa - streamlining the development of Genode applications:
+
+  [https://genodians.org/nfeske/2019-11-25-goa]
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+File-system session
+===================
+
+The file-system session interface received a much anticipated update.
+
+Writing modification times
+--------------------------
+
+The new operation WRITE_TIMESTAMP allows a client to update the modification
+time of a file-system node. The time is defined by the client to keep
+file-system servers free from time-related concerns. The VFS server implements
+the operation by forwarding it to the VFS plugin interface. At present, this
+new interface is implemented by the rump VFS plugin to store modification
+times on EXT2 file systems.
+
+
+Enhanced file-status info
+-------------------------
+
+The status of a file-system node as returned by the 'File_system::Status'
+operation has been revisited. First, we replaced the fairly opaque "mode" bits -
+which were an ad-hoc attempt to stay compatible with Unix - with the explicit
+notion of 'readable', 'writeable', and 'executable' attributes. We completely
+dropped the notion of users and groups. Second, we added the distinction
+between *continuous* and *transactional* files to allow for the robust
+implementation of continuous write operations across component boundaries. A
+continuous file can be written-to via a sequence of arbitrarily sized chunks
+of data. For such files, a client can split a large write operation into any
+number of smaller operations in accordance to the size of the used I/O
+buffers. In contrast, a write to a transactional file is regarded as a
+distinct operation. The canonical example of a transactional file is a
+socket-control pseudo file.
+
+
+Virtual file-system infrastructure
+==================================
+
+First fragments of a front-end API
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The VFS is mostly used indirectly via the C runtime. However, it is also
+useful for a few components that use the Genode API directly without any
+libc. To accommodate such users of the VFS, we introduced the front-end
+API at _os/vfs.h_ that covers a variety of current use cases. Currently, those
+use cases revolve around the watching, reading, and parsing of files and
+file-system structures - as performed by Sculpt's deployment mechanism.
+Writing to files is not covered.
+
+
+Improved file-watching support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All pseudo files that use the VFS-internal 'Readonly_value_file_system'
+utility have become able to deliver watch notifications. This change enables
+VFS clients to respond to VFS-plugin events (think of terminal resize)
+dynamically.
+
+Speaking of the *terminal VFS plugin*, the current release enhances the plugin
+in several respects. First, it now delivers status information such as the
+terminal size via pseudo files. Second, we equipped the VFS terminal file
+system with the ability to detect user interrupts in the incoming data stream,
+and propagate this information via the new pseudo file '.terminal/interrupts'.
+Each time, the user presses control-c in the terminal, the value stored in
+this pseudo file is increased. Thereby, a VFS client can watch this file to
+get notified about the occurrences of user interrupts.
+
+
+VFS plugin for emulating POSIX pipes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We added a new VFS plugin for emulating POSIX pipes. The new plugin creates
+pipes between pairs of VFS handles. It replaces the deprecated libc_pipe
+plugin. In contrast to the libc_pipe plugin, which was limited to pipes within
+one component, the new VFS plugin can also be used to establish pipes between
+different components by mounting the plugin at a shared VFS server.
+
+
+C runtime with improved POSIX compatibility
+===========================================
+
+Within Genode, we used to think of POSIX as a legacy that is best avoided.
+In fact, the foundational components of the framework do not depend on a
+C runtime at all. However, higher up the software stack - at the latest when
+3rd-party libraries enter the picture - a working C runtime is unavoidable. In
+this statement, the term "working" is rather muddy though. Since we have never
+fully embraced POSIX, we were content with cutting corners here and there. For
+example, given Genode's architecture, supporting 'fork' and 'execve' seemed
+totally out of question because those mechanisms would go against the grain of
+Genode.
+
+However, our growing aspiration to bridge the gap between existing popular
+applications and Genode made us re-evaluate our stance towards POSIX.
+All technical criticism aside, POSIX is immensely useful because it is
+a universally accepted stable interface. To dissolve friction between
+Genode and popular application software, we have to satisfy the application's
+expectations. This ignited a series of developments, in particular
+the added support for 'fork' and 'execve' - of all things - in
+[https://genode.org/documentation/release-notes/19.08#Consolidation_of_the_C_runtime_and_Noux - Genode 19.08],
+which was nothing short of surprising, even to us.
+The current release continues this line of development and brings the
+following improvements.
+
+
+Execve
+------
+
+The libc's 'execve' implementation got enhanced to evaluate the path of the
+executable binary according to the information found on the VFS, in particular
+by traversing directories and following symbolic links. This enables the libc
+to execute files stored at sub directories of the file system.
+
+Furthermore, 'execve' received handling for *executing shell scripts* by
+parsing the shebang marker at the beginning of the executable file. This way,
+the 'execve' mechanism of the libc reaches parity with the feature set of the
+Noux runtime that we traditionally used to host Unix software on top of
+Genode.
+
+
+Modification-time handling
+--------------------------
+
+By default, the libc uses the just added facility for updating the timestamp
+of file-system nodes when closing a written-to file, which clears the path
+towards using tools like 'make' that rely on file-modifications times.
+
+The libc's mechanism can be explicitly disabled by specifying
+! <libc update_mtime="no"...>
+This is useful for applications that have no legitimate access to a time
+source.
+
+
+Emulation of 'ioctl' operations via pseudo files
+------------------------------------------------
+
+With the current release, we introduce a new scheme of handling ioctl
+operations, which maps 'ioctl' calls to pseudo-file accesses, similar to how
+the libc already maps socket calls to socket-fs operations.
+
+A device file can be accompanied with a (hidden) directory that is named after
+the device file and hosts pseudo files for triggering the various device
+operations. For example, for accessing a terminal, the directory structure
+looks like this:
+
+! /dev/terminal
+! /dev/.terminal/info
+! /dev/.terminal/rows
+! /dev/.terminal/columns
+! /dev/.terminal/interrupts
+
+The 'info' file contains device information in XML format. The type of the XML
+node corresponds to the device type. Whenever the libc receives a TIOCGWINSZ
+ioctl for _/dev/terminal_, it reads the content of _/dev/.terminal/info_ to
+obtain the terminal-size information. In this case, the _info_ file looks as
+follows:
+
+! <terminal rows="25" columns="80/>
+
+Following this scheme, VFS plugins can support ioctl operations by providing
+an ioctl directory in addition to the actual device file.
+
+
+Emulation of POSIX signals
+--------------------------
+
+Even though there is no notion of POSIX signals at the Genode level, we
+can reasonably emulate certain POSIX signals at the libc level. The current
+release introduces the first bunch of such emulated signals:
+
+:SIGWINCH: If 'stdout' is connected to a terminal, the libc watches the
+  terminal's ioctl pseudo file _.terminal/info_. Whenever the terminal
+  size changes, the POSIX signal SIGWINCH is delivered to the application.
+  With this improvement, Vim becomes able to dynamically adjust itself
+  to changed window dimensions when started as a native Genode component
+  (w/o the Noux runtime environment).
+
+:SIGINT: If 'stdin' is connected to a terminal, the libc watches the
+  terminal's pseudo file _.terminal/interrupts_. Since, the terminal VFS
+  plugin modifies the file for each occurred user interrupt (control-c),
+  the libc is able to reflect such an event as SIGINT signal to the
+  application.
+
+:Process-local signal delivery: The libc's implementation of 'kill' got
+  enhanced with the ability to submit signals to the local process.
+
+
+Support for arbitrarily large write operations
+----------------------------------------------
+
+The number of bytes written by a single 'write' call used to be constrained by
+the file's underlying I/O buffer size. Even though our libc correctly returned
+this information to the application, we found that real-world applications
+rarely check the return value of 'write' because partial writes do usually not
+occur on popular POSIX systems. Thanks to the added distinction between
+continuous and transactional files as described in Section
+[File-system session], we became able to improve the libc's write operation to
+iterate on partial writes to continuous files until the original write count
+is reached. The split of large write operations into small partial writes as
+dictated by the VFS infrastructure becomes invisible to the libc-using
+application.
+
+
+Input-event handling
+====================
+
+In Genode 19.08, we undertook a comprehensive rework of our keyboard-event
+handling in the light of localization and also promised to tie up remaining
+loose ends soon.
+
+First, we again dived into our character generators for a thorough check of
+our stack of keyboards and fixed remaining inconsistencies in French and
+German layouts. En passant, we also increased the default RAM quotas for
+the input filter to 1280K in our recipes to cope with the increased
+layout-configuration sizes in corner cases.
+
+Next - and more importantly - we subdued the monsters lurking in our Qt5
+keyboard back end and enabled transparent support for system-wide keyboard
+layout configuration for Qt5 components. One important change during this work
+was to move the handling of control key sequences into the clients. For
+example, the graphical terminal and Qt5 interpret key events in combination
+with the CTRL modifier based on characters and, thus, support CTRL-A with
+AZERTY and QWERTY layouts correctly. As a result we removed all CTRL modifier
+(mod2) configurations from our character-generator configurations.
+
+Finally we'd like to point out one important change of our rework that
+repeatedly led to surprises: For keys without character mappings the reworked
+character-generator mechanism emits invalid codepoints in contrast to
+codepoints with value 0. For that reason, components interpreting character
+events should check 'Codepoint::valid()' to prevent the processing of invalid
+characters (and not the frequent pattern of 'codepoint.value != 0').
+
+
+NIC router
+==========
+
+The NIC router has received the ability to report the link state of its NIC
+interfaces (downlinks and uplinks). To control this mechanism, there are two
+new boolean attributes 'link_state' and 'link_state_triggers' in the <report>
+tag of the NIC router configuration. If the former is set to "true", the report
+will contain the current link state for each interface:
+
+! <domain name="domain1">
+!    <interface label="uplink1" link_state="false"/>
+!    <interface label="downlink1" link_state="true"/>
+! </domain>
+! <domain name="domain2">
+!    <interface label="downlink2" link_state="true"/>
+! </domain>
+
+The second attribute decides whether to trigger a report update each time the
+link state of an interface changes. By default, both attributes are set to
+"false".
+
+
+Device drivers
+==============
+
+Platform driver on x86
+~~~~~~~~~~~~~~~~~~~~~~
+
+During our enablement of Genode on a
+[https://genodians.org/chelmuth/2019-10-21-sculpt-elitebook - recent notebook],
+we spotted some PC platform shortcomings, we address with this release. Most
+prominently we added support for
+[https://en.wikipedia.org/wiki/PCI_configuration_space#Bus_enumeration - 64-bit PCI base address registers]
+to the x86 platform driver. This allows the use of PCI devices that are
+assigned to physical I/O-memory regions beyond 4 GiB by the boot firmware.
+
+
+Wireless driver
+~~~~~~~~~~~~~~~
+
+We added the firmware images for the 5000 and 9000 series of Intel wireless
+devices to the firmware white-list in the _wifi_drv_ component. Such devices
+as 5100AGN, 5300AGN and 5350AGN as well as 9461, 9462 and 9560 should now be
+usable on Genode.
+
+
+Libraries and applications
+##########################
+
+VirtualBox improvements
+=======================
+
+The GUI handling of our VirtualBox port got improved to react on window-size
+changes more instantly. The effect is that an interactive adjustment of the
+window size, e.g., on Sculpt, becomes quickly visible to the user. Still, the
+VM may take some time to adjust to the resolution change, which ultimately
+depends on the behavior of the driver of the VirtualBox guest additions.
+
+
+Updated 3rd-party software
+==========================
+
+With the addition of the 64-bit ARM architecture (AARCH64) with the
+[https://genode.org/documentation/release-notes/19.05#Broadened_CPU_architecture_support_and_updated_tool_chain - 19.05]
+release, it became necessary to update the libraries the Genode tool chain
+(gcc) depends on in order to support AARCH64 properly. This concerns the GNU
+multi precision arithmetic library (gmp), which has been updated from version
+4.3.2 to 6.1.2, as well as the libraries that depend on it: Multi precision
+floating point (mpfr) and multi precision complex arithmetic (mpc). All those
+old versions did not offer support for the AARCH64 architecture, which is a
+requirement to make Genode self hosting. Targets for building binutils and GCC
+within Genode for AARCH64 are in place, GNU make is in place, and even code
+coverage (gcov) has been added. This work puts AARCH64 in line with other
+supported CPU architectures and emphasizes our interest in the ARM 64-bit
+architecture.
+
+
+Platforms
+#########
+
+Execution on bare hardware (base-hw)
+====================================
+
+With the previous release, Genode's base-hw kernel got extended to support the
+ARMv8-A architecture in principle. The first hardware supported was the
+Raspberry Pi 3 as well as the i.MX8 evaluation kit (EVK). But only a single
+CPU-core was usable at that time. Now, we lifted this limitation. On both
+boards, all four CPU-cores are available henceforth.
+
+
+Removed components
+##################
+
+The current release removes the following components:
+
+:gems/src/app/launcher:
+
+  The graphical launcher remained unused for a few years now. It is not
+  suitable for systems as flexible as Sculpt OS.
+
+:os/src/app/cli_monitor:
+
+  CLI monitor was a runtime environment with a custom command-line interface
+  to start and stop subsystems. It was part of the user interface of our
+  first take on a Genode-based desktop OS called
+  [https://genode.org/documentation/release-notes/15.11#Genode_as_desktop_OS - Turmvilla].
+
+  Nowadays, we use standard command-line tools like Vim to edit init
+  configurations dynamically, which is more flexible and - at the same time -
+  alleviates the need for a custom CLI. The CLI-monitor component was too
+  limited for use cases like Sculpt anyway.
+
+  Along with the CLI monitor, we removed the ancient (and untested for long
+  time) _terminal_mux.run_ script, which was the only remaining user of the CLI
+  monitor.
+
+:fatfs_fs, rump_fs, and libc_fatfs plugin:
+
+  The stand-alone file-system servers fatfs_fs and rump_fs as well as the
+  fatfs libc plugin have been superseded by the fatfs and rump VFS plugins.
+  The stand-alone servers can be replaced by using the VFS server plus the
+  corresponding VFS plugin as a drop-in replacement.
+

doc/release_notes-20-02.txt

@@ -0,0 +1,814 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 20.02
+              ===============================================
+
+                               Genode Labs
+
+
+
+This year's [https://genode.org/about/road-map - road map] is all about making
+Genode and Sculpt OS more approachable. It turns out that the first release of
+the year already pays tribute to that goal. First, it equips Sculpt OS with a
+much more logical and welcoming graphical user interface
+(Section [Redesign of the administrative user interface of Sculpt OS]).
+Second, it greatly reduces the friction when hosting existing applications on
+Genode by smoothening several rough edges with respect to POSIX compatibility,
+and by generally improving performance.
+
+Most topics of the release are closely related to Sculpt. The biggest
+break-though is certainly the ability of running Sculpt OS on 64-bit ARM
+hardware (Section [Sculpt OS on 64-bit ARM i.MX8 hardware]) along with our
+custom virtual machine monitor (VMM). On PC hardware, Sculpt users can enjoy
+an updated audio driver and optimizations of the Seoul VMM. Furthermore,
+Sculpt's window manager received the much anticipated ability to use virtual
+desktops.
+
+At the framework-API level, the most significant changes are the introduction
+of dedicated types for inter-thread synchronization patterns
+(Section [Base-framework refinements]) and a new library for
+bringing the benefits of the Genode architecture to the application level
+(Section [New sandbox library based on the init component]).
+
+
+Redesign of the administrative user interface of Sculpt OS
+##########################################################
+
+On our [https://genode.org/about/road-map - road map] for 2020, we stated
+the reducing of the barrier of entry as our main concern of the year.
+We highlighted the ease of use of Sculpt OS as one particular work area.
+
+
+Removing Unix from the picture
+------------------------------
+
+Until now, Sculpt's administrative user interface - lyrically called
+Leitzentrale - employed a small Unix runtime and the Vim editor as utility for
+basic file operations and for the tweaking of configurations. Even though this
+was a practical intermediate solution, we have to face the fact that not
+everyone loves the Unix command-line interface as much as we do. Quite the
+opposite, actually. When presenting Sculpt, we can clearly sense that people
+with a non-Unix background are put off by it. The audience generally loves the
+runtime graph, visual cues, and discoverability. Furthermore, command-line
+interfaces are (albeit wrongly) perceived as archaic and impenetrable relics
+by many computer users who are otherwise perfectly happy with the notion of
+files and directories. We identified that file-manipulation tasks performed in
+the Leitzentrale are rare and simple. Relying on Unix for those basic tasks is
+like taking a sledgehammer to crack a nut. On average, the Leitzentrale is
+used in just a few moments a day for basic things like browsing a file-system
+hierarchy, glimpsing at the reports stored on the report file system, deleting
+or copying a file or two, or tweaking a configuration file. With a Unix shell
+presenting one barrier, Vim is certainly an even higher one. Familiarity with
+Vim should definitely not be a prerequisite for using an operating system.
+Following this reasoning, we decided to swap out the command-line interface
+and Vim by a simple GUI-based file browser and a notepad-like editor, which do
+not require any learning curve.
+
+Note that even once the Unix command-line interface is removed from Sculpt's
+Leitzentrale, advanced users will still be able to manipulate Sculpt's config
+file system via a Unix runtime deployed as a regular component, similar to the
+use of the noux-system package we have today.
+
+
+New user-interface layout
+-------------------------
+
+The move away from the command-line interface goes hand in hand with the
+redesign of the overall user-interface layout. A new panel at the top of the
+screen contains two centered tabs for switching between the runtime graph and
+the file-system browser.
+
+[image sculpt_20.02_panel]
+
+The storage-management functionality has been moved from the former storage
+dialog into the respective nodes of the runtime graph. E.g., to format a block
+device, the user can now select a USB or storage node of the graph to get a
+menu of block-device-level operations.
+
+[image sculpt_20.02_storage]
+
+The network-management is now located at a drop-down menu that can be toggled
+via a button at the right side of the panel.
+
+[image sculpt_20.02_network]
+
+A new button on the left side of the panel allows the user to toggle a
+drop-down menu for GUI settings. At the current time, there is only the option
+to adjust the font size. In the future, the dialog will give easy access to
+the screen-resolution options and the keyboard layout.
+
+The log-message view is now hidden in another drop-down menu that can be
+toggled via a panel button. So when starting the system, the user is greeted
+with only the runtime graph, which is a much nicer and cleaner looking
+experience.
+
+Informative or diagnostic messages are displayed in the left-bottom corner of
+the screen.
+
+[image sculpt_20.02_message]
+
+The "Files" tab of the panel switches the main screen area to a simple file
+browser that lists all file systems available. By toggling one of the
+file-system buttons, the directory hierarchy can be browsed. When hovering
+a file, an "Edit" or "View" button appears, which can be used to open
+the file in a text area that appears on the right side of the file browser.
+The editor supports the usual notepad-like motions, operations, and
+shortcuts (control-c for copy, control-v for paste, control-s for save).
+
+[image sculpt_20.02_editor]
+
+
+Half-way there
+--------------
+
+With the current release, one can already accomplish a lot without having to
+resort to a command-line interface: connecting to the network, managing
+storage devices, installing and deploying software, inspecting the system
+state, and tweaking configurations.
+
+There are still a few gaps though. In particular the file browser does
+not yet support file operations like the copying, renaming, or removal of
+files. For these tasks, the current version of Sculpt still features the
+Unix-based inspect window, which can be accessed by toggling the "Inspect"
+button inside the USB or storage dialog. Once selected, the panel presents an
+"Inspect" tab that features the familiar Unix shell and Vim. Note, however,
+that we keep the inspect window only as an interim solution. It will
+eventually be removed. As with every new feature, there are still rough edges
+to be expected in the editor and file browser, e.g., the editing of files with
+long lines or the browsing of directories with many entries is not
+appropriately covered yet.
+
+To see the current new version of Sculpt OS in action, you may find the
+following presentation entertaining.
+
+:Live demonstration of Sculpt OS at FOSDEM 2020:
+
+  [https://fosdem.org/2020/schedule/event/uk_sculpt/]
+
+The new version 20.02 of Sculpt OS is part of this release and can be built
+from source and used right now. Several Genode developers already provide
+ready-to-use packages for the new version. The software depots by alex-ab,
+cnuke, skalk are worth exploring. A downloadable system image along with an
+updated manual will be released shortly.
+
+
+Sculpt OS on 64-bit ARM i.MX8 hardware
+######################################
+
+Within the past two releases, big steps were taken to support ARMv8 hardware in
+the Genode OS framework. After implementing basic support for Raspberry Pi 3,
+and the i.MX 8M Evaluation Kit, the network card was enabled for the latter.
+Moreover, we updated the Linux TCP/IP, and C library ports, as well as
+the Noux environment to support the architecture. Finally, with the latest
+releases, a new ARMv8-compliant virtual-machine monitor for the base-hw kernel
+entered the framework.
+
+The rapid achievements motivated us to strive for a more ambitious scenario to
+run on top of the currently focused ARMv8 hardware platform. So why not using
+Sculpt OS on the i.MX 8M System-on-Chip?
+
+
+Persistent storage
+==================
+
+There were several challenges to cope with initially. First, persistent
+storage was needed. Luckily, the Genode OS framework contained already an
+SD-card driver implementation for the i.MX series. The driver was written for
+Genode from scratch and initially supported the i.MX53 SoC only. From then, it
+got extended repeatedly to drive the SD-card controller of several i.MX6 and
+i.MX7 platforms. Therefore, it was not a big issue to support the new hardware
+too. However, when we later used it in Sculpt, it turned out that the driver
+has some low-latency requirements. If those were not met, it got stuck. This
+was the time where the CPU-quota mechanism came in handy in a real-world
+scenario. It helped to let the interrupt handler of the driver be scheduled in
+time, and thereby let the driver run stable.
+
+Having a working block device is one part, but it is of little use without a
+file system. In Sculpt OS, the NetBSD rump kernel's ext2 file-system is
+typically used to host the depot package system and for keeping configuration
+files persistent. Unfortunately, the version of NetBSD as used in Genode's
+rump kernel port does not contain the ARMv8 architecture. Of course, we could
+have upgraded the rump kernel as a whole. But this software stack is quite
+complex with a lot of threads reproducing a sophisticated state machine. It
+took some time in the past to meet its required semantics. Therefore,
+backporting some header definitions and a few architecture-dependent functions
+seemed more attractive. Luckily, it turned out to be the right decision, and
+after a day of backporting work, the file system could run on ARMv8.
+
+Display engine
+==============
+
+One of the more challenging tasks was certainly the enabling of the Display
+Controller Subsystem (DCSS) of the i.MX 8M SoC. Originally, we hoped to profit
+from our experiences with the Image Processing Unit (IPU), the display engine
+of former i.MX SoCs. But as it turned out, the DCSS is a completely new
+design, and has not much in common with the IPU. When first writing a driver
+for the IPU of the i.MX53, we were surprised by the complexity and flexibility
+of this piece of hardware. Back then, it took months to get something
+meaningful working. To not lose too much time by re-implementing a driver from
+scratch, we decided to take the DDE Linux approach, which worked out pretty
+fast. The resulting driver should provide the same flexibility like the Linux
+original one. However, as the i.MX 8M EVK board provides a HDMI connector
+only, we did not test more than that. The configuration of the driver is
+analogous to the Intel framebuffer driver, and looks like the following:
+
+! <config>
+!   <connector name="HDMI-A-1" width="1920" height="1080" hz="60" enabled="true"/>
+! </config>
+
+Later, when using the driver in practice within the Sculpt OS, we could
+experience a slightly sluggish behaviour, which was due to a missing
+architectural back end of the blitting library of Genode. After tweaking this
+too, the graphical user interface experience was good.
+
+
+USB and Input
+=============
+
+The last missing I/O device to run Sculpt OS on the ARMv8 was something for
+user generated input. Therefore, the existent USB host controller driver for
+the i.MX series got updated. The only roadblock here was the powering of the
+device. As there is no platform driver for the target hardware yet, which
+would manage power and clocks, the hardware either has to be pre-configured
+correctly, or the driver has to enable it on its own. Ethernet card, SD-card,
+and the display engine were all already powered by the bootloader, but not
+USB. In contrast to the first devices, the u-boot bootloader turns off USB
+explicitly as soon as it starts the OS. As an interim solution, we patched
+u-boot to not turn off the USB host controller, and enforced u-boot to
+initialize the powering in our boot scripts. Therefore, if one wants to use
+USB on the i.MX 8M EVK, make sure to take our modified version. As a
+convenient solution, you can use the 'uboot' port within the base repository.
+Just issue the following command in the Genode directory:
+
+! tool/ports/prepare_port uboot
+
+Finally, you have to copy u-boot to the SD-card as root user:
+
+! dd if=`tool/ports/current uboot`/imx8q_evk/imx-mkimage/iMX8M/flash.bin \
+!    of=/dev/sd<?> bs=1k seek=33 conv=fsync
+
+Of course, you have to replace 'sd<?>' with the correct device node of your
+attached SD-card.
+
+After enabling the USB host controller driver, we could successfully re-use the
+USB HID client driver to drive keyboard and mouse connected to the board. As a
+nice side-effect, the list of possible storage devices got extended with USB
+mass storage too by adding the USB block client driver.
+
+
+Missing libraries
+=================
+
+Finally, when building the necessary and optional packages for Sculpt OS, we
+stumbled across several libraries that needed to be adapted to compile and
+link for ARMv8 too. Mostly, the inclusion of some other compilation units and
+headers was sufficient. The related libraries are: libssl, libcrypto, libpng,
+and Mesa. With the latter two, it is now even possible to execute Qt5
+components on the target hardware.
+
+Apart from all the new driver components and extended libraries, the Sculpt
+manager had to be slightly modified to execute on the i.MX 8M hardware. In its
+original form it is inherently dependent on x86 drivers, as it for example
+generates configurations for some of those drivers. For the time being, the
+changes to the Sculpt manager are not yet part of the official release.
+Nevertheless, you can produce a Sculpt OS image to be run on an i.MX 8M EVK
+board by using the following
+[https://github.com/skalk/sculpt_20.02_imx8q_evk/ - topic branch].
+
+Alternatively, you can also have a look at Sculpt OS on ARMv8 hardware by
+following the video recordings of the following talk at FOSDEM 2020.
+
+:Live demonstration of Sculpt OS on i.MX 8M EVK at FOSDEM 2020:
+
+  [https://fosdem.org/2020/schedule/event/uk_genode_armv8/]
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+New sandbox library based on the init component
+===============================================
+
+The init component is Genode's canonical mechanism for the composition of
+components. This role was further amplified when init became
+[https://genode.org/documentation/release-notes/17.02#Dynamically_reconfigurable_init_component - dynamically reconfigurable].
+The latter change cleared the ground for system scenarios like Sculpt OS, the
+on-target deployment of packages, and dynamic device discovery. One typical
+pattern found in such scenarios is one dynamically configured instance of init
+accompanied by a controlling component that is usually called "manager". The
+manager would consume reports of the subsystem hosted within the dynamic init,
+and adjust the init configuration according to a domain-specific policy. Such
+a configuration change, in turn, may trigger new reports, which effectively
+turns this setting into a feedback control loop.
+
+Whereas this established pattern is suitable for many scenarios, it is not
+always natural. In particular if the manager does not only need to
+manage a subsystem but also wants to intercept a service used by the
+subsystem, the roles are no longer clear-cut. A practical example is a
+GUI application that employs the menu-view component for the GUI rendering
+while processing keyboard events locally. This application would need to
+intercept the menu-view's GUI session to obtain the stream of user input
+events. For such an application, the most natural approach would be the
+co-location of the init functionality with the application logic into a
+single all-encompassing component.
+
+To accommodate such scenarios where a domain-specific management component is
+tightly coupled with a dynamic subsystem, we extracted the child-management
+functionality from the init component into a new library called "sandbox". The
+library API is located at
+[https://github.com/genodelabs/genode/blob/master/repos/os/include/os/sandbox.h - os/include/os/sandbox.h].
+
+In addition to the hosting of components, the sandbox API also allows for the
+interaction with the sandboxed children by providing locally implemented
+services. The latter mechanism is illustrated by a new test available at
+_os/src/test/sandbox_.
+
+
+POSIX compatibility improvements
+================================
+
+During the release cycle of Genode 20.02, we continued our mission to host
+POSIX software effortlessly as Genode components. In particular, we followed
+up the line of work pursued with the two previous releases
+[https://genode.org/documentation/release-notes/19.08#Consolidation_of_the_C_runtime_and_Noux - 19.08] and
+[https://genode.org/documentation/release-notes/19.11#C_runtime_with_improved_POSIX_compatibility - 19.11]
+with respect to the traditional Unix mechanisms fork, execve, and pipes.
+After covering several edge cases - cloexec, file-descriptor lifetimes,
+line-buffer handling, vfork, just to name a few - as needed by programs like
+make, bash, and tclsh, we eventually reached a state where the website
+generator of [https://genodians.org] works without the need for the now
+deprecated Noux runtime.
+
+For years we have been running complex software stacks like the Qt-based web
+browser on top of our C runtime but not without carefully placed tweaks and
+occasional patches. With the current release, we address the area of
+concurrency and introduce a thorough reimplementation of the synchronization
+primitives namely POSIX mutexes and condition variables as well as semaphores.
+We also reaped the fruit of our labor by replacing our custom Qt thread back
+end by the standard POSIX-thread based implementation. Further, we reduced the
+number of threads in Qt applications by moving the QPA event handling to the
+component entrypoint and removing the timed-semaphore utility from LibC.
+
+Beyond Qt, we also address synchronization issues revealed by running a
+third-party port of [https://grpc.io/ - gRPC] in our network back ends and
+amended thread-local errno in the C runtime. Finally, our POSIX thread
+implementation supports cleanup handlers now.
+
+
+Base-framework refinements
+==========================
+
+Replacing the 'Lock' type by new 'Mutex' and 'Blockade' types
+-------------------------------------------------------------
+
+Up to now, Genode's lock implementation supports mainly two flavours of usage.
+On the one hand, it is used to protect critical sections where the lock is
+initialized as unlocked. In the contention case, the lock holder is supposed
+to release the critical section. On the other hand, the lock is used as
+blockade to synchronize startup between various executions of threads. Here
+the lock is initialized as locked during instantiation whereby the thread that
+releases the lock is not necessarily the same thread as the creator of the
+lock.
+
+We decided to make the two usage patterns more obvious by introducing two
+separate classes, called 'Mutex' and 'Blockade'. The reasons are twofold.
+First, during code review, the usage pattern at hand becomes more obvious.
+Second, by codifying the programmer's intent behind the use of a
+synchronization primitive, Genode becomes able to perform additional checks,
+and diagnose certain dead-lock situations and other usage errors on the spot.
+
+The separation got introduced shortly before this release. Up to now, it is
+only used in 'Genode::Thread', 'Genode::Heap', and 'Genode::Registry'. The
+plan is to cultivate the usage across all Genode sources over the next
+releases and to ultimately remove the 'Genode::Lock' from the public API.
+
+The 'Mutex' class is more restrictive compared to the 'Lock' class.
+
+* At initialization time, it is always unlocked.
+* To enter and leave a critical section the methods 'acquire()' and
+  'release()' are used.
+* A 'Mutex::Guard' is provided, which will 'acquire()' a mutex at
+  construction time and release it automatically at destruction time of
+  the guard.
+* No thread is permitted to lock twice. The code will generate a warning if
+  a dead-lock is detected.
+* Only the lock holder is permitted to release the mutex. The code will
+  generate a warning and will not release the mutex if this rule is violated.
+
+! Genode::Mutex mutex;
+! mutex.acquire();
+! mutex.release();
+!
+! {
+!   Genode::Mutex::Guard guard(mutex) /* acquire() during construction */
+! }                                   /* release() on guard object destruction */
+!
+! Genode::Mutex::Guard guard(mutex);
+! mutex.acquire();                    /* <-- Will cause a warning about the dead-lock */
+
+The 'Blockade' class is always initialized as locked and provides the methods
+'block()' and 'wakeup()'. Beside the initialization aspect, the 'Blockade'
+behaves up to now like the 'Genode::Lock' implementation.
+
+! Genode::Blockade blockade;
+!
+! /* step */    /* thread A */        /* thread B */
+! 0:            -start thread B-
+! 1:            ...                     -startup-
+! 2:            blockade.block();       ...
+! 3:            -sleep-                 ...
+! 4:            -sleep-                 blockade.wakeup();
+! 5:            ...                     ...
+
+
+Performance optimization of the XML parser
+------------------------------------------
+
+Genode's XML parser used to rely on C++ exceptions while parsing, which is an
+almost historic artifact inherited from the initial implementation. The
+performance penalties of exceptions in the rare use of XML was acceptable
+back when we started. But modern Genode systems like Sculpt OS rely on the
+dynamic processing of XML like a back bone. The overhead became particularly
+apparent when executing [Sculpt OS on 64-bit ARM i.MX8 hardware]. Prompted by
+this observation, we reworked the code such that exceptions are no longer
+thrown in any hot code path. The public interface of 'Xml_node' remains
+unchanged.
+
+
+New polling variant for register framework
+------------------------------------------
+
+Genode's register framework has offered a 'wait_for' method for a long time.
+This function sleeps for a certain amount of microseconds and checks if one or
+more given conditions become true. The number of attempts to sleep and check
+the conditions must also be specified. In case the conditions are not met
+after these attempts, a polling timeout exception is thrown. The function
+simply returns in case of success. With the current Genode release, we have
+added a 'wait_for_any' method with almost the same semantics but instead of
+waiting for all conditions to become true, it returns if any condition is
+met, and thus, implements a logical OR.
+
+
+Migration to modern block-device API
+====================================
+
+With release 19.02, Genode introduced two new APIs for block-session handling.
+The client side of a block session now uses the job API in order to send block
+requests to the server, which in turn receives those jobs as requests through
+the Request API. These two APIs replace Genode's 'Block::Driver' and
+'Block::Session_component' implementations that used the packet stream API
+directly, which turned out to be error prone for block session implementations.
+Instead, these new APIs wrap the packet stream handling in a controlled
+manner while handling all corner cases and even the overcommit of packets.
+With the current release, we have adapted Genode's AHCI driver and partition
+manager to these new interfaces, with the plan to adjust all block session
+clients/servers to the new APIs with Genode release 20.05.
+
+During this line of work, the AHCI driver received a major cleanup. For
+example, dynamic memory allocations were removed, the whole initialization
+state machine has been removed, ATAPI support for Qemu has been re-enabled,
+and Exynos5 AHCI support is gone - since the platform is outdated and not
+supported by Genode any more.
+
+
+Updated audio driver based on OpenBSD 6.6
+=========================================
+
+In this release, we updated the 3rd-party sources of the audio driver component
+to OpenBSD 6.6 and adapted the emulation glue code. While doing so, we fixed
+a bug regarding the 'delay()' implementation where the function expects
+microseconds but was given milliseconds. This led to a increased start-up
+time of the component. We also fixed the logging back end that accidentally
+was rendered silent and brought in the 'printf' back end from DDE Linux to
+be able to produce better formatted LOG messages in the future.
+
+Until now the component only supported HDA and EAP (ES1370 PCI) devices. The
+first is primarily intended to be used with real hardware whereas the latter
+was used during the initial porting effort in Qemu. That being said, the EAP
+driver apparently also works on hardware according to community feedback.
+
+Since the HDA driver does not work when used in VirtualBox and users expressed
+the desire to also use audio when running in a VM, we enabled another driver,
+for which a device-model in VirtualBox exists: the AC97 ICH. As it turned out,
+using this driver, we can produce audio, albeit the quality is far from
+usable. Nevertheless, with the driver enabled, interested parties are free to
+investigate the cause for the current issues.
+
+All in all, this update is solely a catch up effort to stay more
+up-to-date with the upstream changes and to pull in HDA quirks for more
+recent systems. More interesting changes to the driver component, like
+reworking the OpenBSD kernel emulation layer and bringing support for USB
+audio devices, are scheduled for future releases.
+
+
+Support for unlabeled LOG output
+================================
+
+In situations where a Genode system is remotely controlled and monitored,
+it is useful to allow a special component to produce log output with no
+Genode label applied. This way, such a component can produce log data in
+a format that is immediately suitable for a controller. This feature can be
+enabled for a component by rewriting the label of the component's LOG session
+to "unlabeled".
+
+! <route>
+!   <service name="LOG"> <parent label="unlabeled"/> </service>
+!   ...
+! </route>
+
+
+Libraries and applications
+##########################
+
+Custom virtual machine monitor on ARM
+=====================================
+
+The ARMv8-compliant virtual-machine monitor introduced in the previous release
+19.11 now contains new device models to enable the interaction with a
+virtual-machine via network and terminal services. The new virtual ethernet
+card and console implementations are compliant to the virtualization standard
+VIRTIO 1.1.
+
+Currently, the VMM cannot be configured to contain specific devices. It is
+hard-wired to provide exactly:
+
+* One virtual ethernet card that connects to Genode's "Nic" service,
+* A VIRTIO console that opens up a session to the "Terminal" service using the
+  label "console", and
+* The traditional PL011 serial device model, which connects to a
+  "Terminal" service too but uses the label "earlycon"
+
+
+Seoul VMM
+=========
+
+During the usage of Seoul on Sculpt, it became apparent that the Seoul VMM
+caused a constant CPU load even when the guest VM was idling. After some
+investigation it became clear that having a fixed rate to synchronize the
+guest graphic memory with the Genode GUI service was the main reason for the
+constant load. With this release, we added the feature to dynamically adjust
+the GUI refresh rate depending on the rate of user interactivity.
+Additionally, if all virtual CPUs go to idle state, the GUI refresh is stopped
+completely. With these measures, the overall CPU load could be reduced
+noticeably.
+
+
+TCP terminal
+============
+
+The TCP terminal is a long-living component in the Genode OS framework since
+release 11.11. It can be used, e.g., to connect to a headless Genode system
+via telnet. Until now, it always listened to incoming network connections at
+configured ports. The port had to be configured for each terminal session
+client.
+
+The TCP terminal got extended to either listen to incoming network
+connections, or to directly connect to another network server, dependent on
+the policy defined for the corresponding terminal client. The following
+example configuration illustrates the differences:
+
+! <config>
+!   <policy label="client" ip="10.0.0.5" port="1234"/>
+!   <policy label="another_client"       port="4567"/>
+! </config>
+
+If only a port is described in the policy, the TCP terminal will listen on
+that port for incoming connections. If an IP address is provided additionally,
+it connects to the IP address using the given port.
+
+
+Virtual desktops
+================
+
+Genode's GUI stack enables a high degree of flexibility. Beside the fundamental
+nitpicker component, responsible for basically multiplexing input events and
+framebuffer content, there is the window-manager component, and example
+implementations of a window-layouter, and decorator. The interplay of the
+latter three allows a window management that scales from simple to rich and
+sophisticated without lowering its security properties. For a brief description
+of its architecture, please refer to the release notes of
+[http://genode.org/documentation/release-notes/14.08 - 14.08].
+
+In this architecture, the window layouter is responsible for the arrangement
+of the different windows. It exports a data model of the window layout.
+Although, the example implementation of the window layouter introduced in
+14.08 was simple, it already contained a notion of having different virtual
+screens and screen sections, beside the actual window placements. However,
+until now there was no use-case of switching dynamically between different
+virtual screens respectively window sets related to them.
+
+While using more and more different graphical components within Sculpt, the
+window layouter in its initial form hit a limit. Although it already allowed to
+switch in-between different windows via configured key-combinations, it became
+inconvenient when having more than a handful windows hiding each other.
+
+Therefore, the window layouter now got extended to allow switching dynamically
+in between several pre-defined virtual screens. For the time being, one has to
+assign a new window to a screen in the rule-set of the window layouter
+initially by hand. Defining the currently visible screen can either be done by
+editing the rule-set, or by using pre-configured key-combinations.
+
+The new default configuration of the window layouter as exported by its
+corresponding depot package looks like the following:
+
+! <config rules="rom">
+!   <rules>
+!     <screen name="screen_1"/>
+!     <screen name="screen_2"/>
+!     <screen name="screen_3"/>
+!     <screen name="screen_4"/>
+!     <screen name="screen_5"/>
+!     <screen name="screen_6"/>
+!     <screen name="screen_7"/>
+!     <screen name="screen_8"/>
+!     <screen name="screen_9"/>
+!     <screen name="screen_0"/>
+!     <assign label_prefix="" target="screen_1" xpos="any" ypos="any"/>
+!   </rules>
+!
+!   <press key="KEY_SCREEN">
+!     <press key="KEY_ENTER" action="toggle_fullscreen"/>
+!     <press key="KEY_1"     action="screen" target="screen_1"/>
+!     <press key="KEY_2"     action="screen" target="screen_2"/>
+!     <press key="KEY_3"     action="screen" target="screen_3"/>
+!     <press key="KEY_4"     action="screen" target="screen_4"/>
+!     <press key="KEY_5"     action="screen" target="screen_5"/>
+!     <press key="KEY_6"     action="screen" target="screen_6"/>
+!     <press key="KEY_7"     action="screen" target="screen_7"/>
+!     <press key="KEY_8"     action="screen" target="screen_8"/>
+!     <press key="KEY_9"     action="screen" target="screen_9"/>
+!     <press key="KEY_0"     action="screen" target="screen_0"/>
+! ...
+
+As can be seen, individual keys are assigned to switch to a specific virtual
+screen. By default ten screens are defined that are accessible via the number
+keys. The first screen definition in the rules configuration marks the
+currently visible screen.
+
+
+Menu-view widget renderer
+=========================
+
+The line of work described in Section
+[Redesign of the administrative user interface of Sculpt OS] called for
+the enhancement of Genode's GUI-rendering component. This component - named
+menu view - was
+[https://genode.org/documentation/release-notes/14.11#New_menu_view_application - originally introduced in Genode 14.11]
+for the rendering of the relatively simple menus of an application launcher.
+Its software design largely deviates from the beaten track of established
+widget toolkits, which come in the form of client-side libraries. The
+menu view is not a complete toolkit but solely a dialog renderer sandboxed
+in a dedicated component. This design reinforces the strict separation of the
+view from the application logic, fosters screen-resolution independence, and -
+most importantly - keeps the complexity of pixel processing out of the
+application program. Because of the latter, it lends itself to the
+implementation of security-sensitive interactive applications.
+
+It would certainly be misguiding to tout our menu-view as feature competitive
+with existing toolkits. We certainly won't recommend using it over Qt in
+general. But Sculpt's custom administrative user interface "Leitzentrale"
+presented us with the perfect playground to explore and grow the potential of
+our novel approach.
+
+In contrast to the previous iteration of the Leitzentrale GUI, which relied on
+a small Unix runtime and Vim for editing text files, the new version ought to
+feature a simple text editor integrated in the GUI. A text editor requires
+a much tighter interplay between the view and the actual program logic
+compared to an application with just a bunch of buttons. Think about cursor
+handling, scrolling text, displaying textual selections, or placing a text
+cursor with the mouse. On the course of the work towards the text-area
+component featured in the new Leitzentrale, the menu view received the
+following improvements:
+
+:Text-cursor support:
+
+  The label widget gained the ability to display one or multiple text cursors,
+  as illustrated by the following example:
+
+  ! <label text="...">
+  !   <cursor at="10"/>
+  ! </label>
+
+  For the display of multiple cursors, each cursor must feature a distinctive
+  'name' attribute.
+
+:Character position featured in the hover report:
+
+  The hovering information provided by the menu view used to be at the
+  granularity of widgets, which is insufficient for placing a text cursor with
+  the mouse. Hence, the information of a hovered label additionally provides
+  the character position within the label now.
+
+:Unquoting label text attribute values:
+
+  The text displayed in label widgets is provided by a 'text' attribute value,
+  which raises the question of how to present '"' characters on the GUI. With
+  the new version, the attribute value can contain XML-quoted characters,
+  specifically "&quot;".
+
+:Support for displaying text selections:
+
+  Similarly to the way of how a <cursor> can be defined for a <label>
+  widget, a selection can now be expressed as follows:
+
+  ! <label ...>
+  !   <selection at="2" length="12"/>
+  ! </label>
+
+:Support of multiple '<float>' widgets within a '<frame>':
+
+  We refined the hover reporting of <float> widgets such that a float widget
+  never responds to hovering unless a child is hovered. This way, it becomes
+  possible to stack multiple float widgets within one frame and still reach
+  all child widgets. This is useful for aligning multiple widgets within one
+  screen area independently from each other. For example, for left-aligning,
+  centering, and right-aligning the elements of a panel.
+
+:Enforcing the minimum size of a label:
+
+  The new '<label min_ex="..">' attribute can be used to enforce a minimum
+  width in the unit of the size of the character 'x'. In the absence of a
+  'text' attribute, the minimum height of a label is implicitly set to 0. The
+  combination of both changes makes the label usable as a horizontal spacer.
+
+:Basic support for styling labels:
+
+  The new version allows for the customization of the text color and alpha
+  value of the label widget by the means of a style-definition file. The
+  mechanism is exemplified with the new "invisible" label style that sets the
+  alpha value to zero.
+
+With these few incremental changes in place, the menu-view widget renderer
+becomes usable as the basis of the simple text editor used in Sculpt's new user
+interface.
+
+
+Self-hosting the tool chain on 64-bit ARM
+=========================================
+
+With our ongoing ARM 64-bit effort, we have successfully updated Genode's tool
+chain with release
+[https://genode.org/documentation/release-notes/19.05#Broadened_CPU_architecture_support_and_updated_tool_chain - 19.05].
+With the current release, we have additionally managed to make Genode's tool
+chain self hosting on ARM 64-bit, which means the tool chain can compile
+source code on ARM 64-bit directly.
+
+
+Platforms
+#########
+
+Execution on bare hardware (base-hw)
+====================================
+
+The generic code base of the base-hw kernel underwent several cosmetic changes
+to reduce or eliminate the application of certain problematic constructs like
+too much inheritance, pointers, and dynamic casts. Those changes were
+motivated to ease the translation of several kernel parts to the Ada/SPARK
+language in the context of the Spunky project. For more information regarding
+this experiment to write a Genode kernel in Ada/SPARK, please have a look at
+the recent [https://genodians.org/m-stein/index - genodians.org article series]
+of Martin Stein or listen to his recent
+[https://video.fosdem.org/2020/AW1.125/ada_spunky.mp4 - FOSDEM talk].
+
+Moreover, the IPC path implementation got simplified to lower the overhead
+costs introduced by the transfer of capabilities. Together with the mentioned
+Spunky cleanup efforts, this change measurably improved IPC performance.
+
+The base-hw kernel now exports time consumption of individual threads via
+the trace service analogously to the implementation for NOVA. Thereby, it
+becomes possible to use for instance the top component within the Sculpt OS
+also on this kernel.
+
+Until now, support for the Raspberry Pi 3 was limited to Qemu emulation only.
+Thanks to a contribution of Tomasz Gajewski, it is now possible to execute
+Genode on all four CPUs of the actual hardware concurrently.
+
+
+Execution on Linux
+==================
+
+Traditionally, the Linux version of Genode serves us as very handy development
+vehicle but it was never intended as an actual target platform. On Linux,
+Genode is usually executed as a multi-process application on top of a regular
+GNU/Linux desktop distribution by specifying 'KERNEL=linux' and 'BOARD=linux'
+to the run tool.
+
+However, thanks to the work of Johannes Kliemann, Genode has become able to
+run on a bare-bone Linux kernel without any other user land.
+We blatantly used to refer to this idea as the
+[https://genode.org/about/challenges#Platforms - microkernelization of Linux].
+Johannes picked up the idea, supplemented Genode's core with the services
+needed for user-level device drivers (IRQ, IOMEM, IOPORT) and supplemented
+the tooling for the integration of Genode scenarios into a bootable initrd
+image. This target of execution can be addressed by specifying 'KERNEL=linux'
+and 'BOARD=pc' to the run tool now. If specified, the run tool will produce a
+bootable Linux system image for the given run script and run it in Qemu.
+
+That said, as this line of work is still considered as an experimental
+playground - not for productive use - the work flow is not entirely automated.
+In particular, one needs to prepare a suitable
+[https://github.com/jklmnn/linux/commits/genode - Linux kernel] manually.
+If you are interested in the topic, please refer to the background information
+given in the [https://github.com/genodelabs/genode/pull/2829 - issue tracker].
+

doc/road_map.txt

@@ -14,122 +14,121 @@ The road map is not fixed. If there is commercial interest of pushing the
 Genode technology to a certain direction, we are willing to revisit our plans.
 
 
-Review of 2018
+Review of 2019
 ##############
 
-Sculpt is our take on creating a Genode-based general-purpose operating
-system. When we declared 2018 as Genode's Year of Sculpt one year ago, our
-vision of how Sculpt OS would shape up was still vague. We were convinced that
-we had - functionality-wise - all building blocks of a general-purpose OS in
-place. But it was rather unclear how to best put them together to attain a
-practical system. The unconquered design space seemed vast, which was both
-exciting but also - at times - a bit paralyzing.
+For the road map 2019, we picked "bridging worlds" as our guiding theme:
+(1) Lowering the friction when combining existing software with Genode,
+(2) Fostering interoperability with widely used protocols and APIs, and
+(3) Making Genode easier to approach and generally more practical.
 
-The Year of Sculpt was more than anything a design-space exploration, not
-an up-front planned activity. The process was driven by intensive
-brainstorming, experimentation, and the continuous practical evaluation
-through the day-to-day use of the system by its developers. For us, this ride
-was certainly the most rewarding period in Genode's history so far. Now, when
-looking at the result, we are proud about what we have achieved together.
-Whenever having the chance to showing off Sculpt running on our laptops,
-the system doesn't fail to impress.
+With respect to (1), we identified Genode's custom tooling (build
+system, run scripts, ports mechanism, depot tools) as a point of
+friction. They are arguably powerful and flexible but require a lot of
+up-front learning. This is certainly a burden unacceptable for a casual
+developer without a black belt in Make and Expect/Tcl. The new
+[https://genode.org/documentation/release-notes/19.11#New_tooling_for_bridging_existing_build_systems_with_Genode - Goa]
+tool rearranges the existing tools in a way that puts the concerns of casual
+developers into focus, allowing for the use of commodity build systems,
+eliminating Tcl syntax from the equation, running sub-second test cycles, and
+streamlining the packaging of software.
 
-Unsurprisingly, many topics of the past year had a direct connection to
-Sculpt, e.g., the NIC router, the huge device-driver efforts, the GUI-stack
-improvements, our custom microcode update mechanism, the software packaging
-and deployment, and the work on the file-system and networking stacks.
+On account of (2), we
+[https://genode.org/documentation/release-notes/19.05#Broadened_CPU_architecture_support_and_updated_tool_chain - switched to C++17]
+by default, fostered the use of
+[https://genodians.org/ssumpf/2019-02-27-java-19-02 - Java],
+updated Qt5, and put
+[https://genode.org/documentation/release-notes/19.11#C_runtime_with_improved_POSIX_compatibility - POSIX]
+compatibility into the spotlight. We were eventually able to dissolve the need
+for our custom Unix runtime (Noux) because all features of Noux are covered by
+our regular libc now.
 
-The bottom line of the Year of Sculpt is that Sculpt OS has become a
-surprisingly versatile and robust system. It can be deployed in a few seconds
-by booting from USB, runs as day-to-day OS on almost all of our laptops, its
-mechanisms for installing and updating software from packages have become a
-second nature, and it continues to inspire us to explore new application
-areas. Even outside of Genode Labs, there is a small and enthusiastic user
-base.
+Our biggest step towards (3) is the [https://genodians.org] website we
+started in winter 2019, which gives individual members of our community
+an easy way to present thoughts, projects, and experiences.
+Complementing Genode's formal documentation, it also conserves practical
+tips and tricks that were previously not covered in written form.
 
-Besides Sculpt, we set forth a number of other goals one year ago.
+When speaking of "bridging worlds", we should not forget to mention the
+tremendous effort to bring Sculpt-OS-like workloads to the 64-bit ARM world.
+Thanks to the added support for
+[https://genode.org/documentation/release-notes/19.08#64-bit_ARM_and_NXP_i.MX8 - multi-core AARCH64],
+hardware-based
+[https://genode.org/documentation/release-notes/19.11#Virtualization_of_64-bit_ARM_platforms - virtualization],
+and network/USB/graphics drivers for the i.MX8 SoC, the flexibility of Sculpt
+OS will eventually become available on PC hardware and ARM-based devices
+alike.
 
-:The transition from NOVA to our custom kernel and seL4: is ongoing but
-  the topic received less attention than originally planned. This has
-  two reasons. First, Alexander Boettcher's excellent maintenance and gradual
-  improvement of NOVA keeps us hooked. Over the past year, there has been not
-  much incentive of actual Sculpt users to move away from NOVA. Second, there
-  is renewed interest in NOVA beyond our use of the kernel. Most specifically,
-  we started joining forces with
-  [https://cyberus-technology.de - Cyberus Technology] to improve NOVA
-  together. That's fantastic!
-
-  This development notwithstanding, we still follow our ambition to bring the
-  support for the other kernels like seL4 on par with NOVA to give Genode
-  users the ultimate choice.
-  Speaking of seL4, throughout the year, we have continuously adapted Genode
-  to the kernel's upstream development and enjoy the informal collaboration
-  with seL4 developer community. That said, the seL4 version of Genode still
-  remains a side activity with no commercial backing.
-
-:NXP i.MX: support has become much better, particularly with respect to
-  network support and performance. Our ongoing commitment to the i.MX
-  platform is also fueled by privacy-advocating projects like the Librem
-  phone that are based on the same SoC.
-
-:Software quality and resilience: ultimately became the title story of the
-  [https://genode.org/documentation/release-notes/18.11#Raising_the_bar_of_quality_assurance - release 18.11].
-  We greatly intensified the amount and quality of testing, explored static
-  code analysis, and vastly scaled up the complexity of workloads carried
-  by Genode.
-
-:System monitoring, tracing, profiling: remains a somewhat underdeveloped area
-  of Genode. As a step in the right direction, we introduced a simple
-  trace-logging tool. Also, Sculpt's introspection features like the ability
-  to inspect the runtime's state live on the machine make Genode's behavior
-  easier to capture and to understand. But that said, the use of these
-  features remains a black art mastered only by a few.
-
-:Java: has found its way into Genode via our port of OpenJDK. Details such as
-  the enabling of the JIT engine on ARM took much more effort than anticipated.
-  We are happy to report that Tomcat works fine. But at the current state, it
-  is still too early to advertise Java as a stable feature.
+Over the course of 2019, we admittedly skipped a few topics originally
+mentioned on our road map. In particular, the user-visible side of
+Sculpt OS received less attention than originally envisioned. We also
+deferred several ideas we had in mind about reworking our GUI stack.
+Instead, we expanded our work in the areas of storage (block-level APIs,
+test infrastructure,
+[https://genode.org/documentation/release-notes/19.11#Preliminary_block-device_encrypter - block encryption])
+and
+[https://genode.org/documentation/release-notes/19.08#Flexible_keyboard_layouts - input processing].
+This shift of focus is mostly attributed to the priorities of Genode Labs'
+customers who fund our work.
 
 
-2019 - Bridging Worlds
-######################
+2020 - Dwarfing the barrier of entry
+####################################
 
-We dedicated the year 2018 to prove that Genode scales to general-purpose
-computing. [https://genode.org/download/sculpt - Sculpt OS] leaves no doubt
-about that. The logical next step is to make Sculpt OS relevant and appealing
-for a broader community.
-During our public road-map
-[https://lists.genode.org/pipermail/users/2018-December/006517.html - discussion]
-on our mailing list, we identified three ways towards that goal:
+Genode as a technology is there. For more than one decade, we walked unfathomed
+territory, fought with countless deep rabbit holes, took risky decisions,
+tracked back, explored design spaces, developed taste and distaste, pruned
+technical debt, and eventually found formulas of success. Today, there are no
+(fundamental) unsolved questions. All the puzzle pieces are in place. There
+could be no better proof than our daily use of Sculpt OS. The time is right
+to make Genode palatable for a wider circle. We identified four actionable
+topics to achieve that.
 
-# In order to capture the interest of new Genode users, we have to
-  put *emphasis on the practical use* of Genode, not on its technical prowess.
-  With practical use, we refer to both desktop computing and headless
-  scenarios like network appliances and servers. Over the course of 2019,
-  we plan to establish (variations of) Sculpt as an attractive foundation for
-  those application areas, and advance Genode's protocol stacks (storage and
-  encryption come in mind) and hardware support (e.g., ARM 64-bit) accordingly.
+:User friendliness of Sculpt OS:
 
-  This will go hand in hand with making Genode easier to discover and to use,
-  describing use cases at a digestible level of detail, and fostering the
-  sense of one community that includes both users and developers.
+  Until now, Sculpt OS is not exactly friendly towards users who are
+  unfamiliar with the Unix command-line tools. Since Sculpt is not Unix
+  based, this is a bit paradoxical. 2020 will give Sculpt OS a friendlier
+  and discoverable user experience. In this context, we will inevitably
+  put our attention to Genode's GUI stack.
 
-# Since an operating system is only valuable with applications, we have
-  to make the *porting of existing software* and the use of popular
-  *programming languages* a frictionless experience. Besides supporting the
-  reuse of existing software, we should also cultivate the "Genode way" as
-  an option for designing native applications. Such applications can
-  leverage the unique capabilities of the framework, in particular the
-  sandboxing of code at a very fine granularity and the low footprint of raw
-  Genode components.
+:Perception of high quality:
 
-# Because an operating system does not exist in isolation, we must foster
-  Genode's *interoperability* with other systems and applications by speaking
-  widely used protocols and supporting universally expected
-  software-integration features.
+  Compared to commodity operating systems who stood the test of time,
+  Genode is a young and largely unproven technology. It understandably calls
+  for skepticism. All the more we must leave no doubts about our high
+  quality standards. There must be no room for uncertainty. Hence, during
+  2020, we will intensify the consolidation and optimization of the framework
+  and its API, and talk about it.
+
+:Enjoyable tooling:
+
+  Genode's success at large will depend on developers. As of today, software
+  development for Genode requires a huge up-front learning curve. This is
+  fine for people who are already convinced of Genode. But it unacceptable
+  for casual developers who want to get their toes wet. We should aim for
+  tooling that allows new developers to keep up their flow and beloved
+  tools. The recently introduced [https://genodians.org/nfeske/2019-11-25-goa - Goa]
+  tooling is our first take in this respect. It is certainly too early to call
+  Goa a success. In order to find out if we are on the right track, we want to
+  expose Goa to as many problems as possible, primarily by the means of
+  porting software. Also, things like IDE usage or adapters for a variety of
+  build systems will certainly move into focus in 2020.
+
+:Convincing use cases:
+
+  Use cases can give exemplary proof of the fitness of Genode. We already
+  took a few baby steps to extend the range of documented use cases beyond
+  Sculpt OS last year. The boot2java scenenario comes in mind. 2020 will
+  hopefully see several more illustrations of Genode's versatility.
 
 
-Milestones for 2019
+Apart from this overall theme, we plan to continue our commitment to the
+NXP i.MX SoC family, revisit Genode's low-latency audio support, and
+extend the cultivation of Ada/SPARK within (and on top of) Genode.
+
+
+Milestones for 2020
 ###################
 
 In the following, we present a rough schedule of the planned work. As usual,
@@ -137,57 +136,64 @@ it is not set in stone. If you are interested in a particular line of work,
 please get in touch.
 
 
-February - Release 19.02
+February - Release 20.02
 ========================
 
-* OpenJDK with JIT on ARM and x86
-* Sculpt with support for online package discovery
-* Showcase of a Genode-based web appliance
-* Showcase of a multi-port network appliance
+* Consolidation: removal of the Noux runtime
+* Library version of the init component
+* Updated audio drivers
+* Sculpt
+  * 64-bit ARM (i.MX8)
+  * Revised administrative user interface
+  * System image without Unix tools
 
 
-May - Release 19.05
+May - Release 20.05
 ===================
 
 * Updated "Genode Foundations" book
-* Tool-chain update and SDK (C++-17, enabling O3 by default, considering GDC)
-* Headless Sculpt
-  * Pluggable network drivers
-  * Native support for Let's Encrypt certificates
-* Revisited GUI-related framework interfaces
+* Consolidation
+  * Block-level components (update to Genode's modern block APIs)
+  * ARM device drivers (introducing the notion of a platform driver)
+  * Improved STL support (e.g., threading and mutexes)
+  * Continuous POSIX-compliance testing
+  * Systematic network-stack stress and performance tests
+* Desktop: panel and virtual desktops
+* Use case: Genode-based network router
+* Goa: broadened support for 3rd-party build systems
+* Native tool chain, including Git
 * Sculpt
-  * Improved interactive system composition
-  * Passphrase handling
-  * Clipboard support
-* Kernel-agnostic virtual-machine monitors
-* ARM 64-bit
+  * Interactive device management
+  * Keyboard-controlled administration
+* Support for BSPs maintained outside of Genode's mainline repository
 
 
-August - Release 19.08
+August - Release 20.08
 ======================
 
-* Interactive tracing tool
-* Virtualization support for the base-hw kernel on x86
-* Library version of the init component
+* Revisited GUI-related framework interfaces
+* Extended tooling for performance monitoring
+* Goa: Qt development workflow
+* Desktop
+  * Native mail client
+  * Native web browser
 * Sculpt
-  * Fine-grained USB-device policies
-  * Interactive depot manager (ability to add/remove software providers)
-  * Configuration of CPU affinities and scheduling priorities
-  * Audio
-* Showcase of a Sculpt-based network router
-* VM-based desktop applications (enhanced VM integration features)
-* Updated Qt5
-* Consolidation of the Noux runtime (performance)
+  * Configurable CPU resources
+  * On-screen documentation
+  * Block encryption via our
+    [https://genode.org/documentation/release-notes/19.11#Preliminary_block-device_encrypter - consistent block encrypter]
+    implemented in Ada/SPARK
+* USB audio
+* Initial version of a kernel implemented in Ada/SPARK
 
 
-November - Release 19.11
+November - Release 20.11
 ========================
 
-* Building Genode packages directly on Sculpt
-* VNC server support
-* Sculpt
-  * On-target debugging of components
-  * Shutdown protocol
-* Block-level encrypted storage
-* Drag-and-drop protocol
+* Consolidation of capability-space management across kernels
+* CPU-load balancing
+* Hardware-accelerated graphics on i.MX8 (experimental)
+* Reworked audio stack (interfaces, mixing)
+* Sculpt: component lifetime management, shutdown protocol
+* VFS plugins for lwext4 and FUSE-based file systems
 

repos/base-fiasco/lib/mk/base-fiasco-common.mk

@@ -10,5 +10,7 @@ LIBS += startup-fiasco syscall-fiasco
 
 SRC_CC += capability.cc capability_raw.cc
 SRC_CC += rpc_dispatch_loop.cc
+SRC_CC += rpc_entrypoint_manage.cc
 SRC_CC += thread.cc thread_bootstrap.cc thread_myself.cc
 SRC_CC += stack_area_addr.cc
+SRC_CC += rpc_entry.cc

repos/base-fiasco/lib/mk/base-fiasco.mk

@@ -6,3 +6,4 @@ SRC_CC += thread_start.cc
 SRC_CC += cache.cc
 SRC_CC += capability_space.cc
 SRC_CC += signal_transmitter.cc signal.cc
+SRC_CC += platform.cc

repos/base-fiasco/recipes/src/base-fiasco/hash

@@ -1 +1 @@
-2019-07-08 1b0e1040842b8f9a8f547f47e1fe8b859383525a
+2020-02-27 6311f83c887384fa01828af695bae799b148e0ad

repos/base-fiasco/src/core/thread_start.cc

@@ -29,7 +29,7 @@ void Thread::_thread_start()
 {
 	Thread::myself()->_thread_bootstrap();
 	Thread::myself()->entry();
-	Thread::myself()->_join_lock.unlock();
+	Thread::myself()->_join.wakeup();
 	sleep_forever();
 }
 

repos/base-fiasco/src/lib/base/ipc.cc

@@ -201,16 +201,14 @@ void Genode::ipc_reply(Native_capability caller, Rpc_exception_code exc,
 	            snd_header.protocol_word,
 	            snd_header.num_caps,
 	            L4_IPC_SEND_TIMEOUT_0, &result);
-
-	if (L4_IPC_IS_ERROR(result))
-		error("ipc_send error ", Hex(L4_IPC_ERROR(result)), ", ignored");
 }
 
 
-Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &last_caller,
-                                           Rpc_exception_code      exc,
-                                           Msgbuf_base            &reply_msg,
-                                           Msgbuf_base            &request_msg)
+Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const         &last_caller,
+                                           Rpc_exception_code              exc,
+                                           Msgbuf_base                    &reply_msg,
+                                           Msgbuf_base                    &request_msg,
+                                           Rpc_entrypoint::Native_context &)
 {
 	using namespace Fiasco;
 
@@ -277,9 +275,10 @@ Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &last_caller,
 }
 
 
-Ipc_server::Ipc_server()
+Ipc_server::Ipc_server(Rpc_entrypoint::Native_context& native_context)
 :
-	Native_capability(Capability_space::import(Fiasco::l4_myself(), Rpc_obj_key()))
+	Native_capability(Capability_space::import(Fiasco::l4_myself(), Rpc_obj_key())),
+	_native_context(native_context)
 { }
 
 

repos/base-fiasco/src/lib/base/lock.cc

@@ -13,6 +13,7 @@
 
 /* Genode includes */
 #include <base/cancelable_lock.h>
+#include <base/thread.h>
 #include <cpu/atomic.h>
 #include <cpu/memory_barrier.h>
 
@@ -33,6 +34,13 @@ Cancelable_lock::Cancelable_lock(Cancelable_lock::State initial)
 
 
 void Cancelable_lock::lock()
+{
+	Applicant myself(Thread::myself());
+	lock(myself);
+}
+
+
+void Cancelable_lock::lock(Applicant &myself)
 {
 	/*
 	 * XXX: How to notice cancel-blocking signals issued when  being outside the
@@ -41,11 +49,14 @@ void Cancelable_lock::lock()
 	while (!Genode::cmpxchg(&_state, UNLOCKED, LOCKED))
 		if (Fiasco::l4_ipc_sleep(Fiasco::l4_ipc_timeout(0, 0, 500, 0)) != L4_IPC_RETIMEOUT)
 			throw Genode::Blocking_canceled();
+
+	_owner = myself;
 }
 
 
 void Cancelable_lock::unlock()
 {
+	_owner = Applicant(nullptr);
 	Genode::memory_barrier();
 	_state = UNLOCKED;
 }

repos/base-foc/lib/mk/base-foc-common.inc

@@ -10,6 +10,9 @@ LIBS += syscall-foc startup-foc
 
 SRC_CC += spin_lock.cc cap_map.cc
 SRC_CC += rpc_dispatch_loop.cc
+SRC_CC += rpc_entrypoint_manage.cc
 SRC_CC += thread.cc thread_bootstrap.cc thread_myself.cc utcb.cc
 SRC_CC += capability.cc
 SRC_CC += signal_source_client.cc
+SRC_CC += platform.cc
+SRC_CC += rpc_entry.cc

repos/base-foc/recipes/src/base-foc-arndale/base-foc-pbxa9/README

@@ -1,7 +0,0 @@
-This archive contains the Fiasco.OC-specific part of Genode.
-
-It also contains the source code of the Fiasco.OC kernel in the
-'src/kernel/foc' directory.
-
-Please note that Fiasco.OC has a license distinct from Genode. Fiasco.OC's
-license can be found at 'src/kernel/foc/COPYING-GPL-2'.

repos/base-foc/recipes/src/base-foc-arndale/base-foc-pbxa9/content.mk

@@ -1,7 +0,0 @@
-RECIPE_DIR := $(REP_DIR)/recipes/src/base-foc-pbxa9
-
-include $(GENODE_DIR)/repos/base-foc/recipes/src/base-foc_content.inc
-
-content: enable_board_spec
-enable_board_spec: etc/specs.conf
-	echo "SPECS += pbxa9" >> etc/specs.conf

repos/base-foc/recipes/src/base-foc-arndale/base-foc-pbxa9/hash

@@ -1 +0,0 @@
-2018-11-14 778d83a4be78dcd6d1e4d45f1ca103def7b298a5

repos/base-foc/recipes/src/base-foc-arndale/hash

@@ -1 +1 @@
-2019-07-08 f3bfd189708c82317b021ffdc53ba80128037465
+2020-02-27 82bbd7275951340ff82061af8bc2cce41f1519e3

repos/base-foc/recipes/src/base-foc-imx6q_sabrelite/hash

@@ -1 +1 @@
-2019-07-08 87f41f86afb0c19e5682e2e2d41ed182f9334ef1
+2020-02-27 c5602daf28cdc5d005a26f408527e64ab905197e

repos/base-foc/recipes/src/base-foc-imx7d_sabre/hash

@@ -1 +1 @@
-2019-07-08 d370ecc4cb2ce3f370cfaefecbf97a1c05ef3e69
+2020-02-27 a3912478467dcf01ab6379502bb15719b748c388

repos/base-foc/recipes/src/base-foc-pbxa9/hash

@@ -1 +1 @@
-2019-07-08 075559ecf0b1206c45de3fc7ccd9b6198bd41d41
+2020-02-27 e7f8bca57dbed6597e46aafd0256dfd5a6ac42c3

repos/base-foc/recipes/src/base-foc-pc/hash

@@ -1 +1 @@
-2019-07-08 536625983e4733b833706e59c35591fe5d06020c
+2020-02-27 b03dfe2bde7fe637c0a7eff9e709845e64b4d09c

repos/base-foc/recipes/src/base-foc-rpi3/hash

@@ -1 +1 @@
-2019-07-08 5f648e24bfed0e532ad659cc87d8cf60a11efe05
+2020-02-27 a1eb6dfc01d82b598f0778c0b74f2a49387cc42d

repos/base-foc/recipes/src/base-foc_content.inc

@@ -23,7 +23,9 @@ src/kernel:
 KERNEL_PORT_DIR := $(call port_dir,$(REP_DIR)/ports/foc)
 
 src/kernel/foc: src/kernel
-	cp -r $(KERNEL_PORT_DIR)/src/kernel/foc/* $@
+	tar -C $(KERNEL_PORT_DIR)/src/kernel/foc --exclude=.git -cf - . |\
+		tar -C $@ -xf -
+
 
 content:
 	for spec in x86_32 x86_64 arm arm_64; do \

repos/base-foc/src/core/include/vm_session_component.h

@@ -108,7 +108,7 @@ class Genode::Vm_session_component
 		void attach(Dataspace_capability, addr_t, Attach_attr) override;
 		void attach_pic(addr_t) override { }
 		void detach(addr_t, size_t) override;
-		void _create_vcpu(Thread_capability);
+		Vcpu_id _create_vcpu(Thread_capability);
 };
 
 #endif /* _CORE__VM_SESSION_COMPONENT_H_ */

repos/base-foc/src/core/ipc_pager.cc

@@ -36,7 +36,7 @@ void Ipc_pager::_parse(unsigned long label) {
 	if (_type == PAGEFAULT || _type == EXCEPTION)
 		_parse_pagefault();
 	if (_type == PAUSE || _type == EXCEPTION)
-		memcpy(&_regs, l4_utcb_exc(), sizeof(l4_exc_regs_t));
+		_regs = *l4_utcb_exc();
 }
 
 
@@ -134,7 +134,7 @@ void Ipc_pager::acknowledge_wakeup()
 
 void Ipc_pager::acknowledge_exception()
 {
-	memcpy(l4_utcb_exc(), &_regs, sizeof(l4_exc_regs_t));
+	_regs = *l4_utcb_exc();
 	l4_cap_idx_t dst = Fiasco::Capability::valid(_last.kcap)
 	                 ? _last.kcap : (l4_cap_idx_t)L4_SYSF_REPLY;
 	Fiasco::l4_msgtag_t const msg_tag =

repos/base-foc/src/core/platform.cc

@@ -495,6 +495,10 @@ Platform::Platform() :
 			xml.node("hardware", [&] () {
 				_setup_platform_info(xml, sigma0_map_kip());
 			});
+			xml.node("affinity-space", [&] () {
+				xml.attribute("width", affinity_space().width());
+				xml.attribute("height", affinity_space().height());
+			});
 		});
 
 		_rom_fs.insert(new (core_mem_alloc()) Rom_module(phys_addr, size,

repos/base-foc/src/core/vm_session_component.cc

@@ -107,10 +107,12 @@ Vcpu::~Vcpu()
 		_ram_alloc.free(_ds_cap);
 }
 
-void Vm_session_component::_create_vcpu(Thread_capability cap)
+Vm_session::Vcpu_id Vm_session_component::_create_vcpu(Thread_capability cap)
 {
+	Vcpu_id ret;
+
 	if (!cap.valid())
-		return;
+		return ret;
 
 	auto lambda = [&] (Cpu_thread_component *thread) {
 		if (!thread)
@@ -146,10 +148,11 @@ void Vm_session_component::_create_vcpu(Thread_capability cap)
 		}
 
 		_vcpus.insert(vcpu);
-		_id_alloc++;
+		ret.id = _id_alloc++;
 	};
 
 	_ep.apply(cap, lambda);
+	return ret;
 }
 
 Dataspace_capability Vm_session_component::_cpu_state(Vcpu_id const vcpu_id)

repos/base-foc/src/include/base/internal/lock_helper.h

@@ -78,7 +78,7 @@ static inline void thread_switch_to(Genode::Thread *thread_base)
 __attribute__((optimize("-fno-omit-frame-pointer")))
 __attribute__((noinline))
 __attribute__((used))
-static void thread_stop_myself()
+static void thread_stop_myself(Genode::Thread *)
 {
 	using namespace Fiasco;
 

repos/base-foc/src/lib/base/ipc.cc

@@ -238,6 +238,11 @@ static l4_msgtag_t copy_msgbuf_to_utcb(Msgbuf_base &snd_msg,
 		/* setup flexpage for valid capability to delegate */
 		if (caps[i].valid) {
 			unsigned const idx = num_msg_words + 2*num_cap_sel;
+
+			/* check bounds of 'l4_msg_regs_t::mr' */
+			if (idx + 1 >= L4_UTCB_GENERIC_DATA_SIZE)
+				break;
+
 			l4_utcb_mr()->mr[idx]     = L4_ITEM_MAP/* | L4_ITEM_CONT*/;
 			l4_utcb_mr()->mr[idx + 1] = l4_obj_fpage(caps[i].sel,
 			                                         0, L4_FPAGE_RWX).raw;
@@ -311,10 +316,11 @@ void Genode::ipc_reply(Native_capability, Rpc_exception_code exc,
 }
 
 
-Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &,
-                                           Rpc_exception_code      exc,
-                                           Msgbuf_base            &reply_msg,
-                                           Msgbuf_base            &request_msg)
+Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const         &,
+                                           Rpc_exception_code              exc,
+                                           Msgbuf_base                    &reply_msg,
+                                           Msgbuf_base                    &request_msg,
+                                           Rpc_entrypoint::Native_context &)
 {
 	Receive_window &rcv_window = Thread::myself()->native_thread().rcv_window;
 
@@ -365,9 +371,10 @@ Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &,
 }
 
 
-Ipc_server::Ipc_server()
+Ipc_server::Ipc_server(Rpc_entrypoint::Native_context& native_context)
 :
-	Native_capability((Cap_index*)Fiasco::l4_utcb_tcr()->user[Fiasco::UTCB_TCR_BADGE])
+	Native_capability((Cap_index*)Fiasco::l4_utcb_tcr()->user[Fiasco::UTCB_TCR_BADGE]),
+	_native_context(native_context)
 {
 	Thread::myself()->native_thread().rcv_window.init();
 }

repos/base-foc/src/lib/base/thread_bootstrap.cc

@@ -59,6 +59,6 @@ void Genode::Thread::_thread_start()
 
 	Thread::myself()->_thread_bootstrap();
 	Thread::myself()->entry();
-	Thread::myself()->_join_lock.unlock();
+	Thread::myself()->_join.wakeup();
 	sleep_forever();
 }

repos/base-foc/src/lib/base/x86/vm_session.cc

@@ -50,7 +50,6 @@ static bool svm_np() { return svm_features() & (1U << 0); }
 struct Vcpu;
 
 static Genode::Registry<Genode::Registered<Vcpu> > vcpus;
-static unsigned vcpu_id = 0;
 
 struct Vcpu : Genode::Thread
 {
@@ -202,7 +201,7 @@ struct Vcpu : Genode::Thread
 		Semaphore                   _wake_up { 0 };
 		Semaphore                  &_handler_ready;
 		Allocator                  &_alloc;
-		Vm_session_client::Vcpu_id  _id;
+		Vm_session_client::Vcpu_id  _id { Vm_session_client::Vcpu_id::INVALID };
 		addr_t                      _state { 0 };
 		addr_t                      _task { 0 };
 		enum Virt const             _vm_type;
@@ -1184,20 +1183,20 @@ struct Vcpu : Genode::Thread
 	public:
 
 		Vcpu(Env &env, Signal_context_capability &cap,
-		     Semaphore &handler_ready,
-		     Vm_session_client::Vcpu_id &id, enum Virt type,
+		     Semaphore &handler_ready, enum Virt type,
 		     Allocator &alloc, Affinity::Location location)
 		:
 			Thread(env, "vcpu_thread", STACK_SIZE, location, Weight(), env.cpu()),
 			_signal(cap), _handler_ready(handler_ready), _alloc(alloc),
-			_id(id), _vm_type(type)
+			_vm_type(type)
 		{ }
 
 		Allocator &allocator() const { return _alloc; }
 
 		bool match(Vm_session_client::Vcpu_id id) { return id.id == _id.id; }
 
-		Genode::Vm_session_client::Vcpu_id id() const { return _id; }
+		Genode::Vm_session_client::Vcpu_id id() const  { return _id; }
+		void id(Genode::Vm_session_client::Vcpu_id id) { _id = id;   }
 
 		void assign_ds_state(Region_map &rm, Dataspace_capability cap)
 		{
@@ -1266,12 +1265,10 @@ Vm_session_client::Vcpu_id
 Vm_session_client::create_vcpu(Allocator &alloc, Env &env,
                                Vm_handler_base &handler)
 {
-	Vm_session_client::Vcpu_id id = { vcpu_id };
-
 	enum Virt vm_type = virt_type(env);
 	if (vm_type == Virt::UNKNOWN) {
 		Genode::error("unsupported hardware virtualisation");
-		return id;
+		return Vm_session::Vcpu_id();
 	}
 
 	Thread * ep = reinterpret_cast<Thread *>(&handler._rpc_ep);
@@ -1279,17 +1276,17 @@ Vm_session_client::create_vcpu(Allocator &alloc, Env &env,
 
 	/* create thread that switches modes between thread/cpu */
 	Vcpu * vcpu = new (alloc) Registered<Vcpu>(vcpus, env, handler._cap,
-	                                           handler._done, id, vm_type,
+	                                           handler._done, vm_type,
 	                                           alloc, location);
 
 	try {
 		/* now it gets actually valid - vcpu->cap() becomes valid */
 		vcpu->start();
 
-		call<Rpc_exception_handler>(handler._cap, vcpu->id());
-
 		/* instruct core to let it become a vCPU */
-		call<Rpc_create_vcpu>(vcpu->cap());
+		vcpu->id(call<Rpc_create_vcpu>(vcpu->cap()));
+
+		call<Rpc_exception_handler>(handler._cap, vcpu->id());
 
 		vcpu->assign_ds_state(env.rm(), call<Rpc_cpu_state>(vcpu->id()));
 	} catch (...) {
@@ -1299,9 +1296,7 @@ Vm_session_client::create_vcpu(Allocator &alloc, Env &env,
 		destroy(alloc, vcpu);
 		throw;
 	}
-
-	vcpu_id ++;
-	return id;
+	return vcpu->id();
 }
 
 void Vm_session_client::run(Vcpu_id vcpu_id)

repos/base-hw/include/spec/arm_64/cpu/vm_state_virtualization.h

@@ -0,0 +1,109 @@
+/*
+ * \brief   CPU, PIC, and timer context of a virtual machine
+ * \author  Stefan Kalkowski
+ * \date    2015-02-10
+ */
+
+/*
+ * Copyright (C) 2015-2017 Genode Labs GmbH
+ *
+ * This file is part of the Genode OS framework, which is distributed
+ * under the terms of the GNU Affero General Public License version 3.
+ */
+
+#ifndef _INCLUDE__SPEC__ARM_64__CPU__VM_STATE_VIRTUALIZATION_H_
+#define _INCLUDE__SPEC__ARM_64__CPU__VM_STATE_VIRTUALIZATION_H_
+
+/* Genode includes */
+#include <cpu/cpu_state.h>
+
+namespace Genode
+{
+	/**
+	 * CPU context of a virtual machine
+	 */
+	struct Vm_state;
+
+	using uint128_t = __uint128_t;
+}
+
+struct Genode::Vm_state : Genode::Cpu_state
+{
+	Genode::uint64_t pstate         { 0 };
+	Genode::uint64_t exception_type { 0 };
+	Genode::uint64_t esr_el2        { 0 };
+
+	/** Fpu registers **/
+	Genode::uint128_t q[32]         { 0 };
+	Genode::uint32_t fpcr           { 0 };
+	Genode::uint32_t fpsr           { 0 };
+
+	Genode::uint64_t elr_el1        { 0 };
+	Genode::uint64_t sp_el1         { 0 };
+	Genode::uint32_t spsr_el1       { 0 };
+	Genode::uint32_t esr_el1        { 0 };
+
+	Genode::uint64_t sctlr_el1      { 0 };
+	Genode::uint64_t actlr_el1      { 0 };
+	Genode::uint64_t vbar_el1       { 0 };
+	Genode::uint32_t cpacr_el1      { 0 };
+	Genode::uint32_t afsr0_el1      { 0 };
+	Genode::uint32_t afsr1_el1      { 0 };
+	Genode::uint32_t contextidr_el1 { 0 };
+
+	Genode::uint64_t ttbr0_el1      { 0 };
+	Genode::uint64_t ttbr1_el1      { 0 };
+	Genode::uint64_t tcr_el1        { 0 };
+	Genode::uint64_t mair_el1       { 0 };
+	Genode::uint64_t amair_el1      { 0 };
+	Genode::uint64_t far_el1        { 0 };
+	Genode::uint64_t par_el1        { 0 };
+
+	Genode::uint64_t tpidrro_el0    { 0 };
+	Genode::uint64_t tpidr_el0      { 0 };
+	Genode::uint64_t tpidr_el1      { 0 };
+
+	Genode::uint64_t vmpidr_el2     { 0 };
+
+	Genode::uint64_t far_el2        { 0 };
+	Genode::uint64_t hpfar_el2      { 0 };
+
+	/**
+	 * Timer related registers
+	 */
+	struct Timer {
+		Genode::uint64_t offset   { 0 };
+		Genode::uint64_t compare  { 0 };
+		Genode::uint32_t control  { 0 };
+		Genode::uint32_t kcontrol { 0 };
+		bool             irq      { false };
+	} timer {};
+
+	/**
+	 * Interrupt related values
+	 */
+	struct Pic
+	{
+		unsigned last_irq    { 1023 };
+		unsigned virtual_irq { 1023 };
+	} irqs {};
+
+	/**************************
+	 ** Platform information **
+	 **************************/
+
+	Genode::uint64_t id_aa64isar0_el1 { 0 };
+	Genode::uint64_t id_aa64isar1_el1 { 0 };
+	Genode::uint64_t id_aa64mmfr0_el1 { 0 };
+	Genode::uint64_t id_aa64mmfr1_el1 { 0 };
+	Genode::uint64_t id_aa64mmfr2_el1 { 0 };
+	Genode::uint64_t id_aa64pfr0_el1  { 0 };
+	Genode::uint64_t id_aa64pfr1_el1  { 0 };
+	Genode::uint64_t id_aa64zfr0_el1  { 0 };
+
+	Genode::uint32_t ccsidr_inst_el1[7] { 0 };
+	Genode::uint32_t ccsidr_data_el1[7] { 0 };
+	Genode::uint64_t clidr_el1          { 0 };
+};
+
+#endif /* _INCLUDE__SPEC__ARM_64__CPU__VM_STATE_VIRTUALIZATION_H_ */

repos/base-hw/lib/mk/base-hw-common.mk

@@ -10,5 +10,7 @@ include $(BASE_DIR)/lib/mk/base-common.inc
 LIBS += syscall-hw
 
 SRC_CC += rpc_dispatch_loop.cc
+SRC_CC += rpc_entrypoint_manage.cc
 SRC_CC += thread.cc thread_myself.cc thread_bootstrap.cc
 SRC_CC += signal_transmitter.cc
+SRC_CC += rpc_entry.cc

repos/base-hw/lib/mk/base-hw.mk

@@ -7,5 +7,6 @@ SRC_CC += raw_write_string.cc
 SRC_CC += signal_receiver.cc
 SRC_CC += stack_area_addr.cc
 SRC_CC += native_utcb.cc
+SRC_CC += platform.cc
 
 LIBS += startup-hw base-hw-common cxx timeout-hw

repos/base-hw/lib/mk/bootstrap-hw.inc

@@ -17,6 +17,7 @@ SRC_CC  += lib/base/heap.cc
 SRC_CC  += lib/base/registry.cc
 SRC_CC  += lib/base/log.cc
 SRC_CC  += lib/base/output.cc
+SRC_CC  += lib/base/raw_output.cc
 SRC_CC  += lib/base/slab.cc
 SRC_CC  += lib/base/sleep.cc
 SRC_CC  += lib/base/sliced_heap.cc

repos/base-hw/lib/mk/core-hw.inc

@@ -52,7 +52,6 @@ SRC_CC += pager.cc
 SRC_CC += _main.cc
 SRC_CC += kernel/cpu.cc
 SRC_CC += kernel/cpu_scheduler.cc
-SRC_CC += kernel/double_list.cc
 SRC_CC += kernel/init.cc
 SRC_CC += kernel/ipc_node.cc
 SRC_CC += kernel/irq.cc

repos/base-hw/lib/mk/spec/arm/core-hw.inc

@@ -17,7 +17,7 @@ SRC_CC += spec/arm/platform_support.cc
 
 # add assembly sources
 SRC_S += spec/arm/crt0.s
-SRC_S += spec/arm/exception_vector.s
+SRC_S += spec/arm/exception_vector.S
 
 vpath spec/32bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
 

repos/base-hw/lib/mk/spec/arm_v6/core-hw-rpi.mk

@@ -9,9 +9,9 @@ INC_DIR += $(REP_DIR)/src/core/spec/rpi
 
 # add C++ sources
 SRC_CC += platform_services.cc
+SRC_CC += spec/arm/bcm2835_pic.cc
+SRC_CC += spec/arm/bcm2835_system_timer.cc
 SRC_CC += spec/arm/cpu.cc
-SRC_CC += spec/rpi/timer.cc
-SRC_CC += spec/rpi/pic.cc
 
 # include less specific configuration
 include $(REP_DIR)/lib/mk/spec/arm_v6/core-hw.inc

repos/base-hw/lib/mk/spec/arm_v7/bootstrap-hw-arndale.mk

@@ -1,7 +1,7 @@
 INC_DIR += $(BASE_DIR)/../base-hw/src/bootstrap/spec/arndale
 
 SRC_CC  += bootstrap/spec/arm/cortex_a15_cpu.cc
-SRC_CC  += bootstrap/spec/arndale/pic.cc
+SRC_CC  += bootstrap/spec/arm/gicv2.cc
 SRC_CC  += bootstrap/spec/arndale/platform.cc
 SRC_CC  += bootstrap/spec/arm/arm_v7_cpu.cc
 SRC_CC  += hw/spec/32bit/memory_map.cc

repos/base-hw/lib/mk/spec/arm_v7/bootstrap-hw-imx6q_sabrelite.mk

@@ -4,7 +4,7 @@ SRC_S   += bootstrap/spec/arm/crt0.s
 
 SRC_CC  += bootstrap/spec/arm/cpu.cc
 SRC_CC  += bootstrap/spec/arm/cortex_a9_mmu.cc
-SRC_CC  += bootstrap/spec/arm/pic.cc
+SRC_CC  += bootstrap/spec/arm/gicv2.cc
 SRC_CC  += bootstrap/spec/arm/imx6_platform.cc
 SRC_CC  += bootstrap/spec/arm/arm_v7_cpu.cc
 SRC_CC  += hw/spec/32bit/memory_map.cc

repos/base-hw/lib/mk/spec/arm_v7/bootstrap-hw-imx7d_sabre.mk

@@ -1,7 +1,7 @@
 INC_DIR += $(BASE_DIR)/../base-hw/src/bootstrap/spec/imx7d_sabre
 
 SRC_CC  += bootstrap/spec/arm/cortex_a15_cpu.cc
-SRC_CC  += bootstrap/spec/arndale/pic.cc
+SRC_CC  += bootstrap/spec/arm/gicv2.cc
 SRC_CC  += bootstrap/spec/imx7d_sabre/platform.cc
 SRC_CC  += bootstrap/spec/arm/arm_v7_cpu.cc
 SRC_CC  += hw/spec/32bit/memory_map.cc

repos/base-hw/lib/mk/spec/arm_v7/bootstrap-hw-nit6_solox.mk

@@ -4,7 +4,7 @@ SRC_S   += bootstrap/spec/arm/crt0.s
 
 SRC_CC  += bootstrap/spec/arm/cpu.cc
 SRC_CC  += bootstrap/spec/arm/cortex_a9_mmu.cc
-SRC_CC  += bootstrap/spec/arm/pic.cc
+SRC_CC  += bootstrap/spec/arm/gicv2.cc
 SRC_CC  += bootstrap/spec/arm/imx6_platform.cc
 SRC_CC  += bootstrap/spec/arm/arm_v7_cpu.cc
 SRC_CC  += hw/spec/32bit/memory_map.cc

repos/base-hw/lib/mk/spec/arm_v7/bootstrap-hw-odroid_xu.mk

@@ -1,7 +1,7 @@
 INC_DIR += $(BASE_DIR)/../base-hw/src/bootstrap/spec/odroid_xu
 
 SRC_CC  += bootstrap/spec/arm/cortex_a15_cpu.cc
-SRC_CC  += bootstrap/spec/arm/pic.cc
+SRC_CC  += bootstrap/spec/arm/gicv2.cc
 SRC_CC  += bootstrap/spec/odroid_xu/platform.cc
 SRC_CC  += bootstrap/spec/arm/arm_v7_cpu.cc
 SRC_CC  += hw/spec/32bit/memory_map.cc

repos/base-hw/lib/mk/spec/arm_v7/bootstrap-hw-panda.mk

@@ -3,7 +3,7 @@ NR_OF_CPUS = 2
 INC_DIR   += $(BASE_DIR)/../base-hw/src/bootstrap/spec/panda
 SRC_CC    += bootstrap/spec/arm/cpu.cc
 SRC_CC    += bootstrap/spec/arm/cortex_a9_mmu.cc
-SRC_CC    += bootstrap/spec/arm/pic.cc
+SRC_CC    += bootstrap/spec/arm/gicv2.cc
 SRC_CC    += bootstrap/spec/panda/platform.cc
 SRC_CC    += bootstrap/spec/arm/arm_v7_cpu.cc
 SRC_CC    += hw/spec/32bit/memory_map.cc

repos/base-hw/lib/mk/spec/arm_v7/bootstrap-hw-pbxa9.mk

@@ -4,7 +4,7 @@ SRC_S   += bootstrap/spec/arm/crt0.s
 
 SRC_CC  += bootstrap/spec/arm/cpu.cc
 SRC_CC  += bootstrap/spec/arm/cortex_a9_mmu.cc
-SRC_CC  += bootstrap/spec/arm/pic.cc
+SRC_CC  += bootstrap/spec/arm/gicv2.cc
 SRC_CC  += bootstrap/spec/pbxa9/platform.cc
 SRC_CC  += bootstrap/spec/arm/arm_v7_cpu.cc
 SRC_CC  += hw/spec/32bit/memory_map.cc

repos/base-hw/lib/mk/spec/arm_v7/bootstrap-hw-wand_quad.mk

@@ -4,7 +4,7 @@ SRC_S   += bootstrap/spec/arm/crt0.s
 
 SRC_CC  += bootstrap/spec/arm/cpu.cc
 SRC_CC  += bootstrap/spec/arm/cortex_a9_mmu.cc
-SRC_CC  += bootstrap/spec/arm/pic.cc
+SRC_CC  += bootstrap/spec/arm/gicv2.cc
 SRC_CC  += bootstrap/spec/arm/imx6_platform.cc
 SRC_CC  += bootstrap/spec/arm/arm_v7_cpu.cc
 SRC_CC  += hw/spec/32bit/memory_map.cc

repos/base-hw/lib/mk/spec/arm_v7/bootstrap-hw-zynq_qemu.mk

@@ -4,7 +4,7 @@ SRC_S   += bootstrap/spec/arm/crt0.s
 
 SRC_CC  += bootstrap/spec/arm/cpu.cc
 SRC_CC  += bootstrap/spec/arm/cortex_a9_mmu.cc
-SRC_CC  += bootstrap/spec/arm/pic.cc
+SRC_CC  += bootstrap/spec/arm/gicv2.cc
 SRC_CC  += bootstrap/spec/zynq/platform.cc
 SRC_CC  += bootstrap/spec/arm/arm_v7_cpu.cc
 SRC_CC  += hw/spec/32bit/memory_map.cc

repos/base-hw/lib/mk/spec/arm_v7/core-hw-arndale.mk

@@ -6,16 +6,16 @@
 
 # add include paths
 INC_DIR += $(REP_DIR)/src/core/spec/arndale
-INC_DIR += $(REP_DIR)/src/core/spec/arm_v7/virtualization
+INC_DIR += $(REP_DIR)/src/core/spec/arm/virtualization
 
 # add C++ sources
-SRC_CC += spec/arm_gic/pic.cc
-SRC_CC += spec/arndale/platform_services.cc
 SRC_CC += kernel/vm_thread_on.cc
+SRC_CC += spec/arm/gicv2.cc
 SRC_CC += spec/arm_v7/virtualization/kernel/vm.cc
-SRC_CC += spec/arm_v7/vm_session_component.cc
-SRC_CC += spec/arm_v7/virtualization/vm_session_component.cc
+SRC_CC += spec/arm/virtualization/platform_services.cc
+SRC_CC += spec/arm/virtualization/vm_session_component.cc
 SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 # add assembly sources
 SRC_S += spec/arm_v7/virtualization/exception_vector.s

repos/base-hw/lib/mk/spec/arm_v7/core-hw-imx53_qsb.inc

@@ -9,8 +9,8 @@
 INC_DIR += $(REP_DIR)/src/core/spec/imx53_qsb
 INC_DIR += $(REP_DIR)/src/core/spec/imx53
 
-SRC_CC += spec/imx53/pic.cc
-SRC_CC += spec/imx53/timer.cc
+SRC_CC += spec/arm/imx_epit.cc
+SRC_CC += spec/arm/imx_tzic.cc
 
 # include less specific configuration
 include $(REP_DIR)/lib/mk/spec/cortex_a8/core-hw.inc

repos/base-hw/lib/mk/spec/arm_v7/core-hw-imx53_qsb_tz.mk

@@ -1,11 +1,12 @@
 INC_DIR += $(REP_DIR)/src/core/spec/arm_v7/trustzone
 INC_DIR += $(REP_DIR)/src/core/spec/imx53/trustzone
 
-SRC_CC += spec/imx53/trustzone/platform_services.cc
 SRC_CC += kernel/vm_thread_on.cc
 SRC_CC += spec/arm_v7/trustzone/kernel/vm.cc
-SRC_CC += spec/arm_v7/vm_session_component.cc
+SRC_CC += spec/arm_v7/trustzone/platform_services.cc
 SRC_CC += spec/arm_v7/trustzone/vm_session_component.cc
+SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 SRC_S += spec/arm_v7/trustzone/exception_vector.s
 

repos/base-hw/lib/mk/spec/arm_v7/core-hw-imx7d_sabre.mk

@@ -6,17 +6,18 @@
 
 # add include paths
 INC_DIR += $(REP_DIR)/src/core/spec/imx7d_sabre
-INC_DIR += $(REP_DIR)/src/core/spec/arm_v7/virtualization
+INC_DIR += $(REP_DIR)/src/core/spec/arm/virtualization
 
 # add C++ sources
-SRC_CC += spec/arm_gic/pic.cc
-SRC_CC += spec/arndale/platform_services.cc
-SRC_CC += spec/imx7d_sabre/timer.cc
 SRC_CC += kernel/vm_thread_on.cc
+SRC_CC += spec/arm/generic_timer.cc
+SRC_CC += spec/arm/gicv2.cc
 SRC_CC += spec/arm_v7/virtualization/kernel/vm.cc
-SRC_CC += spec/arm_v7/vm_session_component.cc
-SRC_CC += spec/arm_v7/virtualization/vm_session_component.cc
+SRC_CC += spec/arm/virtualization/gicv2.cc
+SRC_CC += spec/arm/virtualization/platform_services.cc
+SRC_CC += spec/arm/virtualization/vm_session_component.cc
 SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 # add assembly sources
 SRC_S += spec/arm_v7/virtualization/exception_vector.s

repos/base-hw/lib/mk/spec/arm_v7/core-hw-odroid_xu.mk

@@ -8,7 +8,7 @@
 INC_DIR += $(REP_DIR)/src/core/spec/odroid_xu
 
 # add C++ sources
-SRC_CC += spec/arm_gic/pic.cc
+SRC_CC += spec/arm/gicv2.cc
 SRC_CC += kernel/vm_thread_off.cc
 SRC_CC += platform_services.cc
 

repos/base-hw/lib/mk/spec/arm_v7/core-hw-usb_armory.mk

@@ -11,13 +11,14 @@ INC_DIR += $(REP_DIR)/src/core/spec/arm_v7/trustzone
 INC_DIR += $(REP_DIR)/src/core/spec/imx53/trustzone
 
 # add C++ sources
-SRC_CC += spec/imx53/trustzone/platform_services.cc
 SRC_CC += kernel/vm_thread_on.cc
+SRC_CC += spec/arm/imx_epit.cc
+SRC_CC += spec/arm/imx_tzic.cc
 SRC_CC += spec/arm_v7/trustzone/kernel/vm.cc
-SRC_CC += spec/arm_v7/vm_session_component.cc
+SRC_CC += spec/arm_v7/trustzone/platform_services.cc
 SRC_CC += spec/arm_v7/trustzone/vm_session_component.cc
-SRC_CC += spec/imx53/pic.cc
-SRC_CC += spec/imx53/timer.cc
+SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 # add assembly sources
 SRC_S += spec/arm_v7/trustzone/exception_vector.s

repos/base-hw/lib/mk/spec/arm_v8/bootstrap-hw-imx8q_evk.mk

@@ -0,0 +1,14 @@
+INC_DIR += $(BASE_DIR)/../base-hw/src/bootstrap/spec/imx8q_evk
+
+SRC_CC  += bootstrap/spec/arm/gicv3.cc
+SRC_CC  += bootstrap/spec/arm_64/cortex_a53_mmu.cc
+SRC_CC  += bootstrap/spec/imx8q_evk/platform.cc
+SRC_CC  += lib/base/arm_64/kernel/interface.cc
+SRC_CC  += spec/64bit/memory_map.cc
+SRC_S   += bootstrap/spec/arm_64/crt0.s
+
+NR_OF_CPUS = 4
+
+vpath spec/64bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
+
+include $(BASE_DIR)/../base-hw/lib/mk/bootstrap-hw.inc

repos/base-hw/lib/mk/spec/arm_v8/bootstrap-hw-rpi3.mk

@@ -1,10 +1,13 @@
 INC_DIR += $(BASE_DIR)/../base-hw/src/bootstrap/spec/rpi3
 
+SRC_CC  += bootstrap/spec/arm_64/cortex_a53_mmu.cc
+SRC_CC  += bootstrap/spec/rpi3/platform.cc
 SRC_CC  += lib/base/arm_64/kernel/interface.cc
 SRC_CC  += spec/64bit/memory_map.cc
-SRC_CC  += bootstrap/spec/rpi3/platform.cc
 SRC_S   += bootstrap/spec/arm_64/crt0.s
 
 vpath spec/64bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
 
+NR_OF_CPUS = 4
+
 include $(BASE_DIR)/../base-hw/lib/mk/bootstrap-hw.inc

repos/base-hw/lib/mk/spec/arm_v8/core-hw-imx8q_evk.mk

@@ -0,0 +1,32 @@
+INC_DIR += $(REP_DIR)/src/core/spec/imx8q_evk
+INC_DIR += $(REP_DIR)/src/core/spec/arm_v8
+INC_DIR += $(REP_DIR)/src/core/spec/arm/virtualization
+
+# add C++ sources
+SRC_CC += kernel/cpu_mp.cc
+SRC_CC += kernel/vm_thread_on.cc
+SRC_CC += spec/64bit/memory_map.cc
+SRC_CC += spec/arm/generic_timer.cc
+SRC_CC += spec/arm/gicv3.cc
+SRC_CC += spec/arm/kernel/lock.cc
+SRC_CC += spec/arm/platform_support.cc
+SRC_CC += spec/arm_v8/cpu.cc
+SRC_CC += spec/arm_v8/kernel/cpu.cc
+SRC_CC += spec/arm_v8/kernel/thread.cc
+SRC_CC += spec/arm_v8/virtualization/kernel/vm.cc
+SRC_CC += spec/arm/virtualization/platform_services.cc
+SRC_CC += spec/arm/virtualization/vm_session_component.cc
+SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
+
+#add assembly sources
+SRC_S += spec/arm_v8/exception_vector.s
+SRC_S += spec/arm_v8/crt0.s
+SRC_S += spec/arm_v8/virtualization/exception_vector.s
+
+vpath spec/64bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
+
+NR_OF_CPUS = 4
+
+# include less specific configuration
+include $(REP_DIR)/lib/mk/core-hw.inc

repos/base-hw/lib/mk/spec/arm_v8/core-hw-rpi3.mk

@@ -2,17 +2,17 @@ INC_DIR += $(REP_DIR)/src/core/spec/rpi3
 INC_DIR += $(REP_DIR)/src/core/spec/arm_v8
 
 # add C++ sources
-SRC_CC += platform_services.cc
+SRC_CC += kernel/cpu_mp.cc
 SRC_CC += kernel/vm_thread_off.cc
-SRC_CC += kernel/cpu_up.cc
-SRC_CC += kernel/lock.cc
-SRC_CC += spec/arm_v8/cpu.cc
-SRC_CC += spec/arm_v8/kernel/thread.cc
-SRC_CC += spec/arm_v8/kernel/cpu.cc
-SRC_CC += spec/arm/platform_support.cc
-SRC_CC += spec/rpi3/pic.cc
-SRC_CC += spec/rpi3/timer.cc
+SRC_CC += platform_services.cc
 SRC_CC += spec/64bit/memory_map.cc
+SRC_CC += spec/arm/bcm2837_pic.cc
+SRC_CC += spec/arm/generic_timer.cc
+SRC_CC += spec/arm/kernel/lock.cc
+SRC_CC += spec/arm/platform_support.cc
+SRC_CC += spec/arm_v8/cpu.cc
+SRC_CC += spec/arm_v8/kernel/cpu.cc
+SRC_CC += spec/arm_v8/kernel/thread.cc
 
 #add assembly sources
 SRC_S += spec/arm_v8/exception_vector.s
@@ -20,5 +20,7 @@ SRC_S += spec/arm_v8/crt0.s
 
 vpath spec/64bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
 
+NR_OF_CPUS = 4
+
 # include less specific configuration
 include $(REP_DIR)/lib/mk/core-hw.inc

repos/base-hw/lib/mk/spec/cortex_a15/core-hw.inc

@@ -6,7 +6,6 @@
 
 # add include paths
 INC_DIR += $(BASE_DIR)/../base-hw/src/core/spec/cortex_a15
-INC_DIR += $(BASE_DIR)/../base-hw/src/core/spec/arm_gic
 
 # add C++ sources
 SRC_CC += spec/cortex_a15/cpu.cc

repos/base-hw/lib/mk/spec/cortex_a9/core-hw.inc

@@ -6,12 +6,11 @@
 
 # add include paths
 INC_DIR += $(BASE_DIR)/../base-hw/src/core/spec/cortex_a9
-INC_DIR += $(BASE_DIR)/../base-hw/src/core/spec/arm_gic
 
 # add C++ sources
 SRC_CC += spec/cortex_a9/board.cc
-SRC_CC += spec/cortex_a9/timer.cc
-SRC_CC += spec/arm_gic/pic.cc
+SRC_CC += spec/arm/cortex_a9_private_timer.cc
+SRC_CC += spec/arm/gicv2.cc
 SRC_CC += spec/arm/kernel/lock.cc
 SRC_CC += kernel/vm_thread_off.cc
 SRC_CC += kernel/cpu_mp.cc

repos/base-hw/lib/mk/spec/exynos5/core-hw.inc

@@ -8,7 +8,7 @@
 INC_DIR += $(BASE_DIR)/../base-hw/src/core/spec/exynos5
 
 # add C++ sources
-SRC_CC += spec/exynos5/timer.cc
+SRC_CC += spec/arm/exynos_mct.cc
 
 # include less specific configuration
 include $(BASE_DIR)/../base-hw/lib/mk/spec/cortex_a15/core-hw.inc

repos/base-hw/lib/mk/spec/x86_64/bootstrap-hw-muen.mk

@@ -1,3 +1,5 @@
+REQUIRES = muen
+
 INC_DIR += $(BASE_DIR)/../base-hw/src/bootstrap/spec/x86_64
 
 SRC_CC  += bootstrap/spec/x86_64/platform_muen.cc

repos/base-hw/lib/mk/spec/x86_64/core-hw-muen.mk

@@ -35,7 +35,10 @@ SRC_CC += spec/x86_64/muen/platform_services.cc
 SRC_CC += spec/x86_64/muen/platform_support.cc
 SRC_CC += spec/x86_64/muen/sinfo_instance.cc
 SRC_CC += spec/x86_64/muen/timer.cc
+SRC_CC += spec/x86_64/muen/vm_session_component.cc
 SRC_CC += spec/x86_64/platform_support_common.cc
+SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 SRC_CC += spec/64bit/memory_map.cc
 

repos/base-hw/lib/mk/spec/x86_64/core-hw-pc.mk

@@ -17,7 +17,7 @@ SRC_CC += kernel/cpu_mp.cc
 SRC_CC += kernel/vm_thread_off.cc
 SRC_CC += kernel/lock.cc
 SRC_CC += spec/x86_64/pic.cc
-SRC_CC += spec/x86_64/timer.cc
+SRC_CC += spec/x86_64/pit.cc
 SRC_CC += spec/x86_64/kernel/thread_exception.cc
 SRC_CC += spec/x86_64/platform_support.cc
 SRC_CC += spec/x86/platform_services.cc

repos/base-hw/recipes/api/base-hw/hash

@@ -1 +1 @@
-2019-07-08 abc6d82ca4a240319850c788f29cde2655eab1d1
+2019-11-25 6593319a4dec74af9dc15554139e4343ef4312a9

repos/base-hw/recipes/src/base-hw-arndale/content.mk

@@ -1,3 +1,5 @@
+BOARD = arndale
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-arndale/hash

@@ -1 +1 @@
-2019-07-08 9802c13e6c8e2c677636f691c10329b4352388c8
+2020-02-27 e1a80cef41a848e8f63df9a249a4e57148e66331

repos/base-hw/recipes/src/base-hw-imx53_qsb/content.mk

@@ -1,3 +1,5 @@
+BOARD = imx53_qsb
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-imx53_qsb/hash

@@ -1 +1 @@
-2019-07-08 12c1bf367a425f5af5a3309170d930f7db9493c7
+2020-02-27 bd79fb9d11cef09e99ba545408128a605b47814a

repos/base-hw/recipes/src/base-hw-imx53_qsb_tz/content.mk

@@ -1,3 +1,5 @@
+BOARD = imx53_qsb_tz
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-imx53_qsb_tz/hash

@@ -1 +1 @@
-2019-07-08 d22f7b395c0fcfa1c746f32e189d45b644891f93
+2020-02-27 879f89b08454a6aab78bab0c018d1902af792a47

repos/base-hw/recipes/src/base-hw-imx6q_sabrelite/content.mk

@@ -1,3 +1,5 @@
+BOARD = imx6q_sabrelite
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-imx6q_sabrelite/hash

@@ -1 +1 @@
-2019-07-08 c7b0cd5d4ded3e19b53a297062adf53959129317
+2020-02-27 447889337c681d7b9f68c637f9a3eac3abfd2f30

repos/base-hw/recipes/src/base-hw-imx7d_sabre/content.mk

@@ -1,3 +1,5 @@
+BOARD = imx7d_sabre
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-imx7d_sabre/hash

@@ -1 +1 @@
-2019-07-08 83b2c1ef2ef84902f859801d1f16b9d882bcea9f
+2020-02-27 42c284564d38f3bdbd6b30e58280a2f699b657f9

repos/base-hw/recipes/src/base-hw-imx8q_evk/content.mk

@@ -0,0 +1,7 @@
+BOARD = imx8q_evk
+
+include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
+
+content: enable_board_spec
+enable_board_spec: etc/specs.conf
+	echo "SPECS += imx8q_evk" >> etc/specs.conf

repos/base-hw/recipes/src/base-hw-imx8q_evk/hash

@@ -0,0 +1 @@
+2020-02-27 9d9e438a93c416499bb7b414bbcf2de7f2d3650f

repos/base-hw/recipes/src/base-hw-imx8q_evk/used_apis

@@ -0,0 +1,2 @@
+base-hw
+base

repos/base-hw/recipes/src/base-hw-muen/content.mk

@@ -1,3 +1,5 @@
+BOARD = muen
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-muen/hash

@@ -1 +1 @@
-2019-07-08 9e10a06a0fbbe1e3a0e6edfb392548c7c1c3f1de
+2020-02-27 ff3428ffdd5d60514fa5028b003b54327da895ad

repos/base-hw/recipes/src/base-hw-nit6_solox/content.mk

@@ -1,3 +1,5 @@
+BOARD = nit6_solox
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-nit6_solox/hash

@@ -1 +1 @@
-2019-07-08 37b1396eabb3168735dd8b25b6ef8cdd770c4f81
+2020-02-27 84aec73deeae79a6b34374fe859ea5333d05da69

repos/base-hw/recipes/src/base-hw-odroid_xu/content.mk

@@ -1,3 +1,5 @@
+BOARD = odroid_xu
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-odroid_xu/hash

@@ -1 +1 @@
-2019-07-08 bdcc414a1ab3da17995c7c1772d4c5f7a72fd266
+2020-02-27 e87fc4e86962227db5c41bf048eeacf1c27d04c1

repos/base-hw/recipes/src/base-hw-panda/content.mk

@@ -1,3 +1,5 @@
+BOARD = panda
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-panda/hash

@@ -1 +1 @@
-2019-07-08 22d39aab23ce0f611ed0b29e6c06b134a2ef6c6f
+2020-02-27 ebd97e5400e2b99fd810cd233c0f881ede48f376

repos/base-hw/recipes/src/base-hw-pbxa9/content.mk

@@ -1,3 +1,5 @@
+BOARD = pbxa9
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-pbxa9/hash

@@ -1 +1 @@
-2019-07-08 6b4aa21984a425124dd639dfdcb1472fcad707ac
+2020-02-27 5d0722736647b538eb52b35286b7734581402426

repos/base-hw/recipes/src/base-hw-pc/content.mk

@@ -1 +1,3 @@
+BOARD = pc
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc

repos/base-hw/recipes/src/base-hw-pc/hash

@@ -1 +1 @@
-2019-07-08 b6dbf7cadfbd5a6a447cfa16861ff5b93a47f4e9
+2020-02-27 1caed3e6b2d8bc98948b9fd43f3bb26abd52f780

repos/base-hw/recipes/src/base-hw-rpi/content.mk

@@ -1,3 +1,5 @@
+BOARD = rpi
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-rpi/hash

@@ -1 +1 @@
-2019-07-08 9c6fca8b3296f4c43ffb7c861595bc8c339de306
+2020-02-27 6d72eb037774a58fc079c5df7bd5b7348c8799b4

repos/base-hw/recipes/src/base-hw-rpi3/content.mk

@@ -1,3 +1,5 @@
+BOARD = rpi3
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec

repos/base-hw/recipes/src/base-hw-rpi3/hash

@@ -1 +1 @@
-2019-07-08 d4f12ba2b0227a165eaabc7c1d4e427ba15fc8f2
+2020-02-27 41e345219f64781ef6cb472d4f9d374b0295328b

repos/base-hw/recipes/src/base-hw-zynq_qemu/content.mk

@@ -1,3 +1,5 @@
+BOARD = zynq_qemu
+
 include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
 
 content: enable_board_spec