version: 20.05

This also fixes some mixed content pages on genode.org and, thus,
removes the ugly browser warning, e.g., on
https://genode.org/documentation/release-notes/17.05.

LICENSE

@@ -41,7 +41,7 @@
                     GNU AFFERO GENERAL PUBLIC LICENSE
                        Version 3, 19 November 2007
 
- Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
 
@@ -683,7 +683,7 @@ the "copyright" line and a pointer to where the full notice is found.
     GNU Affero General Public License for more details.
 
     You should have received a copy of the GNU Affero General Public License
-    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+    along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 Also add information on how to contact you by electronic and paper mail.
 
@@ -698,4 +698,4 @@ specific requirements.
   You should also get your employer (if you work as a programmer) or school,
 if any, to sign a "copyright disclaimer" for the program, if necessary.
 For more information on this, and how to apply and follow the GNU AGPL, see
-<http://www.gnu.org/licenses/>.
+<https://www.gnu.org/licenses/>.

VERSION

@@ -1 +1 @@
-19.05
+20.05

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,16 +87,33 @@ 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.
   Thanks to the C runtime, the flexible per-component VFS, the standard
   C++ library, and the Noux runtime (for UNIX software), porting software
   to Genode is relatively straight forward. The
-  [http://genode.org/documentation/developer-resources/porting - porting guide]
+  [https://genode.org/documentation/developer-resources/porting - porting guide]
   explains the typical steps. A wish list of software that we'd like to
   have available on Genode is available at
-  [http://usr.sysret.de/jws/genode/porting_wishlist.html].
+  [https://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
@@ -133,20 +121,20 @@ Application frameworks and runtime environments
 
 :OpenJDK:
 
-  [http://openjdk.java.net/ - OpenJDK] is the reference implementation of the
+  [https://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,
@@ -218,10 +190,37 @@ Application frameworks and runtime environments
   analyzing such components with formal methods.
 
   The use of Haskell for systems development was pioneered by the
-  [http://programatica.cs.pdx.edu/House/ - House Project]. A more recent
-  development is [http://halvm.org - HalVM] - a light-weight OS runtime for
+  [https://programatica.cs.pdx.edu/House/ - House Project]. A more recent
+  development is [https://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,24 +305,12 @@ 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
   perform reasonably well for everyday use cases but are obviously not
   designated for high-performance networking.
-  The [http://dpdk.org/ - DPDK] is a vendor-supported suite of network device
+  The [https://dpdk.org/ - DPDK] is a vendor-supported suite of network device
   drivers that is specifically developed for high-performance applications.
   It presents an attractive alternative to iPXE-based drivers. This project
   has the goal to make DPDK drivers available as a Genode component.
@@ -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/components.txt

@@ -14,6 +14,11 @@ Genode comes with a growing number of components apparently scattered across
 various repositories. This document provides an overview of these components
 and outlines the systematics behind them.
 
+The scope of this document is limited to the Genode main repository maintained
+by Genode Labs. Many additional components and device drivers can be found in
+the community-maintained
+[https://github.com/genodelabs/genode-world/ - Genode-World] repository.
+
 
 Categorization of components
 ############################
@@ -79,6 +84,10 @@ Platform devices
   this simple ACPI parser traverses the ACPI tables and reports device-resource
   information (e.g., interrupt lines of PCI devices).
 
+:'os/src/app/smbios_decoder':
+  A component that parses SMBIOS information on x86 platforms and makes the
+  result available as a report.
+
 :'libports/src/app/acpica':
   In addition to our ACPI base driver, the acpica component uses the
   ACPICA library to provide access to dynamic functions like battery
@@ -93,18 +102,12 @@ UART devices
 
 The UART device drivers implement the UART-session interface.
 
-:'os/src/drivers/uart/spec/pl011':
+:'os/src/drivers/uart/spec/pbxa9':
   Driver for the PL011 UART as found on many ARM-based platforms.
 
-:'os/src/drivers/uart/spec/i8250':
+:'os/src/drivers/uart/spec/x86':
   Driver for the i8250 UART as found on PC hardware.
 
-:'os/src/drivers/uart/spec/omap4':
-  Driver for the UART as found on OMAP4-based hardware.
-
-:'os/src/drivers/uart/spec/exynos5':
-  Driver for the UART as found on Exynos-5-based hardware.
-
 
 Framebuffer and input drivers
 =============================
@@ -141,15 +144,9 @@ input-session interfaces respectively.
   Driver for boot-time initialized framebuffers (e.g., UEFI GOP)
   discovered from the 'platform_info' ROM
 
-:'os/src/drivers/framebuffer/spec/pl11x':
+:'os/src/drivers/framebuffer/pl11x':
   Driver for the PL110/PL111 LCD display.
 
-:'os/src/drivers/framebuffer/spec/omap4':
-  Driver for HDMI output on OMAP4 SoCs.
-
-:'os/src/drivers/framebuffer/spec/exynos5':
-  Driver for HDMI output on Exynos-5 SoCs.
-
 :'os/src/drivers/framebuffer/spec/imx53':
   Driver for LCD output on i.MX53 SoCs.
 
@@ -161,7 +158,7 @@ input-session interfaces respectively.
   driver is only usable on the Linux base platform.
 
 :'os/src/drivers/gpu/intel':
-  Intel Graphics GPU multiplexer for Broadwell and newer.
+  An experimental Intel Graphics GPU multiplexer for Broadwell and newer.
 
 :'dde_linux/src/drivers/framebuffer/intel':
   Framebuffer driver for Intel i915 compatible graphic cards based on
@@ -173,6 +170,9 @@ input-session interfaces respectively.
   refer to the run scripts at 'dde_linux/run/usb_hid' and
   'dde_linux/run/usb_storage'.
 
+:'dde_linux/src/drivers/usb_hid':
+  USB Human Interface Device driver using the USB session interface.
+
 
 Timer drivers
 =============
@@ -220,12 +220,6 @@ All block drivers implement the block-session interface defined at
   Driver for SD-cards connected via the PL180 device as found on the PBX-A9
   platform.
 
-:'os/src/drivers/sd_card/spec/omap4':
-  Driver for SD-cards connected to the SD-card controller of the OMAP4 SoC.
-
-:'os/src/drivers/sd_card/spec/exynos5':
-  Driver for SD-cards and eMMC connected to Exynos-5-based platforms.
-
 :'os/src/drivers/sd_card/spec/imx53':
   Driver for SD-cards connected to the Freescale i.MX53 platform like the
   Quick Start Board or the USB armory device.
@@ -241,6 +235,9 @@ All block drivers implement the block-session interface defined at
 :'os/src/drivers/ahci':
   Driver for SATA disks and CD-ROMs on x86 PCs.
 
+:'os/src/drivers/nvme':
+  Driver for NVMe block devices on x86 PCs.
+
 :'os/src/drivers/usb_block':
   USB Mass Storage Bulk-Only driver using the USB session interface.
 
@@ -259,10 +256,6 @@ defined at 'os/include/nic_session'.
   Native device driver for the LAN9118 network adaptor as featured on the
   PBX-A9 platform.
 
-:'os/src/drivers/nic/gem':
-  Device driver for Cadence EMAC PS network adaptor as featured on the
-  Xilinx Zynq.
-
 :'dde_ipxe/src/drivers/nic':
   Device drivers ported from the iPXE project. Supported devices are Intel
   E1000 and pcnet32.
@@ -281,19 +274,12 @@ defined at 'os/include/nic_session'.
 General-purpose I/O drivers
 ===========================
 
-:'os/src/drivers/gpio/spec/omap4':
-  Driver for accessing the GPIO pins of OMAP4 platforms.
-
 :'os/src/drivers/gpio/spec/imx53':
   Driver for accessing the GPIO pins of i.MX53 platforms.
 
 :'os/src/drivers/gpio/spec/rpi':
   Driver for accessing the GPIO pins of Raspberry Pi platforms.
 
-:'os/src/drivers/gpio/spec/exynos5':
-  Driver for accessing the GPIO pins of Exynos4 platforms, e.g.,
-  Odroid-X2.
-
 
 Resource multiplexers
 #####################
@@ -319,14 +305,21 @@ subdirectory of a source repository.
   the physical network. DHCP requests originating from the virtual NIC sessions
   are delegated to the physical network.
 
+  The NIC router located at 'os/src/server/nic_router' multiplexes one NIC
+  session to multiple virtual NIC sessions by applying network address
+  translation (NAT).
+
 :Block: The block-device partition server at 'os/src/server/part_block' reads
   the partition table of a block session and exports each partition found as
   separate block session. For using this server, please refer to the run
   script at 'os/run/part_block'.
 
-:File system: The FAT file-system service allows multiple clients to
-  concurrently access the same FAT-formatted block device. It is located
-  at 'libports/src/server/fatfs_fs' and supports FAT, FAT32, and exFAT.
+:File system: The VFS file-system server allows multiple clients to
+  concurrently access the same virtual file system. It is located at
+  'os/src/server/vfs'. The VFS can be assembled out of several builtin
+  file-system types (like a RAM file system, or pseudo file systems for
+  various Genode session interfaces) as well as external plugins such as rump
+  (mounting file systems supported by the NetBSD kernel).
 
 :Terminal: The terminal_mux service located at gems/src/server/terminal_mux
   is able to provide multiple terminal sessions over one terminal-client
@@ -340,7 +333,8 @@ Protocol stacks
 Protocol stacks come either in the form of separate components that translate
 one session interface to another, or in the form of libraries.
 
-Separate components:
+Separate components
+===================
 
 :'os/src/server/nit_fb':
   Translates a nitpicker session to a pair of framebuffer and input sessions.
@@ -367,21 +361,10 @@ Separate components:
   Provides each file of an ISO9660 file system accessed via a block session as
   separate ROM session.
 
-:'os/src/server/ram_fs':
-  A file-system implementation that keeps all data in memory.
-
-:'dde_rump/src/server/rump_fs':
-  A file-system server that contains various file-systems ported from the
-  NetBSD kernel.
-
 :'os/src/server/lx_fs':
   A file system server that makes the file system of a Linux base platform
   available to Genode.
 
-:'os/src/server/trace_fs':
-  A pseudo file system that can be used as a front end to core's TRACE
-  service.
-
 :'os/src/server/rom_block':
   Provides the content of a ROM file as a block session, similar to the
   loop-mount mechanism on Linux
@@ -413,9 +396,6 @@ Separate components:
   switching between configuration variants dependent on the state of
   the system.
 
-:'os/src/server/vfs':
-  A file-system server using the VFS library and plugins as backend.
-
 :'os/src/server/log_terminal':
   Forwards terminal output to a LOG session.
 
@@ -444,6 +424,15 @@ Separate components:
   up an equally named file on the file system.
   Please refer to 'os/src/server/fs_rom' for more information.
 
+  For use cases where ROMs are known to be static, the
+  'os/src/server/cached_fs_rom' can be considered as a faster alternative to
+  the regular 'fs_rom' server. Note that 'cached_fs_rom' is not supported
+  in base-linux though.
+
+:'os/src/server/chroot':
+  An intermediate file-system server that makes a sub directory of a file
+  system available as the root of a file system handed out to its client.
+
 :'os/src/server/dynamic_rom':
   A simple ROM service that provides ROM modules that change in time according
   to a configured timeline.
@@ -461,14 +450,9 @@ Separate components:
   is then propagated to the clients of the ROM service according to a
   configurable information-flow policy.
 
-:'ports/src/app/openvpn':
-  OpenVPN enables access to remote network resources through a secure tunnel
-  by providing an encrypted connection to a remote host. It is plugged between
-  NIC server (such as a network driver) and NIC client.
-
-:'os/src/server/input_merger':
-  A component that merges input events from multiple sources into a single
-  stream.
+:'os/src/server/input_filter':
+  A component that transforms and merges input events from multiple sources
+  into a single stream.
 
 :'libports/src/server/acpi_input':
   A component that transforms ACPI events into Genode input events.
@@ -477,20 +461,56 @@ Separate components:
   A wrapper for nitpicker's session interface that applies alpha-blending to
   the of views a nitpicker client.
 
-Libraries:
+
+VFS plugins
+===========
+
+VFS plugins are file-system drivers in the form of shared libraries that
+implement the VFS-plugin interface. They can be combined with any application
+based on Genode's C runtime, with the VFS server, and with non-POSIX
+components that use the Genode's VFS library directly.
+
+:'gems/src/lib/vfs/trace':
+  A VFS plugin that makes core's TRACE service accessible as a pseudo
+  file system.
+
+:'gems/src/lib/vfs/import':
+  A VFS plugin that pre-populates a VFS with initial content.
+
+:'gems/src/lib/vfs/pipe':
+  A VFS plugin that provides bi-directional pipes for exchanging streamed
+  data between components.
+
+:'gems/src/lib/vfs/ttf':
+  A VFS plugin that makes rendered pixel data of the glyphs of Truetype fonts
+  available as a pseudo file system.
+
+:'libports/src/lib/vfs/jitterentropy':
+  A VFS plugin that provides random numbers based on the jitter of executing
+  CPU instructions.
+
+:'libports/src/lib/vfs/lwip':
+  A VFS plugin that uses the light-weight IP (lwIP) stack to provide a
+  network socket interface as a pseudo file system.
+
+:'dde_linux/src/lib/vfs/lxip':
+  A VFS plugin that uses the TCP/IP stack ported from the Linux kernel to
+  provide a network socket interface as a pseudo file system.
+
+:'libports/src/lib/vfs/fatfs':
+  A VFS plugin that allows for the mounting of FAT-formatted block devices.
+
+:'dde_rump/src/lib/vfs/rump':
+  A VFS plugin that enables the use of NetBSD's file-system drivers such
+  as ext2 or msdos.
+
+
+Libraries
+=========
 
 :'libports/lib/mk/libc':
   C runtime ported from FreeBSD.
 
-:'libports/lib/mk/libc_fatfs':
-  Accesses files on a block device that contains a FAT32 file system.
-
-:'libports/lib/mk/libc_fuse_exfat':
-  Accesses files on a block device that contains an exFAT file system.
-
-:'libports/lib/mk/libc_fuse_ext2':
-  Accesses files on a block device that contains an ext2 file system.
-
 :'libports/lib/mk/stdcxx':
   Standard C++ library
 
@@ -498,28 +518,13 @@ Libraries:
   Mesa OpenGL API with backends for software rasterization (egl_swrast)
   and Intel Graphics (egl_i965)
 
-:'libports/lib/mk/pthread':
-  Subset of the POSIX thread and semaphore API.
-
-:'libports/lib/mk/python':
-  Runtime of the Python scripting language.
-
 :'libports/lib/mk/mupdf':
   PDF rendering engine.
 
-:'libports/lib/mk/sdl':
-  Translates the libSDL API to framebuffer and input sessions.
-
 :'libports/lib/mk/ncurses':
   Library for implementing pseudo-graphical applications (i.e., VIM) that
   run on a text terminal.
 
-:'libports/lib/mk/avcodec':
-  A library for video decoding, conversion, and streaming.
-
-:'libports/lib/mk/lua':
-  Runtime for the Lua scripting language.
-
 :'libports/lib/mk/qt5_*':
   Qt5 framework, using nitpicker session and NIC session as back end.
 
@@ -558,8 +563,6 @@ located in their respective directory.
 
 :'gems/app/launcher': Graphical launcher of Genode subsystems.
 
-:'os/app/cli_monitor': Command-line-based launcher of Genode subsystems.
-
 :'demo/src/app/scout':
   Graphical hypertext browser used for Genode's default demonstration scenario.
 
@@ -603,6 +606,7 @@ located in their respective directory.
 :'os/src/app/log_core':
   Component transforming core and kernel output to Genode LOG output.
 
+
 Package-management components
 =============================
 
@@ -629,10 +633,6 @@ Package-management components
 Runtime environments
 ####################
 
-:'ports/src/noux': Noux is an experimental implementation of a UNIX-like API
-  that enables the use of unmodified command-line based GNU software. For using
-  noux, refer to the run script 'ports/run/noux.run'.
-
 :'ports/src/app/seoul': Seoul is a virtual-machine monitor developed for
   the use with the NOVA platform. It virtualizes 32bit x86 PC hardware
   including various peripherals.
@@ -641,7 +641,9 @@ Runtime environments
   of Genode subsystems via a session interface. For further information,
   refer to 'os/src/server/loader/README'.
 
-:'ports/src/app/dosbox': A port of DosBox for executing DOS software.
-
 :'ports/src/virtualbox': VirtualBox running on top of the NOVA hypervisor.
 
+:'os/src/server/vmm': A virtual machine monitor that is based on
+  hardware-assisted virtualization of ARM platforms. It is supported on
+  the base-hw kernel only.
+

doc/contributions.txt

@@ -140,7 +140,7 @@ permission to let Genode Labs redistribute his contributions under non-AGPLv3
 licenses. This permission is granted by signing the Genode Contributors
 Agreement:
 
-:[http:gca.pdf - Genode Contributor's Agreement]:
+:[https://genode.org/community/gca.pdf - Genode Contributor's Agreement]:
   Genode Contributor's Agreement (GCA)
 
 By signing the GCA, you don't lose any rights for your contribution. However,

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,191 @@
                                ===========
 
 
+Sculpt OS release 20.02 | 2020-03-10
+####################################
+
+| Version 20.02 of the Sculpt operating system revisits the administrative
+| user interface for a more intuitive and logical user experience.
+
+With the release of Sculpt version 20.02, we follow our
+[https://genode.org/about/road-map - roadmap's] mission to make Sculpt OS
+easier to approach. In particular, we
+[https://genodians.org/nfeske/2020-01-06-pending-sculpt-ui - identified] the
+reliance on a command-line interface as a potential barrier of entry. As
+Sculpt OS is not a Unix-like system, it should not require any Unix know-how
+from the user. To relieve users from this burden, Sculpt 20.02 introduces
+a custom graphical file browser and editor that can be used for interactively
+inspecting and tweaking the state of the system. The traditional command-line
+interface is still present as a fallback for advanced tasks though.
+The updated [https://genode.org/documentation/articles/sculpt-20-02 - manual]
+goes into detail about the use of the new system.
+
+Thanks to the work of seasoned Genode developers, many software packages are
+already available for the new version. These include virtual machine monitors
+like VirtualBox, performance-monitoring tools, GUI components, Genode's custom
+Unix runtime, and several applications and games. In particular, the software
+depots offered by alex-ab, cnuke, skalk are worth exploring.
+The ready-to-use system image for version 20.02 can be obtained from the
+[https://genode.org/download/sculpt - Sculpt download page] and is
+accompanied by matching
+[https://genode.org/documentation/articles/sculpt-20-02 - documentation].
+
+
+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
 ##############################################
 
@@ -85,7 +270,7 @@ about the articles, readers are invited to the new
 [https://reddit.com/r/genode - /r/genode] subreddit.
 
 As written in the
-[http://genodians.org/nfeske/2019-01-07-welcome - initial posting],
+[https://genodians.org/nfeske/2019-01-07-welcome - initial posting],
 Genode users and developers are warmly invited to join the authors at
 Genodians.org!
 
@@ -891,7 +1076,7 @@ The story behind Genode's TrustZone demo on the USB Armory | 2015-12-08
 | Our latest article provides a look behind the scenes of the
 | development of Genode's support for the USB Armory platform.
 
-The [http://inversepath.com/usbarmory - USB Armory] is a computer in the form
+The [https://inversepath.com/usbarmory - USB Armory] is a computer in the form
 of a USB stick. It normally runs Linux. But thanks to the ARM TrustZone
 capabilities of the device, it is possible to run Genode behind the back of
 Linux. This is useful for shielding sensitive information like cryptographic
@@ -905,7 +1090,7 @@ was splitting the hardware platform into two worlds while maintaining the
 full functionality of Linux. The article goes on to explain the interplay
 between the secure world (Genode) and the normal world (Linux). Furthermore,
 it provides all the pointers needed to reproduce the scenario.
-[http:/documentation/articles/usb_armory - Read the article...]
+[https://genode.org/documentation/articles/usb_armory - Read the article...]
 
 
 Genode OS Framework release 15.11 | 2015-11-30
@@ -2084,7 +2269,7 @@ for our dual-licensing business model. If we made Genode available under the
 BSD license, there would be not point in pursuing this model. However, hiding
 the development process from the public is not only poor-spirited but it
 creates an artificial barrier for people who want to participate. The book
-"Producing Open Source Software" (http://producingoss.com) by Karl Fogel was an
+"Producing Open Source Software" (https://producingoss.com) by Karl Fogel was an
 eye opener to us.
 
 Regarding the efficiency of collaboration, I have to admit that the statement
@@ -2182,7 +2367,7 @@ new support of L4Android on Genode, Android can be used on Genode on the
 Fiasco.OC kernel on the IA32 architecture. For those of you who are eager to
 experiment with L4Android on Genode, please find further information at the
 top-level
-[http://genode.svn.sourceforge.net/viewvc/genode/trunk/ports-foc/README - README]
+[https://genode.svn.sourceforge.net/viewvc/genode/trunk/ports-foc/README - README]
 file of the 'ports-foc' repository and share your results with us at the
 [https:/community/mailing-lists - Genode mailing list].
 
@@ -2297,17 +2482,17 @@ concepts live. The talk was recorded at the
 Amsterdam. Thanks to Bas the Lange for publishing the material.
 
 : <object height="385" width="480">
-:  <param name="movie" value="http://www.youtube.com/v/Z1IMV3FJO7Q" />
+:  <param name="movie" value="https://www.youtube.com/v/Z1IMV3FJO7Q" />
 :  <param name="allowFullScreen" value="true" />
 :  <param name="allowscriptaccess" value="always" />
 :  <embed width="480" height="385" allowfullscreen="true"
 :         allowscriptaccess="always"
 :         type="application/x-shockwave-flash"
-:         src="http://www.youtube.com/v/Z1IMV3FJO7Q">
+:         src="https://www.youtube.com/v/Z1IMV3FJO7Q">
 :  </embed>
 : </object>
 
-[http://www.youtube.com/watch?v=Z1IMV3FJO7Q - Visit the YouTube page...]
+[https://www.youtube.com/watch?v=Z1IMV3FJO7Q - Visit the YouTube page...]
 
 
 Genode OS Framework release 11.02 | 2011-02-24
@@ -2364,17 +2549,17 @@ prepared the following screencast with a guided walk-through. Enjoy!
 
 : <object height="385" width="480">
 :  <param name="movie"
-:         value="http://www.youtube.com/v/CJdWOmajo_8?fs=1&amp;hl=en_US" />
+:         value="https://www.youtube.com/v/CJdWOmajo_8?fs=1&amp;hl=en_US" />
 :  <param name="allowFullScreen" value="true" />
 :  <param name="allowscriptaccess" value="always" />
 :  <embed width="480" height="385"
-:         src="http://www.youtube.com/v/CJdWOmajo_8?fs=1&amp;hl=en_US"
+:         src="https://www.youtube.com/v/CJdWOmajo_8?fs=1&amp;hl=en_US"
 :         type="application/x-shockwave-flash" allowscriptaccess="always"
 :         allowfullscreen="true">
 :  </embed>
 : </object>
 
-[http://www.youtube.com/watch?v=CJdWOmajo_8 - Visit the YouTube page...]
+[https://www.youtube.com/watch?v=CJdWOmajo_8 - Visit the YouTube page...]
 
 [https:/download/live-cds - Download the real thing...]
 
@@ -2773,13 +2958,13 @@ for graphics, input devices, and sound. It is often used as back end for games,
 emulators, and media players. Also the Linux version of Genode relies on the
 hardware abstractions provided by libSDL.
 
-As [http://sourceforge.net/mailarchive/message.php?msg_id=21406424 - announced on the Genode mailing list],
+As [https://sourceforge.net/mailarchive/message.php?msg_id=21406424 - announced on the Genode mailing list],
 libSDL has been ported to Genode. At the current stage, the port supports
 the video subsystem and the input handling for mouse and keyboard. With
 libSDL now becoming available for Genode, it becomes much easier to make the
 wealth of libSDL-based applications available on our platform.
 
-[http://sourceforge.net/mailarchive/message.php?msg_id=21406424 - Read the announcement...]
+[https://sourceforge.net/mailarchive/message.php?msg_id=21406424 - Read the announcement...]
 
 
 Genode on the L4ka::Pistachio kernel | 2008-12-18
@@ -2931,7 +3116,7 @@ Project website launched | 2008-07-29
 | Genode OS framework is scheduled for the 6th of August.
 
 Today, we proudly launched the website of the Genode project
-[https://www.genode.org - https://www.genode.org]. This website is the central
+[https://genode.org - https://genode.org]. This website is the central
 resource for people using or developing the Genode OS framework. It covers
 the latest news about our progress, architectural and technical documentation,
 a community-maintained wiki, mailing lists, information on accessing the
@@ -2940,7 +3125,7 @@ attention of people who want bring forward the project together with us.
 
 We have scheduled the first official release of the Genode OS framework for the
 6th August. Until then, we invite you to test-drive the beta-version of the
-framework as provided at the [https://www.genode.org/download - download].
+framework as provided at the [https://genode.org/download - download].
 
 
 Genode Labs founded | 2008-07-17

doc/release_notes-08-11.txt

@@ -110,7 +110,7 @@ above becomes as simple as:
 !/* invoke remote procedure */
 !Capability ds_csp = rom.dataspace();
 
-[http://genode.org/documentation/api/base_index#Connecting_to_services - See the API documentation for the connection template...]
+[https://genode.org/documentation/api/base_index#Connecting_to_services - See the API documentation for the connection template...]
 
 
 Typed capabilities
@@ -134,7 +134,7 @@ classes at the client side.
 From the application-developer's perspective, working with capabilities
 has now become type-safe, making the produced code more readable and robust.
 
-[http://genode.org/documentation/api/base_index#Capability_representation - See the updated API documentation for the capability representation...]
+[https://genode.org/documentation/api/base_index#Capability_representation - See the updated API documentation for the capability representation...]
 
 
 Fifo data structure
@@ -146,7 +146,7 @@ first-out semantics. For such use cases, we introduced a dedicated
 'Fifo' template. The main motivation for introducing 'Fifo' into the
 base API is the new semaphore described below.
 
-[http://genode.org/documentation/api/base_index#Structured_data_types - See the new API documentation for the fifo template...]
+[https://genode.org/documentation/api/base_index#Structured_data_types - See the new API documentation for the fifo template...]
 
 
 Semaphore
@@ -163,7 +163,7 @@ and added the semaphore to Genode's official base API. We have made
 the wake-up policy in the presence of multiple consumers configurable
 via a template argument. The default policy is first-in-first-out.
 
-[http://genode.org/documentation/api/base_index#Synchronization - See the new API documentation for the semaphore...]
+[https://genode.org/documentation/api/base_index#Synchronization - See the new API documentation for the semaphore...]
 
 Thanks to Christian Prochaska for his valuable contributions to the new
 semaphore design.
@@ -221,7 +221,7 @@ would have to be queued at the transmitter.
 Image [signals] illustrates the roles of signaller thread,
 transmitter, receiver, and signal-handler thread.
 
-[http://genode.org/documentation/api/base_index#Asynchronous_notifications - See the new API documentation for asynchronous notifications...]
+[https://genode.org/documentation/api/base_index#Asynchronous_notifications - See the new API documentation for asynchronous notifications...]
 
 The current generic implementation of the signalling API employs one
 thread at each transmitter and one thread at each receiver. Because
@@ -422,27 +422,27 @@ the API.
 Christian Helmuth created the initial version of the Linux device-driver
 environment for L4. He describes his effort of reusing unmodified sound
 drivers on the L4 platform in his thesis
-[http://os.inf.tu-dresden.de/papers_ps/helmuth-diplom.pdf - Generische Portierung von Linux-Gerätetreibern auf die DROPS-Architektur].
+[https://os.inf.tu-dresden.de/papers_ps/helmuth-diplom.pdf - Generische Portierung von Linux-Gerätetreibern auf die DROPS-Architektur].
 ;
 Gerd Griessbach approached the problem of re-using Linux USB drivers
 by following the DDE approach in his diploma thesis
-[http://os.inf.tu-dresden.de/papers_ps/griessbach-diplom.pdf - USB for DROPS].
+[https://os.inf.tu-dresden.de/papers_ps/griessbach-diplom.pdf - USB for DROPS].
 ;
 Marek Menzer adapted Linux DDE to Linux 2.6 and explored the DDE
 approach for block-device drivers in his student research project
-[http://os.inf.tu-dresden.de/papers_ps/menzer-beleg.pdf - Portierung des DROPS Device Driver Environment (DDE) für Linux 2.6 am Beispiel des IDE-Treibers ]
+[https://os.inf.tu-dresden.de/papers_ps/menzer-beleg.pdf - Portierung des DROPS Device Driver Environment (DDE) für Linux 2.6 am Beispiel des IDE-Treibers ]
 and his diploma thesis
-[http://os.inf.tu-dresden.de/papers_ps/menzer-diplom.pdf - Entwicklung eines Blockgeräte-Frameworks für DROPS].
+[https://os.inf.tu-dresden.de/papers_ps/menzer-diplom.pdf - Entwicklung eines Blockgeräte-Frameworks für DROPS].
 ;
 Thomas Friebel generalized the DDE approach and introduced the DDE kit
 API to enable the re-use of device driver from other platforms than
 Linux. In particular, he experimented with the block-device drivers of
 FreeBSD in his diploma thesis
-[http://os.inf.tu-dresden.de/papers_ps/friebel-diplom.pdf - Übertragung des Device-Driver-Environment-Ansatzes auf Subsysteme des BSD-Betriebssystemkerns].
+[https://os.inf.tu-dresden.de/papers_ps/friebel-diplom.pdf - Übertragung des Device-Driver-Environment-Ansatzes auf Subsysteme des BSD-Betriebssystemkerns].
 ;
 Dirk Vogt successfully re-approached the port of USB device drivers
 from the Linux kernel to L4 in his student research project
-[http://os.inf.tu-dresden.de/papers_ps/beleg-vogt.pdf - USB for the L4 Environment].
+[https://os.inf.tu-dresden.de/papers_ps/beleg-vogt.pdf - USB for the L4 Environment].
 
 The current incarnation of the DDE kit API provides the following
 features:
@@ -556,7 +556,7 @@ source-code repository called 'libc' and is based on the code of FreeBSD.
 The original code is available at the official FreeBSD website.
 
 :FreeBSD website:
-  [http://www.freebsd.org/developers/cvs.html]
+  [https://www.freebsd.org/developers/cvs.html]
 
 Our libc port comprises the libraries 'gdtoa', 'gen', 'locale', 'stdio',
 'stdlib', 'stdtime', 'string', and 'msun'. Currently, it supports the

doc/release_notes-09-02.txt

@@ -28,7 +28,7 @@ supported base platforms.
 
 Our original plan for the release 9.02 also comprised the support of a
 Linux-on-Genode (para-)virtualization solution. Initially, we intended to
-make [http://os.inf.tu-dresden.de/L4/LinuxOnL4/ - L4Linux] available on
+make [https://os.inf.tu-dresden.de/L4/LinuxOnL4/ - L4Linux] available on
 the L4/Fiasco version of Genode. However, we identified several downsides
 with this approach. Apparently, the development of the officially available
 version of L4/Fiasco has become slow and long-known issues remain unfixed.
@@ -41,7 +41,7 @@ and VT support) that we want to explore. Furthermore, there exists another
 version of L4Linux called OKLinux for the OKL4 kernel developed at
 [http://ok-labs.com - OK-Labs], which is very interesting as well.
 Therefore, we decided against an ad-hoc solution and deferred this feature
-to the next release. [http:/about/road-map - See our updated road map...]
+to the next release. [https://genode.org/about/road-map - See our updated road map...]
 
 
 Major new Features
@@ -126,7 +126,7 @@ effort is included in this release and comes in the form of the
 :Further details:
 
 You can find further technical details and usage instructions at this
-dedicated [http://genode.org/documentation/platforms/pistachio - page].
+dedicated [https://genode.org/documentation/platforms/pistachio - page].
 
 
 Qt4 on Genode
@@ -331,7 +331,7 @@ Device-Driver-Environment Kit
 
 Because of the apparent stabilization of the DDE Kit API, we have now added
 this API to Genode's official API reference.
-[http://genode.org/documentation/api/dde_kit_index - See the documentation of the DDE Kit API...]
+[https://genode.org/documentation/api/dde_kit_index - See the documentation of the DDE Kit API...]
 
 
 PS/2 input driver
@@ -413,7 +413,7 @@ gcc 4.2.4.
 
 As an alternative to installing the tool chain from source, we also
 provide pre-compiled binaries at the download section of our website.
-[http://genode.org/download/tool-chain - Visit our tool-chain download website...]
+[https://genode.org/download/tool-chain - Visit our tool-chain download website...]
 
 For the Linux version of Genode, we still use the host's default gcc
 as tool chain. This way, we spare the hassle of downloading and installing

doc/release_notes-09-05.txt

@@ -19,7 +19,7 @@ The previous Genode release was accompanied by a source-code archive containing
 the initial version of Qt4 for Genode. Our approach is to make the Qt4
 framework available for building Genode applications running natively on the
 microkernel rather than within a virtualization environment. As advertised in
-our [http://genode.org/about/road-map - road map], we have now seamlessly
+our [https://genode.org/about/road-map - road map], we have now seamlessly
 integrated the Qt4 framework into our mainline source tree.  Furthermore, we
 have adapted our port to the Qt4 version 4.5.1. Section [Integration of Qt4
 into the mainline repository] gives a rough overview of the changes and an
@@ -152,7 +152,7 @@ L4 kernels.
 These differences of OKL4 compared with the microkernels already supported
 by Genode posed a number of interesting challenges and opportunities. We have
 thoroughly documented the process in
-[http://genode.org/documentation/articles/genode-on-okl4 - Bringing Genode to OKL4].
+[https://genode.org/documentation/articles/genode-on-okl4 - Bringing Genode to OKL4].
 
 
 Usage
@@ -160,7 +160,7 @@ Usage
 
 For using Genode with OKL4, please refer to the following dedicated page:
 
-:[http://genode.org/documentation/platforms/okl4 - Genode on the OKL4 microkernel]:
+:[https://genode.org/documentation/platforms/okl4 - Genode on the OKL4 microkernel]:
   Site about building and using Genode with the OKL4 kernel.
 
 
@@ -293,7 +293,7 @@ Genode's libc. Thereby the linker will silently create references to glibc
 symbols, making both libraries collide. So if using Qt4, we recommend using the
 Genode tool chain:
 
-:[http://genode.org/download/tool-chain]:
+:[https://genode.org/download/tool-chain]:
   Information about downloading and using the Genode tool chain
 
 
@@ -308,7 +308,7 @@ we already utilized this approach for realizing basic networking on Genode.
 With this release, we complement DDE Linux with support required by USB
 drivers. We are grateful for being able to base our implementation on the
 excellent foundation laid by Dirk Vogt. He described his work in
-[http://os.inf.tu-dresden.de/papers_ps/beleg-vogt.pdf - USB for the L4 environment].
+[https://os.inf.tu-dresden.de/papers_ps/beleg-vogt.pdf - USB for the L4 environment].
 
 For USB HID support, we added the Linux USB and input subsystems to the DDE
 Linux 2.6 framework. Besides the 'dde_linux26/net.h' API for network drivers

doc/release_notes-09-11.txt

@@ -194,7 +194,7 @@ Qemu is decribed at a dedicated Wiki page:
 
 :Genode/OKL4 on the GTA01 platfrom:
 
-  [http://genode.org/community/wiki/GenodeOKL4OnTheGTA01Platform - Genode.org Community Wiki]
+  [https://genode.org/community/wiki/GenodeOKL4OnTheGTA01Platform - Genode.org Community Wiki]
 
 Both the OKL4 version 2.1.1 and the GTA01 chip are not the most current
 platforms but this combination turned out to be good as starting point.
@@ -238,7 +238,7 @@ Usage
 
 If you haven't build Genode for OKL4 yet, please refer to the following document:
 
-:[http://genode.org/documentation/platforms/okl4 - Genode on the OKL4 microkernel]:
+:[https://genode.org/documentation/platforms/okl4 - Genode on the OKL4 microkernel]:
   This page contains the information on how to build and use Genode with OKL4.
 
 For building OKLinux for Genode, you first need to download and patch the
@@ -532,7 +532,7 @@ the following config file can be used:
 
 For trying out the example with Qemu, please refer to the instructions
 given in the
-[http://genode.org/documentation/release-notes/9.02#section-4 - description]
+[https://genode.org/documentation/release-notes/9.02#section-4 - description]
 of the initial networking support added in Genode version 9.02.
 
 

doc/release_notes-10-02.txt

@@ -63,7 +63,7 @@ In December 2009, the day we waited for a long time had come. The first version
 of NOVA was publicly released:
 
 :Official website of the NOVA hypervisor:
-  [http://hypervisor.org]
+  [https://hypervisor.org]
 
 Besides the novel and modern kernel interface, NOVA has a list of features that
 sets it apart from most other microkernels, in particular support for
@@ -221,7 +221,7 @@ The Genode release 10.02 supports the NOVA pre-release version 0.1. You can
 download the archive here:
 
 :Download NOVA version 0.1:
-  [http://os.inf.tu-dresden.de/~us15/nova/nova-hypervisor-0.1.tar.bz2]
+  [https://os.inf.tu-dresden.de/~us15/nova/nova-hypervisor-0.1.tar.bz2]
 
 For building NOVA, please refer to the 'README' file contained in the archive.
 Normally, a simple 'make' in the 'build/' subdirectory is all you need to
@@ -236,7 +236,7 @@ following command:
 
 This tool will create a fresh build directory at the location specified
 as 'BUILD_DIR'. Provided that you have installed the
-[http://genode.org/download/tool-chain - Genode tool chain], you can now build
+[https://genode.org/download/tool-chain - Genode tool chain], you can now build
 Genode by using 'make' from within the new build directory.
 
 Note that in contrast to most other kernels, the Genode build process does not
@@ -908,7 +908,7 @@ request inconsistently. We have now enhanced the 'Root_component' template with
 a policy parameter to 'Root_component' that allows the specification of a
 session-creation policy. The most important policy is whether a service can
 have a single or multiple clients.
-[http://genode.org/documentation/api/inline?code/base/include/root/component.h - See the improved template...]
+[https://genode.org/documentation/api/inline?code/base/include/root/component.h - See the improved template...]
 
 Out-of-order RPC replies
 ========================
@@ -933,7 +933,7 @@ provided with the 'libports' repository. It is based on the official
 Python code available from the website:
 
 :Python website:
-  [http://www.python.org]
+  [https://www.python.org]
 
 To fetch the upstream Python source code, call 'make prepare' from within the
 'libports' directory. To include Python in your build process, add 'libports'
@@ -1107,7 +1107,7 @@ running Genode like the following.
 ! sudo ip address add 10.0.0.1/24 brd + dev tap0
 
 Give it a try with the
-[http://genode.org/documentation/release-notes/9.11#section-17 - lwIP example scenario].
+[https://genode.org/documentation/release-notes/9.11#section-17 - lwIP example scenario].
 Please note that lwIP is configured for DHCP and does not assign a
 static IP configuration to its end of the wire. Hence, you should run
 a DHCP server on tap0, e.g.

doc/release_notes-10-05.txt

@@ -1012,7 +1012,7 @@ Arora web browser
 Arora has its origin as an example application for Qt4. However, it emancipated
 itself to be a separate project.
 
-:[http://arora.googlecode.com]: Arora project website
+:[https://arora.googlecode.com]: Arora project website
 
 Even though compared with other browsers, its popularity is relatively small
 but for us, it is perfect to stretch the bounds of our Genode infrastructure.
@@ -1123,7 +1123,7 @@ New two-stage build system
 ==========================
 
 Since the thorough
-[http://www.genode-labs.com/publications/scons-vs-make-2008.pdf - analysis of the Genode build system]
+[https://www.genode-labs.com/publications/scons-vs-make-2008.pdf - analysis of the Genode build system]
 by Ludwig Hähne in 2008, we were planning to incorporate his findings into
 Genode. In his study, he reimplemented Genode's make-based build system using
 SCons and compared both implementations. For us, the two most interesting

doc/release_notes-10-11.txt

@@ -17,7 +17,7 @@ networking, audio output, real-time priorities, mandatory access control,
 USB, ATAPI block devices, Python, hardware-accelerated 3D graphics, Qt4,
 the WebKit-based Arora browser, and the paravirtualized OKLinux kernel.
 So many wonderful toys waiting to get played with. This is how the idea of
-creating [http://genode.org/download/live-cds - the new Genode Live CD] was
+creating [https://genode.org/download/live-cds - the new Genode Live CD] was
 born. In the past, Genode was mostly used in settings with a relatively static
 configuration consisting of several components orchestrated to fulfill
 a few special-purpose functions. Now, the time has come for the next step,
@@ -65,7 +65,7 @@ the nifty interfaces used by the driver in our emulation framework. To
 achieve our short-term goal of a great live CD experience, we had to
 walk a different path.
 
-[http://gpxe.org/ - gPXE] is a lovely network boot loader / open-source
+[https://gpxe.org/ - gPXE] is a lovely network boot loader / open-source
 PXE ROM project and the successor of the famous Etherboot
 implementation. Besides support for DNS, HTTP, iSCSI and AoE, gPXE
 includes dozens of NIC drivers and applies a plain driver framework.
@@ -100,7 +100,7 @@ at 'bin/gpxe_nic_drv'.
 On-demand paging
 ################
 
-In the [http://genode.org/documentation/release-notes/8.11#section-8 - release 8.11],
+In the [https://genode.org/documentation/release-notes/8.11#section-8 - release 8.11],
 we laid the foundation for implementing user-level dataspace managers.
 But so far, the facility remained largely unused except for managing thread
 contexts. This changed with this release.
@@ -271,7 +271,7 @@ Finished transition to new init concept
 =======================================
 
 With the release 10.05, we introduced the
-[http://genode.org/documentation/release-notes/10.05#section-0 - current configuration concept of init].
+[https://genode.org/documentation/release-notes/10.05#section-0 - current configuration concept of init].
 This concept supports mandatory access control and provides flexible
 ways for defining client-server relationships. Until now, we maintained
 the old init concept. With the current release, the transition to the
@@ -736,7 +736,7 @@ Automated coding-style checker
 
 As Genode's code base grows and new developers start to get involved,
 we noticed recurring questions regarding coding style. There is a
-[http://genode.org/documentation/developer-resources/coding_style - document]
+[https://genode.org/documentation/developer-resources/coding_style - document]
 describing our coding style but for people just starting to get involved,
 adhering all the rules can become tedious. However, we stress the importance
 of a consistent coding style for the project. Not only does a consistent style

doc/release_notes-11-02.txt

@@ -88,7 +88,7 @@ following packages:
 Moreover, you need to download and install the tool-chain used by Genode. Have
 a look at this page:
 
-:[http://genode.org/download/tool-chain]:
+:[https://genode.org/download/tool-chain]:
   Genode tool-chain
 
 
@@ -98,8 +98,8 @@ Downloading and building Fiasco.OC
 Checkout the Fiasco.OC sources and tool-chain to an appropriated directory:
 
 ! export REPOMGR_SVN_REV=27
-! svn cat http://svn.tudos.org/repos/oc/tudos/trunk/repomgr |\
-!   perl - init http://svn.tudos.org/repos/oc/tudos fiasco l4re
+! svn cat https://svn.tudos.org/repos/oc/tudos/trunk/repomgr |\
+!   perl - init https://svn.tudos.org/repos/oc/tudos fiasco l4re
 
 
 Building the kernel
@@ -154,7 +154,7 @@ Building the Fiasco.OC version of Genode
 
 The Fiasco.OC version of Genode is available at the Genode public subversion repository:
 
-:http://genode.org/download/subversion-repository:
+:https://genode.org/download/subversion-repository:
   Information about accessing the Genode public subversion repository
 
 Go to a directory where you want the Genode/Fiasco.OC build directory to remain. Use
@@ -273,7 +273,7 @@ Further Information
 :genode/tool/builddir/README:
   Reference manual for the 'create_builddir' script
 
-:[http://os.inf.tu-dresden.de/fiasco]:
+:[https://os.inf.tu-dresden.de/fiasco]:
   Official website for the Fiasco.OC microkernel.
 
 
@@ -453,7 +453,7 @@ and a set of IP cores for implementing fully-fledged windowed GUIs on FPGAs:
 
 :Website of the Genode FPGA Graphics Project:
 
-  [http://genode-labs.com/products/fpga-graphics]
+  [https://genode-labs.com/products/fpga-graphics]
 
 Ever since we first released the Genode FPGA project, we envisioned to combine
 it with the Genode OS Framework. In Spring 2010, Martin Stein joined our team

doc/release_notes-11-05.txt

@@ -96,7 +96,7 @@ C++-based alternative, fostering the use of the C++ streaming operators
 combined with templates. The following paper provides a detailed discussion
 on the subject:
 
-:[http://genode-labs.com/publications/dynrpc-2007.pdf - A Case Study on the Cost and Benefit of Dynamic RPC Marshalling for Low-Level System Components]:
+:[https://genode-labs.com/publications/dynrpc-2007.pdf - A Case Study on the Cost and Benefit of Dynamic RPC Marshalling for Low-Level System Components]:
   _SIGOPS OSR Special Issue on Secure Small-Kernel Systems, 2007_
 
 In hindsight, leaving behind the IDL approach was the right decision. From a
@@ -120,7 +120,7 @@ function call to a remote process running on the same machine (contrarily to
 the term RPC being used in the context of systems distributed over a network).
 
 The state of the art is best explained by the example interface discussed
-in the [http://genode.org/documentation/developer-resources/client_server_tutorial - Hello Tutorial].
+in the [https://genode.org/documentation/developer-resources/client_server_tutorial - Hello Tutorial].
 On Genode, each RPC interface is represented by an abstract C++ class,
 enriched by some bits of information shared by the caller and the callee.
 

doc/release_notes-11-08.txt

@@ -251,27 +251,27 @@ The new way of dealing with different kernels motivated us to revisit and
 complement our exiting documentation. The following documents are new or
 have received considerable attention:
 
-:[http://genode.org/documentation/developer-resources/getting_started - Getting started]:
+:[https://genode.org/documentation/developer-resources/getting_started - Getting started]:
   The revised guide of how to explore Genode provides a quick way to
   test drive Genode's graphical demo scenario with a kernel of your
   choice and gives pointers to documents needed to proceed your
   exploration.
 
-:[http://genode.org/documentation/developer-resources/build_system - Build system manual]:
+:[https://genode.org/documentation/developer-resources/build_system - Build system manual]:
   The new build-system manual explains the concepts behind Genode's
   build system, provides guidance with creating custom programs and
   libraries, and covers the tool support for the automated integration
   and testing of application scenarios.
 
-:[http://genode.org/documentation/components - Components overview]:
+:[https://genode.org/documentation/components - Components overview]:
   The new components-overview document explains the categorization of
   Genode's components and lists all components that come with the framework.
 
-:[http://genode.org/documentation/developer-resources/init - Configuration of the init process]:
+:[https://genode.org/documentation/developer-resources/init - Configuration of the init process]:
   The document describes Genode's configuration concept, the routing of
   service requests, and the expression of mandatory access-control policies.
 
-:[http://genode.org/community/wiki - Wiki]:
+:[https://genode.org/community/wiki - Wiki]:
   The platform-specific Wiki pages for L4/Fiasco, L4ka::Pistachio, NOVA,
   Codezero, Fiasco.OC, and OKL4 have been updated to reflect the new flows of
   working with the respective base platforms.

doc/release_notes-11-11.txt

@@ -76,7 +76,7 @@ traditional hypervisors. Hence, the authors of NOVA coined the term
 microhypervisor.
 
 The NOVA virtualization architecture is detailed in the paper
-[http://os.inf.tu-dresden.de/papers_ps/steinberg_eurosys2010.pdf - NOVA: A Microhypervisor-Based Secure Virtualization Architecture]
+[https://os.inf.tu-dresden.de/papers_ps/steinberg_eurosys2010.pdf - NOVA: A Microhypervisor-Based Secure Virtualization Architecture]
 by Udo Steinberg and Bernhard Kauer.
 
 Since February 2010, NOVA is one of the supported base platforms of Genode. But
@@ -123,7 +123,7 @@ L4Linux is the base of L4Android, a project that combines the Android software
 stack with L4Linux. With the current release, we have integrated L4Android with
 Genode.
 
-:[http://l4android.org]:
+:[https://l4android.org]:
   L4Android project website
 
 [image l4android]
@@ -396,7 +396,7 @@ Vancouver is a virtual machine monitor specifically developed for the use with
 the NOVA hypervisor. It virtualizes a 32-bit x86 PC hardware including various
 peripherals.
 
-The official project website is [http://hypervisor.org]. Vancouver relies
+The official project website is [https://hypervisor.org]. Vancouver relies
 on hardware virtualization support such as VMX (Intel) or SVM (AMD).
 With the current release, we have added the first version of our port of
 Vancouver to Genode to the 'ports' repository. To download the Vancouver
@@ -575,7 +575,7 @@ bidirectional communication (terminal session), and creating the actual GDB
 support in the form of the GDB monitor component. To paint a complete picture
 of the scene, we have added the following documentation:
 
-:[http://genode.org/documentation/developer-resources/gdb]:
+:[https://genode.org/documentation/developer-resources/gdb]:
   User-level debugging on Genode
 
 
@@ -680,7 +680,7 @@ the official successor of gPXE, for our NIC drivers. Currently, drivers for
 Intel E1000/E1000e and PCnet32 cards are enabled in the new 'nic_drv'. The
 Linux based driver was removed.
 
-:[http://ipxe.org]:
+:[https://ipxe.org]:
   iPXE open source boot firmware
 
 

doc/release_notes-12-02.txt

@@ -28,7 +28,7 @@ with new device-driver infrastructure such as the first version of a device
 driver manager and a new ACPI parser.
 
 Feature-wise, the current release takes the first steps towards the goal of the
-[http://genode.org/about/road-map - Roadmap for 2012], turning Genode into a
+[https://genode.org/about/road-map - Roadmap for 2012], turning Genode into a
 general-purpose OS ready for everyday use by its developers. According to the
 roadmap, we enhanced the Noux runtime with fork semantics so that we can run
 command-line based GNU programs such as the bash shell and coreutils unmodified
@@ -48,7 +48,7 @@ releases. This way of development seemed to work quite well for us, we were
 satisfied about the pace of development, and with each release, our project got
 more recognition.
 
-However, the excellent book [http://producingoss.com/ - Producing Open Source Software]
+However, the excellent book [https://producingoss.com/ - Producing Open Source Software]
 made us realize that even though we released our work under an Open-Source
 license, our development process was actually far from being open and may have
 discouraged participation of people outside the inner circle of developers.
@@ -58,14 +58,14 @@ to liberate the project from its closed fashion of development.
 
 In the beginning of December, the vague idea has become a plan. So we finally
 brought the topic to our mailing list
-([http://genode.org/news/steps-towards-an-open-development-process - Steps towards an open development process]).
+([https://genode.org/news/steps-towards-an-open-development-process - Steps towards an open development process]).
 We decided to take the release cycle for Genode 12.02 as the opportunity to put
 our plan to practice. The central element of this endeavour was moving the
 project over to GitHub and adapt our workflows and tooling support accordingly.
 First, we started to embrace GitHub's issue tracker for the management of
 working topics:
 
-:[http://github.com/genodelabs/genode/issues]: Issue Tracker
+:[https://github.com/genodelabs/genode/issues]: Issue Tracker
 
 The most significant step was leaving our Genode-Labs-internal code
 repositories behind and starting a completely public Git repository instead:
@@ -86,7 +86,7 @@ comes directly from the project's Git repository. So maintaining website
 content is done in the same coherent and transparent way as working on Genode's
 code base. So we could finally put the old Wiki to rest. In the process, we
 largely revisited the existing content. For example, we rewrote the
-[http://genode.org/community/contributions - contributions] document in a
+[https://genode.org/community/contributions - contributions] document in a
 tutorial-like style and incorporated several practical hints, in particular
 related to the recommended use of Git.
 
@@ -419,9 +419,9 @@ New and updated libraries
 
   We updated Qt4 from version 4.7.1 to version 4.7.4. For the most part, the
   update contains bug fixes as detailed in the release notes for the versions
-  [http://qt.nokia.com/products/changes/changes-4.7.2 - 4.7.2],
-  [http://qt.nokia.com/products/changes/changes-4.7.3 - 4.7.3], and
-  [http://labs.qt.nokia.com/2011/09/01/qt-4-7-4-released - 4.7.4].
+  [https://qt.nokia.com/products/changes/changes-4.7.2 - 4.7.2],
+  [https://qt.nokia.com/products/changes/changes-4.7.3 - 4.7.3], and
+  [https://labs.qt.nokia.com/2011/09/01/qt-4-7-4-released - 4.7.4].
 
 :Update of zlib to version 1.2.6:
 
@@ -469,7 +469,7 @@ PDF viewer
 According to our road map for 2012, we pursued the port of an existing PDF
 viewer as native application to Genode.
 
-We first looked at the [http://poppler.freedesktop.org - libpoppler],
+We first looked at the [https://poppler.freedesktop.org - libpoppler],
 which seems to be the most popular PDF rendering engine in the world of
 freedesktop.org. To get a grasp on what the porting effort of this engine may
 be, we looked at projects using this library as well as the library source
@@ -678,7 +678,7 @@ employing a full-blown ACPI interpreter, the ACPI driver uses an ingenious
 technique invented by Bernhard Kauer, which is described in the following
 paper:
 
-:[http://os.inf.tu-dresden.de/papers_ps/tr-atare-2009.pdf - ATARE - ACPI Tables and Regular Expressions]:
+:[https://os.inf.tu-dresden.de/papers_ps/tr-atare-2009.pdf - ATARE - ACPI Tables and Regular Expressions]:
   _TU Dresden technical report TUD-FI09-09, Dresden, Germany, August 2009_
 
 :Usage:

doc/release_notes-12-05.txt

@@ -17,7 +17,7 @@ The highlights are the introduction of Genode's file-system infrastructure and
 a new concept for the dynamic adjustment of the system's behaviour at runtime.
 
 The release follows the rough plan we laid out in our
-[http://genode.org/about/road-map - road map]. One planned road-map item was
+[https://genode.org/about/road-map - road map]. One planned road-map item was
 revisiting our base of device drivers as we realized that some important
 drivers were not on par with our requirements, the USB stack being the most
 important example. Our prior existing solution was originally ported from Linux
@@ -619,8 +619,8 @@ from the official zlib mirrors.
 
 :Video codecs via libav:
 
-The [http://libav.org - libav project] is one successor of the popular
-[http://ffmpeg.org/ - FFmpeg] library, which is a comprehensive solution
+The [https://libav.org - libav project] is one successor of the popular
+[https://ffmpeg.org/ - FFmpeg] library, which is a comprehensive solution
 for video and audio decoding, conversion, and streaming. The version
 0.8.2 of libav has been incorporated into the libports repository.
 
@@ -645,7 +645,7 @@ versatile test tool, which loads and runs test scripts configured with
 Genode's config mechanism. Test results can be aggregated, printed, and
 analyzed at runtime by scripts.
 
-:[http://lua.org/]: Lua programming language
+:[https://lua.org/]: Lua programming language
 
 
 libSDL
@@ -743,7 +743,7 @@ player. It consists of the following pieces.
 [image media_player]
   The unmodified 'avplay' embedded in Qt4-based GUI.
   The media file was downloaded from
-  http://www.youtube.com/watch?v=CbtAP3kUCxs.
+  https://www.youtube.com/watch?v=CbtAP3kUCxs.
 
 The latter part is particularly interesting because it makes creative use of
 Genode's unique service virtualization facilities. The 'qt_avplay' program

doc/release_notes-12-08.txt

@@ -48,7 +48,7 @@ the genode.org website via the lighttpd web server,
 
 :What about the road map?:
 
-Those of you who track the milestones laid out in our [http:/about/road-map - road map]
+Those of you who track the milestones laid out in our [https://genode.org/about/road-map - road map]
 may wonder how Genode 12.08 relates to the stated goals. In fact, several
 points of the road map haven't received the attention as originally planned.
 As an explanation, let us quote the paragraph right atop of the road-map page:
@@ -152,10 +152,10 @@ you will see the new 'hw_panda_a2', 'hw_vea9x4', 'hw_pbxa9' choices of
 build-directory templates. The latter platform enables you to run a
 'base-hw' Genode system on Qemu.
 
-[http://genode.org/documentation/platforms/hw - Learn more about using the new base-hw platform...]
+[https://genode.org/documentation/platforms/hw - Learn more about using the new base-hw platform...]
 
 For running Genode directly on the Pandaboard, please refer to the
-[http://genode.org/documentation/platforms/hw_panda_a2 - Pandaboard-specific documentation...]
+[https://genode.org/documentation/platforms/hw_panda_a2 - Pandaboard-specific documentation...]
 
 
 Embracing the NOVA Hypervisor
@@ -406,14 +406,14 @@ New and updated 3rd-party libraries
 
 :Expat:
 
-[http://expat.sourceforge.net - Expat] is an XML parsing library. The port of
+[https://expat.sourceforge.net - Expat] is an XML parsing library. The port of
 this library was motivated by our goal to use the GNU debugger for on-target
 debugging. GDB depends on this library.
 
 :MPC and GMP:
 
 We complemented our existing port of the
-[http://gmplib.org - GNU multiple precision arithmetic library (libgmp)] with
+[https://gmplib.org - GNU multiple precision arithmetic library (libgmp)] with
 support for the x86_64 and ARM architectures. This change combined with the
 port of the [http://www.multiprecision.org/index.php?prog=mpc - MPC library]
 enables us to build the Genode tool chain for these architectures.
@@ -437,14 +437,14 @@ on it.
 
 :PCRE:
 
-[http://www.pcre.org/ - PCRE] is a library for parsing regular rexpressions. We
+[https://www.pcre.org/ - PCRE] is a library for parsing regular rexpressions. We
 require this library for our ongoing work on porting the lighttpd webserver.
 
 
 Lighttpd web server
 ===================
 
-The [http://www.lighttpd.net/ - Lighttpd] web server has been added to the
+The [https://www.lighttpd.net/ - Lighttpd] web server has been added to the
 'ports' repository. The port runs as a native Genode application and ultimately
 clears the way to hosting the genode.org website on Genode. To test drive this
 scenario, please give the 'ports/run/genode_org.run' script a try.

doc/release_notes-12-11.txt

@@ -328,7 +328,7 @@ To prevent the TCP/IP stack from artificially throttling TCP throughput,
 we adjusted lwIP's TCP_SND_BUF size.
 
 From our work on optimizing the NIC stub-code performance of L4Linux as
-described [http://genode.org/documentation/articles/pandaboard - here],
+described [https://genode.org/documentation/articles/pandaboard - here],
 we learned that the use of a NIC-specific packet allocator for the
 packet-stream interface is beneficial. At the lwIP back end, we still relied on
 the original general-purpose allocator. Hence, we improved the lwIP back-end
@@ -368,7 +368,7 @@ device-driver environment for the audio drivers of the Open Sound System (OSS).
 
 :Website of the Open Sound System:
 
-  [http://http://www.4front-tech.com]
+  [http://www.4front-tech.com]
 
 The new 'dde_oss' contains all the pieces needed to use Intel HDA, AC97, and
 ES1370 audio cards on Genode. On first use, the 3rd-party code can be
@@ -732,4 +732,4 @@ refer to the tool-chain website:
 
 :Genode tool chain:
 
-  [http://genode.org/download/tool-chain]
+  [https://genode.org/download/tool-chain]

doc/release_notes-13-02.txt

@@ -172,7 +172,7 @@ Full virtualization on NOVA/x86
 
 Vancouver is a x86 virtual machine monitor that is designed to run as
 user-level process on top of the NOVA hypervisor. In
-[http://genode.org/documentation/release-notes/11.11#Faithful_x86_PC_Virtualization_enabled_by_the_Vancouver_VMM - Genode version 11.11],
+[https://genode.org/documentation/release-notes/11.11#Faithful_x86_PC_Virtualization_enabled_by_the_Vancouver_VMM - Genode version 11.11],
 we introduced the preliminary adaptation of Vancouver to Genode. This version
 was meant as a mere proof of concept, which allowed the bootup of small Guest
 OSes (such as Fiasco.OC or Pistachio) inside the VMM. However, it did not
@@ -379,7 +379,7 @@ Trimmed and unified framework API
 =================================
 
 A though-provoking
-[http://sourceforge.net/mailarchive/forum.php?thread_name=CAGQ-%3Dq27%2B_UooBiJmz9RdTE1gDmVcg9v0w-8TNgEH5fzHYiA%2BQ%40mail.gmail.com&forum_name=genode-main - posting]
+[https://sourceforge.net/mailarchive/forum.php?thread_name=CAGQ-%3Dq27%2B_UooBiJmz9RdTE1gDmVcg9v0w-8TNgEH5fzHYiA%2BQ%40mail.gmail.com&forum_name=genode-main - posting]
 on our mailing list prompted us to explore the idea to make shared libraries
 and dynamically linked executables binary compatible among different kernels.
 This sounds a bit crazy at first but it is not downright infeasible.

doc/release_notes-13-05.txt

@@ -9,7 +9,7 @@
 
 
 With Genode 13.05, we have diverged quite a bit from the feature-laden plans
-laid out in our [http://genode.org/about/road-map road map] as we realized
+laid out in our [https://genode.org/about/road-map road map] as we realized
 that consolidating and optimizing the current feature set will have a more
 sustainable effect than functional enhancements at this point. In particular,
 we addressed the problem that the ever growing diversity of platforms imposes
@@ -110,7 +110,7 @@ TFTP boot x86
 The following description uses NOVA as an example to illustrate the usage.
 Other base platforms are supported as well and can be configured analogously.
 
-[http://os.inf.tu-dresden.de/~us15/pulsar/ - Pulsar] is a tiny boot loader
+[https://os.inf.tu-dresden.de/~us15/pulsar/ - Pulsar] is a tiny boot loader
 that uses PXE to fetch boot images via TFTP over the network. On the x86
 architecture, Genode supports the automatic generation of Pulsar configuration
 files, which can be placed directly onto a TFTP server. Genode can be booted
@@ -345,7 +345,7 @@ each requiring a dedicated 'Terminal::Session'. Hence, we need a way to
 multiplex the 'Terminal::Session' interface between those clients. Our
 multiplexing solution comes in the form of a component called terminal_mux,
 which we just introduced in the
-[http://genode.org/documentation/release-notes/13.02#New_terminal_multiplexer - previous release].
+[https://genode.org/documentation/release-notes/13.02#New_terminal_multiplexer - previous release].
 It uses a single terminal connection to implement a text-based user interface
 to multiple virtual terminal consoles.
 
@@ -400,7 +400,7 @@ unsynchronized class interfaces.
 :MMIO framework improvements:
 
 For native Genode device drivers, we consistently use our
-[http://genode.org/documentation/release-notes/12.02#MMIO_access_framework - MMIO framework API].
+[https://genode.org/documentation/release-notes/12.02#MMIO_access_framework - MMIO framework API].
 These utilities help us to safeguard the access to individual bit fields of
 memory-mapped device registers and cleanly separate the declaration of device
 registers from the driver logic. During the increased use of the API, we
@@ -669,7 +669,7 @@ particular, we addressed USB networking, XHCI (USB-3), Gigabit networking over
 USB-3, eMMC, and SATA.
 
 The development of those device drivers follows our rationale that guided our
-[http://genode.org/documentation/articles/pandaboard - previous work on the OMAP4 platform].
+[https://genode.org/documentation/articles/pandaboard - previous work on the OMAP4 platform].
 For the USB driver, we employed the device-driver-environment (DDE) approach
 for reusing the Linux USB stack and the host controller drivers. In contrast,
 the eMMC and SATA drivers are built as genuine Genode drivers with no
@@ -747,7 +747,7 @@ The OMAP4 framebuffer driver used to support HDMI only, which was used
 for connecting a display to the Pandaboard. To make the driver usable on
 phones and tablets, the driver has been enhanced to support LCD output. Thanks
 to Alexander Tarasikov for the patch and the insightful story about
-[http://allsoftwaresucks.blogspot.com/2013/05/porting-genode-to-commercial-hardware.html - porting Genode to the B&N Nook HD+ tablet]!
+[https://allsoftwaresucks.blogspot.com/2013/05/porting-genode-to-commercial-hardware.html - porting Genode to the B&N Nook HD+ tablet]!
 
 
 USB

doc/release_notes-13-08.txt

@@ -533,7 +533,7 @@ Management of CPU affinities
 ============================
 
 In line with our experience of supporting
-[http://www.genode.org/documentation/release-notes/10.02#Real-time_priorities - real-time priorities]
+[https://genode.org/documentation/release-notes/10.02#Real-time_priorities - real-time priorities]
 in version 10.02, we were seeking a way to express CPU affinities such that
 Genode's recursive nature gets preserved and facilitated. Dealing with
 physical CPU numbers would contradict with this mission. Our solution

doc/release_notes-14-02.txt

@@ -203,7 +203,7 @@ but less so with file systems that are well supported by the Linux kernel.
 Coincidentally, when we came to this realization, we stumbled upon the
 wonderful work of Antti Kantee on so-called rump kernels:
 
-:[http://wiki.netbsd.org/rumpkernel/]:
+:[https://wiki.netbsd.org/rumpkernel/]:
   Rump kernel Wiki
 
 The motivation behind the rump kernels was the development of
@@ -394,7 +394,7 @@ Block cache
 ===========
 
 The provisioning of a block cache was one of the primary motivations behind the
-[http://www.genode.org/documentation/release-notes/13.11#Dynamic_resource_balancing - dynamic resource balancing]
+[https://genode.org/documentation/release-notes/13.11#Dynamic_resource_balancing - dynamic resource balancing]
 concept that was introduced in Genode 13.11. We are now introducing the first
 version of such a cache.
 

doc/release_notes-14-05.txt

@@ -214,7 +214,7 @@ Unification of the ports management
 With the new source-tree layout in place, we could pursue a new take on
 unifying the management of ported 3rd-party source code. The new solution,
 which is very much inspired by the fabulous
-[http://nixos.org/nix - Nix package manager] comes in the form of new tools to
+[https://nixos.org/nix - Nix package manager] comes in the form of new tools to
 be found at 'tool/ports/'.
 
 Note that even though the port mechanism described herein looks a bit like
@@ -268,7 +268,7 @@ please refer to the updated porting guide:
 
 :Genode Porting Guide:
 
-  [http://genode.org/documentation/developer-resources/porting]
+  [https://genode.org/documentation/developer-resources/porting]
 
 
 :Known limitations:

doc/release_notes-14-08.txt

@@ -415,7 +415,7 @@ ROM session interface
 
 Originally, the ROM session interface had been designed for providing boot
 modules to the user land. Later, in version
-[http://genode.org/documentation/release-notes/12.05#System_reconfiguration_at_runtime - 12.05],
+[https://genode.org/documentation/release-notes/12.05#System_reconfiguration_at_runtime - 12.05],
 we enhanced the interface to support dynamic updates of ROM modules to
 facilitate the reconfiguration of components at runtime. In the meanwhile,
 the dynamic updating of ROM modules has become commonplace within Genode,
@@ -479,7 +479,7 @@ Pluggable VFS file systems
 ==========================
 
 The virtual file system (VFS) infrastructure introduced with version
-[http://genode.org/documentation/release-notes/14.05#Per-process_virtual_file_systems - 14.05],
+[https://genode.org/documentation/release-notes/14.05#Per-process_virtual_file_systems - 14.05],
 supports a number of built-in file-system types such as the TAR, ROM, FS,
 block, terminal, or LOG file systems. It allows the tailoring of the
 file-system environment specifically for each individual program.
@@ -1030,7 +1030,7 @@ Finished transition to new ports mechanism
 ==========================================
 
 In version 14.05, we introduced
-[http://genode.org/documentation/release-notes/14.05#Management_of_ported_3rd-party_source_code - new tools]
+[https://genode.org/documentation/release-notes/14.05#Management_of_ported_3rd-party_source_code - new tools]
 for integrating 3rd-party software with Genode and migrated the majority of
 our ports to the new mechanism. With the current version, we have finished the
 transition by migrating the remaining ports, namely Qt5, GCC, and GDB.

doc/release_notes-14-11.txt

@@ -402,7 +402,7 @@ modules:
 
 Furthermore all Intel wireless cards supported by the 'iwlwifi' driver need a
 specific firmware to work. You can download the archives containing the
-firmware from [http://wireless.kernel.org/en/users/Drivers/iwlwifi]. The
+firmware from [https://wireless.kernel.org/en/users/Drivers/iwlwifi]. The
 firmware image also has to be added to the boot module list. If the firmware
 is missing, the driver will complain and print an error message:
 
@@ -556,7 +556,7 @@ For realizing graphical applications that are security critical, we wish to
 avoid the complexity of sophisticated tool kits like Qt5. To ease the
 development of such Genode-specific graphical applications, we introduced a
 few common low-level interfaces and utilities for graphics in
-[http://genode.org/documentation/release-notes/14.02#Unified_interfaces_for_graphics - version 14.02].
+[https://genode.org/documentation/release-notes/14.02#Unified_interfaces_for_graphics - version 14.02].
 
 The current version refines those utilities with added support for layering
 graphics using alpha channels. There is a new ALPHA8 pixel format that can be
@@ -637,7 +637,7 @@ Growing tool kit for low-complexity GUI applications
 ====================================================
 
 With the current release, we continue our line of GUI-related work started in
-[http://genode.org/documentation/release-notes/14.08#New_GUI_architecture - version 14.08].
+[https://genode.org/documentation/release-notes/14.08#New_GUI_architecture - version 14.08].
 As a side product of implementing low-complexity GUI components directly on
 Genode instead of using existing GUI tool kits, a library of common utilities
 is evolving. The utilities are not strictly GUI-related but also cover the
@@ -935,7 +935,7 @@ Raspberry Pi
 ============
 
 Genode added principle support for the Raspberry Pi one year ago in
-[http://genode.org/documentation/release-notes/13.11#Raspberry_Pi - version 13.11].
+[https://genode.org/documentation/release-notes/13.11#Raspberry_Pi - version 13.11].
 Back then, the driver support covered the interrupt controller, timer, UART,
 display, and USB. The latter was particularly challenging because the DWC-OTG
 USB host controller lacked public documentation. Hence, we ported the driver
@@ -1035,7 +1035,7 @@ amttool, which uses a SOAP EOI protocol for communication. Newer hardware with
 AMT version 9 or higher dropped the support for SOAP EOI - read
 [https://software.intel.com/en-us/blogs/2012/12/01/intel-amt-wsman-interface-is-replacing-the-soapeoi-interface - a blog entry by Intel]
 for more details - switched to the
-[http://www.dmtf.org/standards/wsman - WSMAN interface]. The tool wsman on
+[https://www.dmtf.org/standards/wsman - WSMAN interface]. The tool wsman on
 Linux speaks the protocol and can be used as a replacement. We integrated the
 support of wsman into our run tool infrastructure and use it by default if
 installed - otherwise amttool will be used. Of course, you can enforce your

doc/release_notes-15-02.txt

@@ -8,7 +8,7 @@
 
 
 
-Genode's [http://genode.org/about/road-map - roadmap] for this year puts a
+Genode's [https://genode.org/about/road-map - roadmap] for this year puts a
 strong emphasis on the consolidation and cultivation of the existing feature
 set. With the first release of the year, version 15.02 pays tribute to this
 mission by stepping up to extensive and systematic automated testing. As
@@ -46,7 +46,7 @@ Cortex-A15-based Arndale board.
 
 While integrating ARM's virtualization extension, we aimed to strictly follow
 microkernel-construction principles. The primary design is inspired by the
-[http://hypervisor.org/ - NOVA OS Virtualization Architecture]. It is based on a
+[https://hypervisor.org/ - NOVA OS Virtualization Architecture]. It is based on a
 microhypervisor that provides essential microkernel mechanisms along with
 basic primitives to switch between virtual machines (VMs). On top of the
 microhypervisor, classical OS services are implemented as
@@ -71,7 +71,7 @@ Design
 
 The ARM virtualization extensions are based on the so-called security
 extensions, commonly known as
-[http://genode.org/documentation/articles/trustzone - TrustZone].
+[https://genode.org/documentation/articles/trustzone - TrustZone].
 The ARM designers did not follow the
 Intel approach to split the CPU into a "root" and a "guest" world while having all prior
 existing CPU modes available in both worlds. Instead, ARM added a new privilege level
@@ -206,7 +206,7 @@ Modular tool kit for automated testing
 ######################################
 
 In
-[http://genode.org/documentation/release-notes/13.05#Automated_quality-assurance_testing - Genode version 13.05],
+[https://genode.org/documentation/release-notes/13.05#Automated_quality-assurance_testing - Genode version 13.05],
 we already introduced comprehensive support for the automated testing of
 Genode scenarios. Since then, Genode Labs has significantly widened the scope
 of its internal test infrastructure, both in terms of the coverage of the test
@@ -391,7 +391,7 @@ the physical address ranges of memory:
 
 * When using an IOMMU on NOVA, Genode represents the address space
   accessible by devices (by the means of DMA) using a so-called device PD
-  ([http://genode.org/documentation/release-notes/13.02#DMA_protection_via_IOMMU]).
+  ([https://genode.org/documentation/release-notes/13.02#DMA_protection_via_IOMMU]).
   DMA transactions originating from PCI devices are subjected to the virtual
   address space of the device PD.
   All DMA buffers are identity-mapped with their physical addresses within
@@ -739,7 +739,7 @@ includes hardware, software, and firmware. This motivated us to
 bring Genode to this platform.
 
 The underlying idea is to facilitate
-[http://genode.org/documentation/articles/trustzone - ARM TrustZone] to
+[https://genode.org/documentation/articles/trustzone - ARM TrustZone] to
 use Genode as a companion to a Linux-based OS on the platform.
 Whereas Linux would run in the normal world of TrustZone, Genode runs
 in the secure world. With Linux, the normal world will control the

doc/release_notes-15-05.txt

@@ -66,7 +66,7 @@ completely written from scratch:
 
 The book is published under the Creative Commons Attribution + ShareAlike
 License (CC-BY-SA) and can be downloaded as
-[http://genode.org/documentation/genode-foundations-15-05.pdf - PDF document].
+[https://genode.org/documentation/genode-foundations-15-05.pdf - PDF document].
 
 It first presents the motivation behind our project, followed by a thorough
 description of the Genode OS architecture. The conceptual material is
@@ -74,7 +74,7 @@ complemented with practical information for developers and a discussion of
 framework internals. The second part of the book serves as a reference of
 Genode's programming interfaces.
 
-[http://genode.org/documentation/genode-foundations-15-05.pdf - Download the book (PDF)...]
+[https://genode.org/documentation/genode-foundations-15-05.pdf - Download the book (PDF)...]
 
 In the upcoming weeks, we plan to update the documentation section of the
 genode.org website with the new material. Until then, we hope you find the
@@ -135,8 +135,8 @@ Principal support for the 64-bit x86 architecture
 _This section was written by Adrian-Ken Rueegsegger and Reto Buerki who_
 _conducted the described line of work independent from Genode Labs._
 
-The [http://muen.sk - Muen Separation Kernel (SK) project] is an Open-Source
-microkernel, which uses the [http://spark-2014.org/ - SPARK] programming
+The [https://muen.sk - Muen Separation Kernel (SK) project] is an Open-Source
+microkernel, which uses the [https://spark-2014.org/ - SPARK] programming
 language to enable light-weight formal methods for high assurance. The 64-bit
 x86 kernel, currently consisting of a little over 5'000 LOC, makes extensive
 use of the latest Intel virtualization features and has been formally proven
@@ -337,7 +337,7 @@ Dynamic thread weights
 ======================
 
 With the Genode release 14.11, we introduced an entirely
-[http://genode.org/documentation/release-notes/14.11#Trading_CPU_time_between_components_using_the_HW_kernel - new scheduler]
+[https://genode.org/documentation/release-notes/14.11#Trading_CPU_time_between_components_using_the_HW_kernel - new scheduler]
 in the base-hw kernel that allows for the trading of CPU time between Genode
 components. This scheduler knows two parameters for each scheduling context: A
 priority that models the urgency for low-latency execution and a quota that
@@ -688,7 +688,7 @@ File-system utilities
 =====================
 
 When we introduced Genode's file-system session interface in
-[http://genode.org/documentation/release-notes/12.05#New_file-system_infrastructure - version 12.05],
+[https://genode.org/documentation/release-notes/12.05#New_file-system_infrastructure - version 12.05],
 it was accompanied with a RAM file system as the first implementation. Since
 then, a growing number of file-system services were developed, which took the
 RAM file system as blue print. Over the years, this practice resulted in the
@@ -902,7 +902,7 @@ Board support for i.MX6-based Wandboard
 The increasing interest in the combination of Genode and the Freescale i.MX6
 SoC motivated us to add official support for a board based on this SoC
 to our custom kernel. We settled on the
-[http://www.wandboard.org/ - Wandboard Quad] that was developed on a volunteer
+[https://www.wandboard.org/ - Wandboard Quad] that was developed on a volunteer
 basis. Thanks to Praveen Srinivas (IIT Madras, India) and Nikolay Golikov
 (Ksys Labs LLC, Russia) who contributed their work on i.MX6. The Wandboard
 Quad features 2 GiB of DDR3 RAM and a quad-core Cortex-A9 CPU. So, unlike when
@@ -984,7 +984,7 @@ USB-device pass-through support
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 With the availability of the
-[http://www.genode.org/documentation/release-notes/15.02#USB_session_interface - USB session interface]
+[https://genode.org/documentation/release-notes/15.02#USB_session_interface - USB session interface]
 and the new [USB device-list report] feature of the USB driver, it is now
 possible to pass a selection of raw USB devices directly to VirtualBox guests.
 
@@ -1024,7 +1024,7 @@ Platforms
 Proof-of-concept support for the seL4 kernel
 ============================================
 
-Since last summer when the [http://sel4.systems - seL4 kernel] was released
+Since last summer when the [https://sel4.systems - seL4 kernel] was released
 under the General Public License, we entertained the idea to run Genode on
 this kernel. As the name suggests, the seL4 kernel is a member of the L4
 family of kernels. But there are two things that set this kernel apart from
@@ -1040,7 +1040,7 @@ Since last autumn, we conducted the port of Genode to the seL4 kernel as
 background activity. We took the chance to thoroughly document our experience
 by the following series of articles:
 
-:[http://genode.org/documentation/articles/sel4_part_1 - Building a simple root task from scratch]:
+:[https://genode.org/documentation/articles/sel4_part_1 - Building a simple root task from scratch]:
   The first article describes the integration of the kernel code with Genode's
   source tree and the steps taken to create a minimalistic root task that runs
   on the kernel. It is full of hands-on information about the methodology of
@@ -1048,12 +1048,12 @@ by the following series of articles:
   from the perspective of someone with no prior association with the seL4
   project.
 
-:[http://genode.org/documentation/articles/sel4_part_2 - IPC and virtual memory]:
+:[https://genode.org/documentation/articles/sel4_part_2 - IPC and virtual memory]:
   The second part of the article series examines the seL4 kernel interface
   with respect to synchronous inter-process communication and the management
   of virtual memory.
 
-:[http://genode.org/documentation/articles/sel4_part_3 - Porting the core component]:
+:[https://genode.org/documentation/articles/sel4_part_3 - Porting the core component]:
   The third article presents the steps taken to bring Genode's core and init
   components to life. Among the covered topics are the memory and capability
   management, inter-component communication, and page-fault handling. The
@@ -1167,7 +1167,7 @@ development environment and the tool chain running within Genode's Noux
 runtime environment.
 
 To use Genode 15.05, please obtain and install the new binary version of the
-tool chain available at [http://genode.org/download/tool-chain] or build it
+tool chain available at [https://genode.org/download/tool-chain] or build it
 manually via the _tool/tool_chain_ script.
 
 
@@ -1205,7 +1205,7 @@ The following parts have been pruned from the Genode source tree:
 
 * The _linux_drivers_ repository hosted device drivers ported via the
   original DDE-Linux approach. We
-  [http://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment - disregarded this approach]
+  [https://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment - disregarded this approach]
   in 2012. The only remaining code worth keeping is the i915 GPU driver, which
   will potentially re-appear in our modern _repos/dde_linux_ repository.
 

doc/release_notes-15-08.txt

@@ -47,13 +47,13 @@ _conducted the described line of work independent from Genode Labs._
 
 After completing our x86_64 port of the Genode base-hw kernel, which was
 featured in the
-[http://genode.org/documentation/release-notes/15.05#Principal_support_for_the_64-bit_x86_architecture - previous release (15.05)],
+[https://genode.org/documentation/release-notes/15.05#Principal_support_for_the_64-bit_x86_architecture - previous release (15.05)],
 we immediately started working on our main goal: running a Genode system as
 guest on the Muen Separation Kernel (SK). This would enable the Muen platform
 to benefit from the rich ecosystem of Genode.
 
-For those who have not read the 15.05 Genode release notes, [http://muen.sk - Muen]
-is an Open-Source microkernel, which uses the [http://spark-2014.org/ - SPARK]
+For those who have not read the 15.05 Genode release notes, [https://muen.sk - Muen]
+is an Open-Source microkernel, which uses the [https://spark-2014.org/ - SPARK]
 programming language to enable light-weight formal methods for high assurance.
 The 64-bit x86 kernel, currently consisting of a little over 5'000 LOC, makes
 extensive use of the latest Intel virtualization features and has been formally
@@ -194,18 +194,18 @@ Our modified version of the NOVA microhypervisor is the used kernel.
 The user interface is based on our custom GUI stack including the nitpicker
 GUI server as well as the window manager and its companion components
 (decorator, layouter, pointer) we introduced in
-[http://genode.org/documentation/release-notes/14.08#New_GUI_architecture - version 14.08].
+[https://genode.org/documentation/release-notes/14.08#New_GUI_architecture - version 14.08].
 The display is driven by the VESA driver. User input is handled by the PS/2
 driver for handling the laptop keyboard and trackpoint, and the USB driver for
 handling an externally connected keyboard and mouse.
 
 Network connectivity is provided by our port of the Intel Wireless stack that
 we introduced with the version
-[http://genode.org/documentation/release-notes/14.11#Intel_wireless_stack - 14.11].
+[https://genode.org/documentation/release-notes/14.11#Intel_wireless_stack - 14.11].
 
 Our custom AHCI driver provides access to the physical hard disk. File-system
 access is provided by our
-[http://genode.org/documentation/release-notes/14.02#NetBSD_file_systems_using_rump_kernels - Rump-kernel-based file-system server].
+[https://genode.org/documentation/release-notes/14.02#NetBSD_file_systems_using_rump_kernels - Rump-kernel-based file-system server].
 
 A simple Genode shell called CLI monitor allows the user to start and kill
 subsystems dynamically. Initially, the two most important subsystems are
@@ -383,9 +383,9 @@ systems rely on a virtual file system (VFS) implemented in the OS kernel,
 Genode's VFS has the form of a library that can optionally be linked to a
 component. The implementation of this library originated from the noux runtime
 introduced in version
-[http://genode.org/documentation/release-notes/11.02#Noux_-_an_execution_environment_for_the_GNU_userland - 11.02],
+[https://genode.org/documentation/release-notes/11.02#Noux_-_an_execution_environment_for_the_GNU_userland - 11.02],
 and was later integrated into our C runtime in version
-[http://genode.org/documentation/release-notes/14.05#Per-process_virtual_file_systems - 14.05].
+[https://genode.org/documentation/release-notes/14.05#Per-process_virtual_file_systems - 14.05].
 With the current release, we take the VFS a step further by making it
 available to components without a C runtime. Thereby, low-complexity
 security-sensitive components such as CLI monitor become able to benefit from
@@ -435,7 +435,7 @@ and identifying effective optimization vectors, tools for gathering a holistic
 view of the system are highly desired.
 
 With the introduction of our light-weight
-[http://genode.org/documentation/release-notes/13.08#Light-weight_event_tracing - event-tracing facility]
+[https://genode.org/documentation/release-notes/13.08#Light-weight_event_tracing - event-tracing facility]
 in version 13.08, we laid the foundation for such tools. The current release
 extends core's TRACE service with the ability to obtain statistics about CPU
 utilization. More specifically, it enables clients of core's TRACE service to
@@ -513,7 +513,7 @@ and PCI drivers. The ACPI driver originally executed the PCI driver as a slave
 (child) service. The ACPI driver parsed the ACPI tables and provided the
 relevant information as configuration during the PCI-driver startup. We
 changed this close coupling to the more modern and commonly used
-[http://genode.org/documentation/release-notes/14.02#New_session_interface_for_status_reporting - report_rom mechanism].
+[https://genode.org/documentation/release-notes/14.02#New_session_interface_for_status_reporting - report_rom mechanism].
 
 When the new ACPI driver finishes the ACPI table parsing, it provides the
 information via a report to any interested and registered components. The
@@ -784,8 +784,8 @@ common API among the execution environments of ported user-level device
 drivers. However, over the course of the past years, we found that this
 approach could not fulfill its promise while introducing a number of new
 problems. We reported our experiences in the release notes of versions
-[http://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment - 12.05] and
-[http://genode.org/documentation/release-notes/14.11#Roundup - 14.11].
+[https://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment - 12.05] and
+[https://genode.org/documentation/release-notes/14.11#Roundup - 14.11].
 To be able to remove the DDE-Kit API, we reworked the USB driver, our port of
 the Linux TCP/IP stack, and the wireless driver accordingly.
 

doc/release_notes-15-11.txt

@@ -9,7 +9,7 @@
 
 
 In the
-[http://genode.org/documentation/release-notes/15.08 - previous release],
+[https://genode.org/documentation/release-notes/15.08 - previous release],
 we proudly reported the initial use of Genode as day-to-day OS. With the
 current release, we maintained the strong focus on making Genode viable as the
 foundation of a desktop OS. There are many aspects to be considered, ranging
@@ -30,7 +30,7 @@ Armory (a dedicated article about this work will follow soon), added support
 for Xilinx Zynq-7000, and optimized our version of VirtualBox for NOVA.
 
 According to our
-[http://genode.org/about/road-map - road map], we planned to address package
+[https://genode.org/about/road-map - road map], we planned to address package
 management, a modern web browser, and cross-kernel binary compatibility with
 the version 15.11. However, we decided to put emphasis on the general
 usability, robustness, and scalability first, before entering new
@@ -106,7 +106,7 @@ as well as high-level applications:
   without the need to restart it?
 
 We attempted to answer these questions with a single mechanism in version
-[http://genode.org/documentation/release-notes/12.05#System_reconfiguration_at_runtime - 12.05].
+[https://genode.org/documentation/release-notes/12.05#System_reconfiguration_at_runtime - 12.05].
 But the scalability of the approach remained unproven until now.
 
 In short, configuration information is supplied to a component by its
@@ -201,7 +201,7 @@ similar common GUI elements. These parts of the GUI must be implemented at the
 client side.
 
 In
-[http://genode.org/documentation/release-notes/14.08#New_GUI_architecture - version 14.08],
+[https://genode.org/documentation/release-notes/14.08#New_GUI_architecture - version 14.08],
 we laid the foundation for a scalable GUI architecture that further reduced
 the functional scope of nitpicker and complements nitpicker with higher-level
 components for managing windows. Thanks to this architecture, most of
@@ -1067,11 +1067,11 @@ from Linux kernel 3.14.5 to Genode. We successfully tested it on machines
 containing Intel GPUs from generation five up to generation eight. With the
 port of the Intel driver to Genode, we followed the approach that we already
 used to enable the USB stack on Genode described in
-[http://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment - release 12.05],
+[https://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment - release 12.05],
 to enable the Linux TCP/IP stack in
-[http://genode.org/documentation/release-notes/13.11#Gigabit_networking_using_the_Linux_TCP_IP_stack - release 13.11],
+[https://genode.org/documentation/release-notes/13.11#Gigabit_networking_using_the_Linux_TCP_IP_stack - release 13.11],
 and more recently to enable the Intel wireless stack in
-[http://genode.org/documentation/release-notes/14.11#Intel_wireless_stack - release 14.11].
+[https://genode.org/documentation/release-notes/14.11#Intel_wireless_stack - release 14.11].
 
 The driver can be configured dynamically at run-time via the config
 ROM-mechanism. Each connector of the graphics card can be configured
@@ -1303,14 +1303,14 @@ You can build the demo by executing
 A tutorial on how to create a bootable SD card can be found in the
 corresponding run script _os/tz_vmm.run_. A tutorial on how to reproduce the
 pre-built Linux image, Rootfs and DTB - used by the run script - can be found
-at [http://genode.org/files/release-15.11/usb_armory_tz_vmm/README].
+at [https://genode.org/files/release-15.11/usb_armory_tz_vmm/README].
 
 
 NOVA
 ====
 
 With the release 15.08, we
-[http://genode.org/documentation/release-notes/15.08#NOVA_kernel-resource_management - extended the kernel]
+[https://genode.org/documentation/release-notes/15.08#NOVA_kernel-resource_management - extended the kernel]
 to handle memory quota per Genode component. The line of work for the current
 release built upon those new mechanisms and simplifies the memory management
 within Genode's core component.
@@ -1345,9 +1345,9 @@ Tools and build system
 Run-tool support for booting via the iPXE boot loader
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-[http://ipxe.org - iPXE] is an open source network boot firmware, which
+[https://ipxe.org - iPXE] is an open source network boot firmware, which
 supports booting from a web server
-[http://ipxe.org/howto/chainloading#breaking_the_loop_with_an_embedded_script - via HTTP].
+[https://ipxe.org/howto/chainloading#breaking_the_loop_with_an_embedded_script - via HTTP].
 
 With the new load module at _tool/run/load/ipxe_, Genode's run tool has become
 able to load images via iPXE/HTTP to the test hardware. The following two
@@ -1375,7 +1375,7 @@ This can be achieved by building iPXE with the following embedded script:
 In addition to loading an image, an iPXE boot configuration is required to
 boot the loaded image on the target machine. The run-tool back ends for NOVA,
 Fiasco.OC, and L4/Fiasco have been enhanced to automatically generate such
-configurations, which use the [http://ipxe.org/cmd/sanboot - sanboot command]
+configurations, which use the [https://ipxe.org/cmd/sanboot - sanboot command]
 to download and boot an ISO image via HTTP. To use this boot method, your
 RUN_OPT configuration must specify both the ISO-image and the iPXE-load
 modules:
@@ -1383,7 +1383,7 @@ modules:
 ! RUN_OPT +=  --include image/iso --include load/ipxe
 
 Note that the webserver serving the ISO image must support
-[http://forum.ipxe.org/showthread.php?tid=7295&pid=10482#pid10482 - ranged requests].
+[https://forum.ipxe.org/showthread.php?tid=7295&pid=10482#pid10482 - ranged requests].
 
 Thanks to Adrian-Ken Rueegsegger for these improvements!
 

doc/release_notes-16-02.txt

@@ -48,7 +48,7 @@ version 2.1, which prompted us to fundamentally revisit the low-level resource
 management of Genode on this kernel. A summary of this undertaking is presented
 in Section [seL4 version 2.1].
 
-According to the [http:/about/road-map - road map], we originally planned to
+According to the [https://genode.org/about/road-map - road map], we originally planned to
 revise the framework API in this release. Even though this topic is
 [https://github.com/genodelabs/genode/issues/1832 - very actively pursued], we
 decided to not rush it. We find it important to provide a smooth migration path
@@ -62,7 +62,7 @@ Assignment of USB devices to virtual machines
 
 As a migration strategy for running Genode on a daily basis, using VirtualBox
 to execute a feature-rich OS is vital. In release
-[http://genode.org/documentation/release-notes/15.05#USB-device_pass-through_support - 15.05],
+[https://genode.org/documentation/release-notes/15.05#USB-device_pass-through_support - 15.05],
 we added USB pass-through support to VirtualBox by enabling its integrated USB
 proxy service. Since we use the open-source edition of VirtualBox, we were
 merely able to use the OHCI device model and were therefore limited to using
@@ -181,11 +181,11 @@ The consumer, in this case a VMM, then accesses the USB device (4).
 New support for the RISC-V CPU architecture
 ###########################################
 
-We became aware of [http://riscv.org - RISC-V] when attending several talks
+We became aware of [https://riscv.org - RISC-V] when attending several talks
 about the project at [https://fosdem.org - FOSDEM] in 2015. RISC-V aims to be
 an open-source hardware architecture and is now complemented by many projects
 that target the release of real hardware or ASICs (for example,
-[http://lowrisc.org - the LowRISC project]). We have experience with various
+[https://www.lowrisc.org - the LowRISC project]). We have experience with various
 major CPU architectures and many systems on a chip and, therefore, embrace a
 sharp eye on certain platform properties. Intel's ME and ARM's Trustzone
 practically lock out operating systems of certain hardware and firmware
@@ -195,7 +195,7 @@ AMT technology for instance comes with a complete TCP/IP stack that intercepts
 packets from the integrated NIC and a VNC server that can magically expose a
 mouse and a keyboard at the USB controller. If you are interested in more
 details about this topic
-[http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf - Intel x86 considered harmful]
+[https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf - Intel x86 considered harmful]
 by Joanna Rutkowska is a very good read. We decided to have a deeper look at
 the RISC-V architecture as an alternative open hardware platform. Especially,
 since the LowRISC project promises a completely open system on chip, including
@@ -281,7 +281,7 @@ GUI stack usability improvements
 
 Motivated by the daily use of Genode as desktop OS by an increasingly number
 of developers, the window-layouter component of the
-[http://genode.org/documentation/release-notes/15.11#GUI_stack - GUI stack]
+[https://genode.org/documentation/release-notes/15.11#GUI_stack - GUI stack]
 received welcomed usability improvements.
 
 
@@ -451,7 +451,7 @@ components within the _world_ repository are not subjected to the regular
 quality-assurance measures of Genode Labs. Hence, problems are to be expected.
 If you encounter bugs, build problems, or stability issues, please report them
 to the [https://github.com/genodelabs/genode-world/issues - issue tracker] or
-the [http://genode.org/community/mailing-lists - mailing list].
+the [https://genode.org/community/mailing-lists - mailing list].
 
 
 Updated 3rd-party software
@@ -499,10 +499,10 @@ Build integration
 -----------------
 
 Building Genode scenarios running on top of the
-[http://muen.sk - Muen separation kernel] has been greatly simplified by
+[https://muen.sk - Muen separation kernel] has been greatly simplified by
 properly integrating the Muen system build process into the Genode build system.
 As described in the
-[http://genode.org/documentation/release-notes/15.08#Genode_on_top_of_the_Muen_Separation_Kernel - 15.08 release notes],
+[https://genode.org/documentation/release-notes/15.08#Genode_on_top_of_the_Muen_Separation_Kernel - 15.08 release notes],
 the architecture with Muen is different since the entire hw_x86_64_muen Genode
 system runs as a guest VM on top of the separation kernel. This means that the
 Genode base-hw image must itself be packaged into the final Muen system image
@@ -531,7 +531,7 @@ _image/muen_ run-tool plugin, which processes the following RUN_OPT parameters.
 
 The options are automatically added to the _etc/build.conf_ file for the
 hw_x86_64_muen base-hw platform. The
-[http://genode.org/documentation/platforms/muen - documentation] has been
+[https://genode.org/documentation/platforms/muen - documentation] has been
 updated to reflect the new, simplified build process.
 
 A port file was added to facilitate the download of the Muen sources v0.7 and
@@ -562,7 +562,7 @@ drivers to transparently use MSIs for passed-through PCI devices.
 seL4 version 2.1
 ================
 
-By the end of 2015, the [http://sel4.systems/ - seL4 kernel] version 2.0 was
+By the end of 2015, the [https://sel4.systems/ - seL4 kernel] version 2.0 was
 published. With the current release, we update Genode's preliminary support
 for this kernel from the experimental branch of one year ago to the master
 branch of version 2.1. Note that this line of work is still considered as an

doc/release_notes-16-05.txt

@@ -190,7 +190,7 @@ The changes between the last year's edition and the current revision are:
 : <p>
 :  <div style="clear: both; float: left; margin-right:20px;">
 :   <a class="internal-link" href="https://genode.org">
-:    <img class="image-inline" src="http://genode.org/documentation/genode-foundations-title.png">
+:    <img class="image-inline" src="https://genode.org/documentation/genode-foundations-title.png">
 :   </a>
 :  </div>
 : </p>

doc/release_notes-16-08.txt

@@ -412,7 +412,7 @@ to prepare your system for Muen.
 
 As a next step, create a VirtualBox VM with a 32-bit guest OS of your choice
 and install the guest additions
-[http://download.virtualbox.org/virtualbox/4.3.36/VBoxGuestAdditions_4.3.36.iso].
+[https://download.virtualbox.org/virtualbox/4.3.36/VBoxGuestAdditions_4.3.36.iso].
 In this tutorial, we chose Windows 7.
 
 Note: use guest additions close to the VirtualBox version of Genode. We have
@@ -858,7 +858,7 @@ Init configuration changes
 ==========================
 
 We refined the label-based server-side policy-selection mechanism introduced in
-[http://genode.org/documentation/release-notes/15.11#Label-dependent_session_routing - version 15.11]
+[https://genode.org/documentation/release-notes/15.11#Label-dependent_session_routing - version 15.11]
 to limit the damage of spelling mistakes in manually crafted configurations.
 I.e., consider the following policy of a file-system server with a misspelled
 'label_prefix' attribute:
@@ -1015,7 +1015,7 @@ RISC-V front-end server
 =======================
 
 In version
-[http://genode.org/documentation/release-notes/16.02#New_support_for_the_RISC-V_CPU_architecture - 16.02],
+[https://genode.org/documentation/release-notes/16.02#New_support_for_the_RISC-V_CPU_architecture - 16.02],
 Genode gained support for the RISC-V CPU architecture. Genode can be executed
 on either a simulator or a synthesized FPGA softcore, e.g., on Xilinx Zynq
 FPGAs. On the latter platform, the RISC-V core is a secondary CPU that

doc/release_notes-16-11.txt

@@ -141,7 +141,7 @@ Third, even though not inherent to synchronous RPC, Genode's original design
 facilitated the use of a session capability as argument for requesting the
 parent to close a specific session. However, the use of capabilities as
 re-identifiable tokens is not well supported by most kernels, including seL4
-([http://sel4.systems/pipermail/devel/2014-November/000114.html - discussion]
+([https://sel4.systems/pipermail/devel/2014-November/000114.html - discussion]
 on the seL4 mailing list).
 
 
@@ -534,7 +534,7 @@ Transition to new framework API
 ===============================
 
 Since we fundamentally revised Genode's API in
-[http://genode.org/documentation/release-notes/16.05#The_great_API_renovation - version 16.05],
+[https://genode.org/documentation/release-notes/16.05#The_great_API_renovation - version 16.05],
 we gradually adapt our existing components. Given that Genode comes with
 over 300 components, this is no small feat. But with 30 percent of the
 components converted, we already made substantial progress.
@@ -603,11 +603,11 @@ your own time source, you can find an example at _os/include/os/timer.h_ .
 Support for smart cards
 =======================
 
-We ported the [http://pcsclite.alioth.debian.org/pcsclite.html - PC/SC Lite]
+We ported the [https://pcsclite.alioth.debian.org/pcsclite.html - PC/SC Lite]
 library to Genode, which provides a commonly used API for communicating with
 smart cards. It supports USB smart card readers, using the
-[http://pcsclite.alioth.debian.org/ccid.html - CCID] library as driver.
-The CCID driver itself requires [http://libusb.info - libusb] to access the
+[https://pcsclite.alioth.debian.org/ccid.html - CCID] library as driver.
+The CCID driver itself requires [https://libusb.info - libusb] to access the
 USB device.
 
 Vanilla PC/SC Lite is structured as a client-server architecture, consisting

doc/release_notes-17-05.txt

@@ -154,7 +154,7 @@ edition are:
 : <p>
 :  <div style="clear: both; float: left; margin-right:20px;">
 :   <a class="internal-link" href="https://genode.org">
-:    <img class="image-inline" src="http://genode.org/documentation/genode-foundations-title.png">
+:    <img class="image-inline" src="https://genode.org/documentation/genode-foundations-title.png">
 :   </a>
 :  </div>
 : </p>
@@ -834,7 +834,7 @@ Nim programming language
 ========================
 
 In the previous release, we were proud to debut a
-[http://genode.org/documentation/release-notes/17.02#Linux_TCP_IP_stack_as_VFS_plugin - pluggable TCP/IP stack]
+[https://genode.org/documentation/release-notes/17.02#Linux_TCP_IP_stack_as_VFS_plugin - pluggable TCP/IP stack]
 for the VFS library. This required an overhaul of the Berkley sockets and
 'select' implementation within the POSIX runtime, but scrutiny of the POSIX
 standard leaves us reluctant to endorse it as a network API.

doc/release_notes-17-08.txt

@@ -643,7 +643,7 @@ system partition in a GUID partition table (GPT). The image is equipped by the
 new 'image/uefi' module with the GRUB2 boot loader, a GRUB2 configuration, and
 the corresponding Genode run scenario. The final image can be copied with 'dd'
 to a bootable USB stick. Additionally, we added support to boot such an image
-on Qemu leveraging [http://www.tianocore.org - TianoCore's] UEFI firmware.
+on Qemu leveraging [https://www.tianocore.org - TianoCore's] UEFI firmware.
 
 As a side project, minor virtualization support for AMD has been added to
 Virtualbox 4 and to the NOVA kernel on Genode. This enables us to run a 32-bit

doc/release_notes-18-02.txt

@@ -728,7 +728,7 @@ on Genode:
   noux package. Note, however, that this port comprises solely the
   functionality needed for simple scripting.
 
-:[http://flif.info/ - FLIF]: is a library for the Free Lossless Image
+:[https://flif.info/ - FLIF]: is a library for the Free Lossless Image
   Format. Thanks to Emery Hemingway for making it available in the
   genode-world repository.
 

doc/release_notes-18-05.txt

@@ -95,7 +95,7 @@ since the last year's edition are:
 : <p>
 :  <div style="clear: both; float: left; margin-right:20px;">
 :   <a class="internal-link" href="https://genode.org">
-:    <img class="image-inline" src="http://genode.org/documentation/genode-foundations-title.png">
+:    <img class="image-inline" src="https://genode.org/documentation/genode-foundations-title.png">
 :   </a>
 :  </div>
 : </p>
@@ -603,7 +603,7 @@ Over the course of the past year, we started to look into Java support for
 Genode with the ultimate goal of porting an existing Java Virtual Machine
 (JVM), which translates and executes Java byte code, to Genode. After
 investigating possible JVM candidates, it became obvious that
-[http://openjdk.java.net - OpenJDK] is the only viable option when looking for
+[https://openjdk.java.net - OpenJDK] is the only viable option when looking for
 a functional, maintained, feature complete, and open-source Java SDK.
 Therefore, we decided upon OpenJDK version 9 and started to port OpenJDK's
 HotSpot virtual machine.

doc/release_notes-18-08.txt

@@ -979,7 +979,7 @@ NOVA microhypervisor
 ====================
 
 The NOVA kernel branch in use has been switched to revision r10, which is an
-intermediate result of [http://cyberus-technology.de/ - Cyberus Technology]
+intermediate result of [https://cyberus-technology.de/ - Cyberus Technology]
 and of [https://www.genode-labs.com/ - Genode Labs] to harmonize their
 independently developed NOVA kernel branches. We hope to mutually benefit from
 the evolution of NOVA over the long run by having a common NOVA trunk and

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
+[https://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 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 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
+[https://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

@@ -7,129 +7,128 @@
 Herein, we lay out our plans for evolving Genode. Progress in addition to this
 planning will very much depend on the degree of community support the project
 will receive. The
-[http:/about/challenges - Challenges] page collects some of our ideas to
+[https://genode.org/about/challenges - Challenges] page collects some of our ideas to
 advance Genode in various further directions.
 
 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/doc/fiasco.txt

@@ -1,119 +0,0 @@
-
-        =============================================
-        How to use Genode with the Fiasco microkernel
-        =============================================
-
-
-               Norman Feske, Christian Helmuth
-
-Abstract
-########
-
-This documentation describes the process of building and booting the L4/Fiasco
-version of Genode. It assumes that you are familiar with basic concepts
-described in the introductory documentation of Genode, namely the "How to start
-exploring Genode" document.
-
-
-Preconditions
-#############
-
-The Fiasco version of Genode relies on the following components from
-the source tree of the Fiasco microkernel and the L4 environment (which also
-need additional tools).
-
-
-Tools
-=====
-
-* Gawk
-* Bison
-* Byacc
-* Python
-
-
-The Fiasco microkernel
-======================
-
-Information about Fiasco are provided at its official website:
-
-! http://os.inf.tu-dresden.de/fiasco/prev/
-
-To download the kernel and integrate it with Genode, issue the following
-command from within the toplevel directory:
-
-! ./tool/ports/prepare_port fiasco
-
-For the vesa driver on x86 the x86emu library is required and can be downloaded
-and prepared by invoking the following command:
-
-! ./tool/ports/prepare_port x86emu
-
-This command will download a prepackaged version of the kernel tested
-with Genode. The build process of the kernel is integrated with Genode's
-build system. After creating a build directory using 'create_builddir'
-with 'fiasco_x86' as argument:
-
-! <genode-dir>/tool/create_builddir fiasco_x86 \
-!   BUILD_DIR=<build-dir>
-
-From within the new <build-dir>, the kernel can be compiled via
-
-! make kernel/fiasco
-
-When using Genode's run mechanism, there is no need to explicitly build the
-kernel. The run environment (see 'tool/run/boot_dir/fiasco') takes care of it.
-So you can simple execute run scripts from within the build directory, for
-example:
-
-! make run/demo
-
-
-Behind the scenes
-=================
-
-For using the L4/Fiasco kernel, some basic user-level components and libraries
-are needed. These are subsumed under the name L4 environment an are organized
-as a number of packages. These packages provide two types of components.  There
-are low-level components for booting up and interfacing to Fiasco and there are
-higher-level components that compose a basic OS infrastructure. For Genode, we
-only rely on the low-level packages.
-
-Previous versions of Genode included all necessary sources from the L4
-environment in the '3rd/fiasco/snapshot' subdirectory. From release 10.02, the
-'3rd' directory is no longer part of the release archive and also removed from
-the subversion repository. Please download the '3rd_fiasco.tar.bz2' archive.
-The source are organized as follows
-
-:'tool': contains the tools that are used by the build processes of
-  the L4 environment and Fiasco. For example, the build process of Fiasco
-  relies on the 'preprocess' tool.
-
-:'kernel': contains the Fiasco microkernel.
-
-:'l4': contains the L4-environment source tree. The single packages
-  are located at 'l4/pkg'.
-
-From all the packages of the L4 environment, the following three are of
-interest for using Genode:
-
-:'pkg/l4sys': contains the Fiasco system-call bindings.
-
-  The system-call bindings are a set of C-header files that define the
-  application-programming interface for invoking the system calls of
-  Fiasco.
-
-:'pkg/sigma0':
-
-  Sigma0 is the initial memory manager required to use Fiasco.
-
-:'pkg/bootstrap':
-
-  Bootstrap is the program that is started by the boot loader.
-  After being started, Bootstrap prepares the bare machine to
-  accommodate Fiasco. On many embedded architectures, bootstrap
-  is used to create a single binary image containing all boot-time
-  OS components.
-
-Those components are implicitly built by the Genode build system when
-issuing 'make kernel/fiasco'.

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-05-26 02e84ead88242170c4d025cb7a62c2c2a0549c61

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

@@ -82,7 +82,7 @@ void Irq_object::_wait_for_irq()
 void Irq_object::start()
 {
 	::Thread::start();
-	_sync_bootup.lock();
+	_sync_bootup.block();
 }
 
 
@@ -94,10 +94,10 @@ void Irq_object::entry()
 	}
 
 	/* thread is up and ready */
-	_sync_bootup.unlock();
+	_sync_bootup.wakeup();
 
 	/* wait for first ack_irq */
-	_sync_ack.lock();
+	_sync_ack.block();
 
 	while (true) {
 
@@ -108,7 +108,7 @@ void Irq_object::entry()
 
 		Genode::Signal_transmitter(_sig_cap).submit(1);
 
-		_sync_ack.lock();
+		_sync_ack.block();
 	}
 }
 
@@ -116,7 +116,6 @@ void Irq_object::entry()
 Irq_object::Irq_object(unsigned irq)
 :
 	Thread_deprecated<4096>("irq"),
-	_sync_ack(Lock::LOCKED), _sync_bootup(Lock::LOCKED),
 	_irq(irq)
 { }
 

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,9 +201,6 @@ 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");
 }
 
 

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/config/arndale.kernel

@@ -1,120 +0,0 @@
-#
-# Automatically generated file; DO NOT EDIT.
-# Fiasco configuration
-#
-CONFIG_HAS_FPU_OPTION=y
-CONFIG_HAS_LAZY_FPU=y
-CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
-CONFIG_HAS_SERIAL_OPTION=y
-CONFIG_HAS_JDB_DISASM_OPTION=y
-CONFIG_HAS_JDB_GZIP_OPTION=y
-CONFIG_HAS_MP_OPTION=y
-CONFIG_HAS_CPU_VIRT=y
-
-#
-# Target configuration
-#
-# CONFIG_IA32 is not set
-# CONFIG_AMD64 is not set
-CONFIG_ARM=y
-# CONFIG_MIPS is not set
-# CONFIG_PF_INTEGRATOR is not set
-# CONFIG_PF_REALVIEW is not set
-# CONFIG_PF_SUNXI is not set
-# CONFIG_PF_BCM283X is not set
-# CONFIG_PF_SA1100 is not set
-# CONFIG_PF_XSCALE is not set
-# CONFIG_PF_ARMADA38X is not set
-# CONFIG_PF_KIRKWOOD is not set
-# CONFIG_PF_TEGRA is not set
-# CONFIG_PF_LAYERSCAPE is not set
-# CONFIG_PF_IMX is not set
-# CONFIG_PF_ARM_VIRT is not set
-# CONFIG_PF_RCAR3 is not set
-CONFIG_PF_EXYNOS=y
-# CONFIG_PF_S3C2410 is not set
-# CONFIG_PF_OMAP is not set
-# CONFIG_PF_ZYNQ is not set
-# CONFIG_PF_ZYNQMP is not set
-CONFIG_BSP_NAME="exynos"
-CONFIG_CAN_ARM_CPU_CORTEX_A15=y
-CONFIG_ARM_V7=y
-CONFIG_ARM_V6PLUS=y
-CONFIG_ARM_V7PLUS=y
-CONFIG_PF_EXYNOS5=y
-CONFIG_CPU_SUSPEND=y
-CONFIG_PF_EXYNOS_PKG_IDS=""
-# CONFIG_PF_EXYNOS4_4210 is not set
-# CONFIG_PF_EXYNOS4_4412 is not set
-CONFIG_PF_EXYNOS5_5250=y
-# CONFIG_PF_EXYNOS5_5410 is not set
-CONFIG_PF_EXYNOS_UART_NATIVE=y
-CONFIG_PF_EXYNOS_UART_NR=2
-CONFIG_PF_EXYNOS_TIMER_MCT=y
-# CONFIG_PF_EXYNOS_TIMER_PWM is not set
-# CONFIG_PF_EXYNOS_TIMER_GEN is not set
-CONFIG_ABI_VF=y
-CONFIG_ARM_CORTEX_A15=y
-# CONFIG_CPU_VIRT is not set
-CONFIG_FPU=y
-CONFIG_LAZY_FPU=y
-CONFIG_HAVE_ARM_SECMONIF_NONE=y
-CONFIG_HAVE_ARM_SECMONIF_MC=y
-# CONFIG_ARM_ALIGNMENT_CHECK is not set
-CONFIG_ARM_EM_STD=y
-# CONFIG_ARM_EM_NS is not set
-# CONFIG_ARM_EM_TZ is not set
-# CONFIG_ARM_SMC_USER is not set
-# CONFIG_ARM_ENABLE_SWP is not set
-# CONFIG_ARM_LPAE is not set
-CONFIG_ARM_CPU_ERRATA=y
-
-#
-# Kernel options
-#
-CONFIG_MP=y
-CONFIG_MP_MAX_CPUS=4
-CONFIG_CONTEXT_4K=y
-# CONFIG_FINE_GRAINED_CPUTIME is not set
-CONFIG_SCHED_FIXED_PRIO=y
-CONFIG_VIRT_OBJ_SPACE=y
-
-#
-# Debugging
-#
-CONFIG_INLINE=y
-# CONFIG_NDEBUG is not set
-# CONFIG_NO_FRAME_PTR is not set
-# CONFIG_STACK_DEPTH is not set
-# CONFIG_LIST_ALLOC_SANITY is not set
-CONFIG_SERIAL=y
-CONFIG_JDB=y
-# CONFIG_JDB_LOGGING is not set
-# CONFIG_JDB_DISASM is not set
-CONFIG_JDB_GZIP=y
-# CONFIG_JDB_ACCOUNTING is not set
-# CONFIG_WARN_NONE is not set
-CONFIG_WARN_WARNING=y
-# CONFIG_WARN_ANY is not set
-
-#
-# ARM debugging options
-#
-# CONFIG_VMEM_ALLOC_TEST is not set
-# CONFIG_DEBUG_KERNEL_PAGE_FAULTS is not set
-
-#
-# Compiling
-#
-CONFIG_CC="gcc"
-CONFIG_CXX="g++"
-CONFIG_HOST_CC="gcc"
-CONFIG_HOST_CXX="g++"
-# CONFIG_MAINTAINER_MODE is not set
-CONFIG_LABEL=""
-# CONFIG_EXPERIMENTAL is not set
-CONFIG_PERF_CNT=y
-CONFIG_BIT32=y
-CONFIG_WARN_LEVEL=1
-CONFIG_XARCH="arm"
-CONFIG_ABI="vf"

repos/base-foc/config/arndale.user

@@ -1,84 +0,0 @@
-#
-# Automatically generated file; DO NOT EDIT.
-# L4Re Configuration
-#
-CONFIG_ARCH_ENABLE_STACK_PROTECTOR=y
-# CONFIG_BUILD_ARCH_amd64 is not set
-CONFIG_BUILD_ARCH_arm=y
-# CONFIG_BUILD_ARCH_arm64 is not set
-# CONFIG_BUILD_ARCH_mips is not set
-# CONFIG_BUILD_ARCH_ppc32 is not set
-# CONFIG_BUILD_ARCH_sparc is not set
-# CONFIG_BUILD_ARCH_x86 is not set
-CONFIG_BUILD_ARCH="arm"
-CONFIG_BUILD_ABI_l4f=y
-CONFIG_BUILD_ABI="l4f"
-# CONFIG_CPU_ARM_ARMV4 is not set
-# CONFIG_CPU_ARM_ARMV4T is not set
-# CONFIG_CPU_ARM_ARMV5 is not set
-# CONFIG_CPU_ARM_ARMV5T is not set
-# CONFIG_CPU_ARM_ARMV5TE is not set
-# CONFIG_CPU_ARM_ARMV6 is not set
-# CONFIG_CPU_ARM_ARMV6T2 is not set
-# CONFIG_CPU_ARM_ARMV6ZK is not set
-CONFIG_CPU_ARM_ARMV7A=y
-CONFIG_CPU="armv7a"
-CONFIG_CPU_ARMV6KPLUS=y
-CONFIG_CPU_ARMV6PLUS=y
-# CONFIG_PLATFORM_TYPE_exynos4 is not set
-# CONFIG_PLATFORM_TYPE_imx35 is not set
-# CONFIG_PLATFORM_TYPE_zedboard is not set
-# CONFIG_PLATFORM_TYPE_beagleboard is not set
-# CONFIG_PLATFORM_TYPE_rv_pbx is not set
-CONFIG_PLATFORM_TYPE_exynos5=y
-# CONFIG_PLATFORM_TYPE_kirkwood is not set
-# CONFIG_PLATFORM_TYPE_ls1012afrdm is not set
-# CONFIG_PLATFORM_TYPE_pandaboard is not set
-# CONFIG_PLATFORM_TYPE_arm_virt is not set
-# CONFIG_PLATFORM_TYPE_tegra2 is not set
-# CONFIG_PLATFORM_TYPE_rv is not set
-# CONFIG_PLATFORM_TYPE_rv_vexpress_a15 is not set
-# CONFIG_PLATFORM_TYPE_cubieboard2 is not set
-# CONFIG_PLATFORM_TYPE_omap3_am33xx is not set
-# CONFIG_PLATFORM_TYPE_parallella is not set
-# CONFIG_PLATFORM_TYPE_rpi_b is not set
-# CONFIG_PLATFORM_TYPE_imx21 is not set
-# CONFIG_PLATFORM_TYPE_rcar3 is not set
-# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
-# CONFIG_PLATFORM_TYPE_tegra3 is not set
-# CONFIG_PLATFORM_TYPE_imx7 is not set
-# CONFIG_PLATFORM_TYPE_imx28 is not set
-# CONFIG_PLATFORM_TYPE_omap3evm is not set
-# CONFIG_PLATFORM_TYPE_zynqmp is not set
-# CONFIG_PLATFORM_TYPE_imx6 is not set
-# CONFIG_PLATFORM_TYPE_imx6ul is not set
-# CONFIG_PLATFORM_TYPE_armada38x is not set
-# CONFIG_PLATFORM_TYPE_omap5 is not set
-# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
-# CONFIG_PLATFORM_TYPE_imx51 is not set
-# CONFIG_PLATFORM_TYPE_rpi_a is not set
-# CONFIG_PLATFORM_TYPE_integrator is not set
-# CONFIG_PLATFORM_TYPE_custom is not set
-CONFIG_PLATFORM_TYPE="exynos5"
-CONFIG_DROPS_STDDIR="/path/to/l4re"
-CONFIG_DROPS_INSTDIR="/path/to/l4re"
-CONFIG_BID_COLORED_PHASES=y
-
-#
-# Building
-#
-CONFIG_YACC="yacc"
-CONFIG_LEX="flex"
-CONFIG_CTAGS="ctags"
-CONFIG_ETAGS="etags"
-CONFIG_HAVE_LDSO=y
-CONFIG_INT_CPP_NAME_SWITCH=y
-CONFIG_INT_LD_NAME_SWITCH=y
-# CONFIG_BID_STRIP_PROGS is not set
-# CONFIG_BID_GCC_OMIT_FP is not set
-CONFIG_BID_GCC_ENABLE_STACK_PROTECTOR=y
-# CONFIG_BID_GCC_STACK_PROTECTOR_ALL is not set
-CONFIG_BID_GCC_STACK_PROTECTOR=y
-# CONFIG_BID_BUILD_DOC is not set
-# CONFIG_RELEASE_MODE is not set
-CONFIG_MAKECONFS_ADD=""

repos/base-foc/config/odroid_x2.kernel

@@ -1,121 +0,0 @@
-#
-# Automatically generated file; DO NOT EDIT.
-# Fiasco configuration
-#
-CONFIG_HAS_FPU_OPTION=y
-CONFIG_HAS_LAZY_FPU=y
-CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
-CONFIG_HAS_SERIAL_OPTION=y
-CONFIG_HAS_JDB_DISASM_OPTION=y
-CONFIG_HAS_JDB_GZIP_OPTION=y
-CONFIG_HAS_MP_OPTION=y
-
-#
-# Target configuration
-#
-# CONFIG_IA32 is not set
-# CONFIG_AMD64 is not set
-CONFIG_ARM=y
-# CONFIG_MIPS is not set
-# CONFIG_PF_INTEGRATOR is not set
-# CONFIG_PF_REALVIEW is not set
-# CONFIG_PF_SUNXI is not set
-# CONFIG_PF_BCM283X is not set
-# CONFIG_PF_SA1100 is not set
-# CONFIG_PF_XSCALE is not set
-# CONFIG_PF_ARMADA38X is not set
-# CONFIG_PF_KIRKWOOD is not set
-# CONFIG_PF_TEGRA is not set
-# CONFIG_PF_LAYERSCAPE is not set
-# CONFIG_PF_IMX is not set
-# CONFIG_PF_ARM_VIRT is not set
-# CONFIG_PF_RCAR3 is not set
-CONFIG_PF_EXYNOS=y
-# CONFIG_PF_S3C2410 is not set
-# CONFIG_PF_OMAP is not set
-# CONFIG_PF_ZYNQ is not set
-# CONFIG_PF_ZYNQMP is not set
-CONFIG_BSP_NAME="exynos"
-CONFIG_CAN_ARM_CPU_CORTEX_A9=y
-CONFIG_CAN_ARM_CACHE_L2CXX0=y
-CONFIG_ARM_V7=y
-CONFIG_ARM_V6PLUS=y
-CONFIG_ARM_V7PLUS=y
-CONFIG_PF_EXYNOS4=y
-CONFIG_PF_EXYNOS_PKG_IDS=""
-# CONFIG_PF_EXYNOS4_4210 is not set
-CONFIG_PF_EXYNOS4_4412=y
-# CONFIG_PF_EXYNOS5_5250 is not set
-# CONFIG_PF_EXYNOS5_5410 is not set
-CONFIG_PF_EXYNOS_UART_NATIVE=y
-CONFIG_PF_EXYNOS_UART_NR=1
-CONFIG_PF_EXYNOS_TIMER_MCT=y
-# CONFIG_PF_EXYNOS_TIMER_MP is not set
-# CONFIG_PF_EXYNOS_TIMER_PWM is not set
-# CONFIG_PF_EXYNOS_EXTGIC is not set
-CONFIG_ABI_VF=y
-CONFIG_ARM_CORTEX_A9=y
-CONFIG_FPU=y
-CONFIG_LAZY_FPU=y
-CONFIG_HAVE_ARM_SECMONIF_NONE=y
-CONFIG_HAVE_ARM_SECMONIF_MC=y
-# CONFIG_ARM_ALIGNMENT_CHECK is not set
-# CONFIG_ARM_EM_STD is not set
-CONFIG_ARM_EM_NS=y
-# CONFIG_ARM_EM_TZ is not set
-# CONFIG_ARM_SECMONIF_NONE is not set
-CONFIG_ARM_SECMONIF_MC=y
-# CONFIG_ARM_SMC_USER is not set
-CONFIG_ARM_CACHE_L2CXX0=y
-# CONFIG_ARM_ENABLE_SWP is not set
-# CONFIG_ARM_CPU_ERRATA is not set
-
-#
-# Kernel options
-#
-CONFIG_MP=y
-CONFIG_MP_MAX_CPUS=4
-CONFIG_CONTEXT_4K=y
-# CONFIG_FINE_GRAINED_CPUTIME is not set
-CONFIG_SCHED_FIXED_PRIO=y
-CONFIG_VIRT_OBJ_SPACE=y
-
-#
-# Debugging
-#
-CONFIG_INLINE=y
-# CONFIG_NDEBUG is not set
-CONFIG_NO_FRAME_PTR=y
-# CONFIG_STACK_DEPTH is not set
-# CONFIG_LIST_ALLOC_SANITY is not set
-CONFIG_SERIAL=y
-CONFIG_JDB=y
-# CONFIG_JDB_LOGGING is not set
-# CONFIG_JDB_DISASM is not set
-CONFIG_JDB_GZIP=y
-# CONFIG_JDB_ACCOUNTING is not set
-# CONFIG_WARN_NONE is not set
-CONFIG_WARN_WARNING=y
-# CONFIG_WARN_ANY is not set
-
-#
-# ARM debugging options
-#
-# CONFIG_VMEM_ALLOC_TEST is not set
-# CONFIG_DEBUG_KERNEL_PAGE_FAULTS is not set
-
-#
-# Compiling
-#
-CONFIG_CC="gcc"
-CONFIG_CXX="g++"
-CONFIG_HOST_CC="gcc"
-CONFIG_HOST_CXX="g++"
-# CONFIG_MAINTAINER_MODE is not set
-CONFIG_LABEL=""
-# CONFIG_EXPERIMENTAL is not set
-CONFIG_PERF_CNT=y
-CONFIG_BIT32=y
-CONFIG_WARN_LEVEL=1
-CONFIG_XARCH="arm"
-CONFIG_ABI="vf"

repos/base-foc/config/odroid_x2.user

@@ -1,84 +0,0 @@
-#
-# Automatically generated file; DO NOT EDIT.
-# L4Re Configuration
-#
-CONFIG_ARCH_ENABLE_STACK_PROTECTOR=y
-# CONFIG_BUILD_ARCH_amd64 is not set
-CONFIG_BUILD_ARCH_arm=y
-# CONFIG_BUILD_ARCH_arm64 is not set
-# CONFIG_BUILD_ARCH_mips is not set
-# CONFIG_BUILD_ARCH_ppc32 is not set
-# CONFIG_BUILD_ARCH_sparc is not set
-# CONFIG_BUILD_ARCH_x86 is not set
-CONFIG_BUILD_ARCH="arm"
-CONFIG_BUILD_ABI_l4f=y
-CONFIG_BUILD_ABI="l4f"
-# CONFIG_CPU_ARM_ARMV4 is not set
-# CONFIG_CPU_ARM_ARMV4T is not set
-# CONFIG_CPU_ARM_ARMV5 is not set
-# CONFIG_CPU_ARM_ARMV5T is not set
-# CONFIG_CPU_ARM_ARMV5TE is not set
-# CONFIG_CPU_ARM_ARMV6 is not set
-# CONFIG_CPU_ARM_ARMV6T2 is not set
-# CONFIG_CPU_ARM_ARMV6ZK is not set
-CONFIG_CPU_ARM_ARMV7A=y
-CONFIG_CPU="armv7a"
-CONFIG_CPU_ARMV6KPLUS=y
-CONFIG_CPU_ARMV6PLUS=y
-CONFIG_PLATFORM_TYPE_exynos4=y
-# CONFIG_PLATFORM_TYPE_imx35 is not set
-# CONFIG_PLATFORM_TYPE_zedboard is not set
-# CONFIG_PLATFORM_TYPE_beagleboard is not set
-# CONFIG_PLATFORM_TYPE_rv_pbx is not set
-# CONFIG_PLATFORM_TYPE_exynos5 is not set
-# CONFIG_PLATFORM_TYPE_kirkwood is not set
-# CONFIG_PLATFORM_TYPE_ls1012afrdm is not set
-# CONFIG_PLATFORM_TYPE_pandaboard is not set
-# CONFIG_PLATFORM_TYPE_arm_virt is not set
-# CONFIG_PLATFORM_TYPE_tegra2 is not set
-# CONFIG_PLATFORM_TYPE_rv is not set
-# CONFIG_PLATFORM_TYPE_rv_vexpress_a15 is not set
-# CONFIG_PLATFORM_TYPE_cubieboard2 is not set
-# CONFIG_PLATFORM_TYPE_omap3_am33xx is not set
-# CONFIG_PLATFORM_TYPE_parallella is not set
-# CONFIG_PLATFORM_TYPE_rpi_b is not set
-# CONFIG_PLATFORM_TYPE_imx21 is not set
-# CONFIG_PLATFORM_TYPE_rcar3 is not set
-# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
-# CONFIG_PLATFORM_TYPE_tegra3 is not set
-# CONFIG_PLATFORM_TYPE_imx7 is not set
-# CONFIG_PLATFORM_TYPE_imx28 is not set
-# CONFIG_PLATFORM_TYPE_omap3evm is not set
-# CONFIG_PLATFORM_TYPE_zynqmp is not set
-# CONFIG_PLATFORM_TYPE_imx6 is not set
-# CONFIG_PLATFORM_TYPE_imx6ul is not set
-# CONFIG_PLATFORM_TYPE_armada38x is not set
-# CONFIG_PLATFORM_TYPE_omap5 is not set
-# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
-# CONFIG_PLATFORM_TYPE_imx51 is not set
-# CONFIG_PLATFORM_TYPE_rpi_a is not set
-# CONFIG_PLATFORM_TYPE_integrator is not set
-# CONFIG_PLATFORM_TYPE_custom is not set
-CONFIG_PLATFORM_TYPE="exynos4"
-CONFIG_DROPS_STDDIR="/path/to/l4re"
-CONFIG_DROPS_INSTDIR="/path/to/l4re"
-CONFIG_BID_COLORED_PHASES=y
-
-#
-# Building
-#
-CONFIG_YACC="yacc"
-CONFIG_LEX="flex"
-CONFIG_CTAGS="ctags"
-CONFIG_ETAGS="etags"
-CONFIG_HAVE_LDSO=y
-CONFIG_INT_CPP_NAME_SWITCH=y
-CONFIG_INT_LD_NAME_SWITCH=y
-# CONFIG_BID_STRIP_PROGS is not set
-# CONFIG_BID_GCC_OMIT_FP is not set
-CONFIG_BID_GCC_ENABLE_STACK_PROTECTOR=y
-# CONFIG_BID_GCC_STACK_PROTECTOR_ALL is not set
-CONFIG_BID_GCC_STACK_PROTECTOR=y
-# CONFIG_BID_BUILD_DOC is not set
-# CONFIG_RELEASE_MODE is not set
-CONFIG_MAKECONFS_ADD=""

repos/base-foc/config/panda.kernel

@@ -1,110 +0,0 @@
-#
-# Automatically generated file; DO NOT EDIT.
-# Fiasco configuration
-#
-CONFIG_HAS_FPU_OPTION=y
-CONFIG_HAS_LAZY_FPU=y
-CONFIG_HAS_VIRT_OBJ_SPACE_OPTION=y
-CONFIG_HAS_SERIAL_OPTION=y
-CONFIG_HAS_JDB_DISASM_OPTION=y
-CONFIG_HAS_JDB_GZIP_OPTION=y
-CONFIG_HAS_MP_OPTION=y
-
-#
-# Target configuration
-#
-# CONFIG_IA32 is not set
-# CONFIG_AMD64 is not set
-CONFIG_ARM=y
-# CONFIG_MIPS is not set
-# CONFIG_PF_INTEGRATOR is not set
-# CONFIG_PF_REALVIEW is not set
-# CONFIG_PF_SUNXI is not set
-# CONFIG_PF_BCM283X is not set
-# CONFIG_PF_SA1100 is not set
-# CONFIG_PF_XSCALE is not set
-# CONFIG_PF_ARMADA38X is not set
-# CONFIG_PF_KIRKWOOD is not set
-# CONFIG_PF_TEGRA is not set
-# CONFIG_PF_LAYERSCAPE is not set
-# CONFIG_PF_IMX is not set
-# CONFIG_PF_ARM_VIRT is not set
-# CONFIG_PF_RCAR3 is not set
-# CONFIG_PF_EXYNOS is not set
-# CONFIG_PF_S3C2410 is not set
-CONFIG_PF_OMAP=y
-# CONFIG_PF_ZYNQ is not set
-# CONFIG_PF_ZYNQMP is not set
-CONFIG_BSP_NAME="omap"
-CONFIG_CAN_ARM_CPU_CORTEX_A9=y
-CONFIG_CAN_ARM_CACHE_L2CXX0=y
-CONFIG_ARM_V7=y
-CONFIG_ARM_V6PLUS=y
-CONFIG_ARM_V7PLUS=y
-# CONFIG_PF_OMAP3_OMAP35XEVM is not set
-# CONFIG_PF_OMAP3_BEAGLEBOARD is not set
-# CONFIG_PF_OMAP3_AM33XX is not set
-CONFIG_PF_OMAP4_PANDABOARD=y
-# CONFIG_PF_OMAP5_5432EVM is not set
-CONFIG_ABI_VF=y
-CONFIG_ARM_CORTEX_A9=y
-CONFIG_FPU=y
-CONFIG_LAZY_FPU=y
-# CONFIG_ARM_ALIGNMENT_CHECK is not set
-CONFIG_ARM_EM_STD=y
-# CONFIG_ARM_EM_NS is not set
-# CONFIG_ARM_EM_TZ is not set
-# CONFIG_ARM_SMC_USER is not set
-CONFIG_ARM_CACHE_L2CXX0=y
-# CONFIG_ARM_ENABLE_SWP is not set
-# CONFIG_ARM_CPU_ERRATA is not set
-
-#
-# Kernel options
-#
-CONFIG_MP=y
-CONFIG_MP_MAX_CPUS=4
-CONFIG_CONTEXT_4K=y
-# CONFIG_FINE_GRAINED_CPUTIME is not set
-CONFIG_SCHED_FIXED_PRIO=y
-CONFIG_VIRT_OBJ_SPACE=y
-
-#
-# Debugging
-#
-CONFIG_INLINE=y
-# CONFIG_NDEBUG is not set
-# CONFIG_NO_FRAME_PTR is not set
-# CONFIG_STACK_DEPTH is not set
-# CONFIG_LIST_ALLOC_SANITY is not set
-CONFIG_SERIAL=y
-CONFIG_JDB=y
-CONFIG_JDB_LOGGING=y
-# CONFIG_JDB_DISASM is not set
-CONFIG_JDB_GZIP=y
-# CONFIG_JDB_ACCOUNTING is not set
-# CONFIG_WARN_NONE is not set
-CONFIG_WARN_WARNING=y
-# CONFIG_WARN_ANY is not set
-
-#
-# ARM debugging options
-#
-# CONFIG_VMEM_ALLOC_TEST is not set
-# CONFIG_DEBUG_KERNEL_PAGE_FAULTS is not set
-
-#
-# Compiling
-#
-CONFIG_CC="gcc"
-CONFIG_CXX="g++"
-CONFIG_HOST_CC="gcc"
-CONFIG_HOST_CXX="g++"
-# CONFIG_MAINTAINER_MODE is not set
-CONFIG_LABEL=""
-# CONFIG_EXPERIMENTAL is not set
-CONFIG_PERF_CNT=y
-CONFIG_BIT32=y
-CONFIG_WARN_LEVEL=1
-CONFIG_XARCH="arm"
-CONFIG_ABI="vf"

repos/base-foc/config/panda.user

@@ -1,82 +0,0 @@
-#
-# Automatically generated file; DO NOT EDIT.
-# L4Re Configuration
-#
-CONFIG_ARCH_ENABLE_STACK_PROTECTOR=y
-# CONFIG_BUILD_ARCH_amd64 is not set
-CONFIG_BUILD_ARCH_arm=y
-# CONFIG_BUILD_ARCH_arm64 is not set
-# CONFIG_BUILD_ARCH_mips is not set
-# CONFIG_BUILD_ARCH_ppc32 is not set
-# CONFIG_BUILD_ARCH_sparc is not set
-# CONFIG_BUILD_ARCH_x86 is not set
-CONFIG_BUILD_ARCH="arm"
-CONFIG_BUILD_ABI_l4f=y
-CONFIG_BUILD_ABI="l4f"
-# CONFIG_CPU_ARM_ARMV4 is not set
-# CONFIG_CPU_ARM_ARMV4T is not set
-# CONFIG_CPU_ARM_ARMV5 is not set
-# CONFIG_CPU_ARM_ARMV5T is not set
-# CONFIG_CPU_ARM_ARMV5TE is not set
-# CONFIG_CPU_ARM_ARMV6 is not set
-# CONFIG_CPU_ARM_ARMV6T2 is not set
-# CONFIG_CPU_ARM_ARMV6ZK is not set
-CONFIG_CPU_ARM_ARMV7A=y
-CONFIG_CPU="armv7a"
-CONFIG_CPU_ARMV6KPLUS=y
-CONFIG_CPU_ARMV6PLUS=y
-# CONFIG_PLATFORM_TYPE_exynos4 is not set
-# CONFIG_PLATFORM_TYPE_imx35 is not set
-# CONFIG_PLATFORM_TYPE_zedboard is not set
-# CONFIG_PLATFORM_TYPE_beagleboard is not set
-# CONFIG_PLATFORM_TYPE_rv_pbx is not set
-# CONFIG_PLATFORM_TYPE_exynos5 is not set
-# CONFIG_PLATFORM_TYPE_kirkwood is not set
-# CONFIG_PLATFORM_TYPE_ls1012afrdm is not set
-CONFIG_PLATFORM_TYPE_pandaboard=y
-# CONFIG_PLATFORM_TYPE_arm_virt is not set
-# CONFIG_PLATFORM_TYPE_tegra2 is not set
-# CONFIG_PLATFORM_TYPE_rv is not set
-# CONFIG_PLATFORM_TYPE_rv_vexpress_a15 is not set
-# CONFIG_PLATFORM_TYPE_cubieboard2 is not set
-# CONFIG_PLATFORM_TYPE_omap3_am33xx is not set
-# CONFIG_PLATFORM_TYPE_parallella is not set
-# CONFIG_PLATFORM_TYPE_rpi_b is not set
-# CONFIG_PLATFORM_TYPE_imx21 is not set
-# CONFIG_PLATFORM_TYPE_rcar3 is not set
-# CONFIG_PLATFORM_TYPE_ls1021atwr is not set
-# CONFIG_PLATFORM_TYPE_tegra3 is not set
-# CONFIG_PLATFORM_TYPE_imx7 is not set
-# CONFIG_PLATFORM_TYPE_imx28 is not set
-# CONFIG_PLATFORM_TYPE_omap3evm is not set
-# CONFIG_PLATFORM_TYPE_zynqmp is not set
-# CONFIG_PLATFORM_TYPE_imx6 is not set
-# CONFIG_PLATFORM_TYPE_imx6ul is not set
-# CONFIG_PLATFORM_TYPE_armada38x is not set
-# CONFIG_PLATFORM_TYPE_omap5 is not set
-# CONFIG_PLATFORM_TYPE_rv_vexpress is not set
-# CONFIG_PLATFORM_TYPE_imx51 is not set
-# CONFIG_PLATFORM_TYPE_rpi_a is not set
-# CONFIG_PLATFORM_TYPE_integrator is not set
-# CONFIG_PLATFORM_TYPE_custom is not set
-CONFIG_PLATFORM_TYPE="pandaboard"
-CONFIG_DROPS_STDDIR="/path/to/l4re"
-CONFIG_DROPS_INSTDIR="/path/to/l4re"
-CONFIG_BID_COLORED_PHASES=y
-
-#
-# Building
-#
-CONFIG_YACC="yacc"
-CONFIG_LEX="flex"
-CONFIG_CTAGS="ctags"
-CONFIG_ETAGS="etags"
-CONFIG_HAVE_LDSO=y
-CONFIG_INT_CPP_NAME_SWITCH=y
-CONFIG_INT_LD_NAME_SWITCH=y
-# CONFIG_BID_STRIP_PROGS is not set
-# CONFIG_BID_GCC_OMIT_FP is not set
-# CONFIG_BID_GCC_ENABLE_STACK_PROTECTOR is not set
-# CONFIG_BID_BUILD_DOC is not set
-# CONFIG_RELEASE_MODE is not set
-CONFIG_MAKECONFS_ADD=""

repos/base-foc/doc/foc.txt

@@ -1,78 +0,0 @@
-
-                     ===================================
-                     Genode on the Fiasco.OC microkernel
-                     ===================================
-
-
-                            Stefan Kalkowski
-
-
-Fiasco.OC is a microkernel originally developed by the OS group of the
-TU-Dresden. Nowadays, it is primarily maintained and developed by
-the company Kernkonzept. It's an object-oriented capability-based system
-for x86, ARM, PowerPC and MIPS platforms.
-
-This document provides brief instructions about downloading, building and
-booting the Fiasco.OC version of Genode.
-
-
-Prerequisites
-#############
-
-You need certain tools to use the Fiasco.OC build system. On Debian/Ubuntu
-systems you have to install the following packages:
-
-! apt-get install make gawk g++ binutils pkg-config g++-multilib subversion
-
-Moreover, you need to download and install the tool-chain used by Genode. Have
-a look at this page:
-
-:[http://genode.org/download/tool-chain]:
-  Genode tool-chain
-
-
-Building the Fiasco.OC version of Genode
-########################################
-
-The current version of Genode is available at the public Github repository:
-
-:http://github.com/genodelabs/genode:
-  Github repository of Genode
-
-After you've fetched the Genode source tree from the git repository, or
-downloaded the latest release tar archive, you need the Fiasco.OC source code,
-its kernel-bindings, additional bootstrap tools etc. To simplify that step,
-you can use the 'prepare_port' tool:
-
-! ./tool/ports/prepare_port foc
-
-This will install all necessary third-party source code in the 'contrib' folder.
-
-Now, go to a directory where you want the Genode/Fiasco.OC build directory to
-remain. Use the helper script in the 'tool' directory of the Genode
-source tree to create the initial build environment. You need to state the
-build directory you want to create, and the hardware architecture to run
-Fiasco.OC/Genode on. Choose 'x86_32', 'x86_64', or one of the available ARM
-boards.
-
-! <genode-dir>/tool/create_builddir x86_64
-
-Now, go to the newly created build directory and type make:
-
-! cd build/x86_64
-! make KERNEL=foc
-
-This will build the Fiasco.OC kernel, its bootstrap code, and every Genode component,
-that runs on top of Fiasco.OC.
-
-If you just want to give Genode/Fiasco.OC a try, you can call e.g.: the demo run-script
-instead of building everything:
-
-! make run/demo KERNEL=foc
-
-
-Further Information
-###################
-
-:[https://l4re.org/fiasco/]:
-  Official website for the Fiasco.OC microkernel.

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

@@ -13,3 +13,4 @@ SRC_CC += rpc_dispatch_loop.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

repos/base-foc/lib/mk/spec/arndale/kernel-foc.mk

@@ -1,3 +0,0 @@
-KERNEL_CONFIG := $(REP_DIR)/config/arndale.kernel
-
-include $(REP_DIR)/lib/mk/kernel-foc.inc

repos/base-foc/lib/mk/spec/arndale/syscall-foc.mk

@@ -1,5 +0,0 @@
-L4_CONFIG := $(call select_from_repositories,config/arndale.user)
-
-L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/arndale-build/bin/arm_armv7a
-
-include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

repos/base-foc/lib/mk/spec/odroid_x2/kernel-foc.mk

@@ -1,3 +0,0 @@
-KERNEL_CONFIG := $(REP_DIR)/config/odroid_x2.kernel
-
-include $(REP_DIR)/lib/mk/kernel-foc.inc

repos/base-foc/lib/mk/spec/odroid_x2/syscall-foc.mk

@@ -1,5 +0,0 @@
-L4_CONFIG := $(call select_from_repositories,config/odroid_x2.user)
-
-L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/odroid_x2-build/bin/arm_armv7a
-
-include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

repos/base-foc/lib/mk/spec/panda/kernel-foc.mk

@@ -1,3 +0,0 @@
-KERNEL_CONFIG := $(REP_DIR)/config/panda.kernel
-
-include $(REP_DIR)/lib/mk/kernel-foc.inc

repos/base-foc/lib/mk/spec/panda/syscall-foc.mk

@@ -1,5 +0,0 @@
-L4_CONFIG := $(call select_from_repositories,config/panda.user)
-
-L4_BIN_DIR := $(LIB_CACHE_DIR)/syscall-foc/panda-build/bin/arm_armv7a
-
-include $(REP_DIR)/lib/mk/spec/arm/syscall-foc.inc

repos/base-foc/patches/0006-FOC-adjust-panda-timer-to-version-A6.patch

@@ -1,34 +0,0 @@
-From 8ce1c02d02fa8a9e50124e3237c2e01ae73c248c Mon Sep 17 00:00:00 2001
-From: Sebastian Sumpf <sebastian.sumpf@genode-labs.com>
-Date: Wed, 8 Mar 2017 16:58:27 +0100
-Subject: [PATCH 06/15] FOC: adjust panda timer to version A6
-
-A6 runs at 800 not 700 MHz (as the ES2 does) when bootstrapped by U-boot
-
-(thanks to mstein)
----
- .../fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp   | 10 +++++++++-
- 1 file changed, 9 insertions(+), 1 deletion(-)
-
-diff --git a/kernel/fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp b/kernel/fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp
-index 72ef9b90..c0aef990 100644
---- a/kernel/fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp
-+++ b/kernel/fiasco/src/kern/arm/bsp/omap/timer-arm-mptimer-omap4.cpp
-@@ -4,5 +4,13 @@ INTERFACE [arm && mptimer && pf_omap4_pandaboard]:
- EXTENSION class Timer
- {
- private:
--  static Mword interval() { return 499999; }
-+  static Mword interval()
-+  {
-+    /*
-+     * This is only valid for Panda A6, as we run it at our offices. For A6
-+     * U-Boot will clock the board at 800 MHz leading to a 400 MHz private timer
-+     * tick.
-+     */
-+    return 399999;
-+  }
- };
--- 
-2.11.0
-

repos/base-foc/ports/foc.hash

@@ -1 +1 @@
-91ca3363690c5b9c992a110375242f5d426a6848
+ce2d3e9f54b383ef2368e4cd285b0b48b0424f63

repos/base-foc/ports/foc.port

@@ -28,7 +28,6 @@ PATCH_OPT(patches/0001-L4RE-Remove-moe-from-switch_ram_base-target.patch)
 PATCH_OPT(patches/0002-FOC-change-l4_task_cap_equal-semantic.patch)               := -p3 -d${DIR(foc)}
 PATCH_OPT(patches/0003-Sigma0-raise-sigma0-s-priority-to-maximum.patch)           := -p4 -d${DIR(l4re-core)}
 PATCH_OPT(patches/0005-FOC-Increase-name-buffer-of-JDB-to-32K.patch)              := -p3 -d${DIR(foc)}
-PATCH_OPT(patches/0006-FOC-adjust-panda-timer-to-version-A6.patch)                := -p3 -d${DIR(foc)}
 PATCH_OPT(patches/0007-L4RE-fix-x86-syscall-bindings-to-use-in-C-namespace.patch) := -p4 -d${DIR(l4re-core)}
 PATCH_OPT(patches/0009-Bootstrap-read-out-comport-on-x86-from-BDA-area.patch)     := -p4 -d${DIR(bootstrap)}
 PATCH_OPT(patches/0010-L4RE-get-rid-of-__builtin_strlen-usage.patch)              := -p4 -d${DIR(l4re-core)}

repos/base-foc/recipes/src/base-foc-arndale/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/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/content.mk

@@ -1,3 +0,0 @@
-BOARD := arndale
-
-include $(GENODE_DIR)/repos/base-foc/recipes/src/base-foc_content.inc

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

@@ -1 +0,0 @@
-2019-07-08 f3bfd189708c82317b021ffdc53ba80128037465

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

@@ -1 +1 @@
-2019-07-08 87f41f86afb0c19e5682e2e2d41ed182f9334ef1
+2020-05-26 aaa0173203e45653f66c3d618ebb4f3f8c8ab824

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

@@ -1 +1 @@
-2019-07-08 d370ecc4cb2ce3f370cfaefecbf97a1c05ef3e69
+2020-05-26 4765046a8124b5ccb91e5d5d99c25dbd77b4beee

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

@@ -1 +1 @@
-2019-07-08 075559ecf0b1206c45de3fc7ccd9b6198bd41d41
+2020-05-26 a7b1bc8a7f5c49c55b78b4553c35e8c6f326a505

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

@@ -1 +1 @@
-2019-07-08 536625983e4733b833706e59c35591fe5d06020c
+2020-05-26 2e409e97f835d14938ed24e134251d20c1b1349a

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

@@ -1 +1 @@
-2019-07-08 5f648e24bfed0e532ad659cc87d8cf60a11efe05
+2020-05-26 0b9ad6d521217d2a0eedfc81d9313ec8eeed7d4d

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/cap_id_alloc.h

@@ -17,7 +17,7 @@
 /* Genode includes */
 #include <base/allocator_avl.h>
 #include <base/exception.h>
-#include <base/lock.h>
+#include <base/mutex.h>
 #include <synced_range_allocator.h>
 
 namespace Genode {
@@ -35,7 +35,7 @@ namespace Genode {
 
 			Synced_range_allocator<Allocator_avl> _id_alloc;
 
-			Lock _lock { };
+			Mutex _mutex { };
 
 		public:
 

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

@@ -15,7 +15,6 @@
 #define _CORE__VM_SESSION_COMPONENT_H_
 
 /* Genode includes */
-#include <base/allocator_guard.h>
 #include <base/rpc_server.h>
 #include <base/heap.h>
 #include <vm_session/vm_session.h>
@@ -108,7 +107,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/rpc_cap_factory.cc

@@ -192,7 +192,7 @@ Cap_id_allocator::Cap_id_allocator(Allocator &alloc)
 
 unsigned long Cap_id_allocator::alloc()
 {
-	Lock::Guard lock_guard(_lock);
+	Mutex::Guard lock_guard(_mutex);
 
 	void *id = nullptr;
 	if (_id_alloc.alloc(CAP_ID_OFFSET, &id))
@@ -203,7 +203,7 @@ unsigned long Cap_id_allocator::alloc()
 
 void Cap_id_allocator::free(unsigned long id)
 {
-	Lock::Guard lock_guard(_lock);
+	Mutex::Guard lock_guard(_mutex);
 
 	if (id < CAP_ID_RANGE)
 		_id_alloc.free((void*)(id & CAP_ID_MASK), CAP_ID_OFFSET);

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;

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;
@@ -228,14 +227,14 @@ struct Vcpu : Genode::Thread
 
 		State _state_request { NONE };
 		State _state_current { NONE };
-		Lock  _remote_lock   { Lock::UNLOCKED };
+		Mutex _remote_mutex  { };
 
 		void entry() override
 		{
 			_wake_up.down();
 
 			{
-				Lock::Guard guard(_remote_lock);
+				Mutex::Guard guard(_remote_mutex);
 
 				/* leave scope for Thread::join() - vCPU setup failed */
 				if (_state_request == TERMINATE)
@@ -320,7 +319,7 @@ struct Vcpu : Genode::Thread
 			while (true) {
 				/* read in requested state from remote threads */
 				{
-					Lock::Guard guard(_remote_lock);
+					Mutex::Guard guard(_remote_mutex);
 					_state_current = _state_request;
 					_state_request = NONE;
 				}
@@ -332,7 +331,7 @@ struct Vcpu : Genode::Thread
 
 				if (_state_current != RUN && _state_current != PAUSE) {
 					Genode::error("unknown vcpu state ", (int)_state_current);
-					while (true) { _remote_lock.lock(); }
+					while (true) { _remote_mutex.acquire(); }
 				}
 
 				/* transfer vCPU state to Fiasco.OC */
@@ -356,7 +355,7 @@ struct Vcpu : Genode::Thread
 						reason = 0xfc; 
 
 					{
-						Lock::Guard guard(_remote_lock);
+						Mutex::Guard guard(_remote_mutex);
 						_state_request = NONE;
 						_state_current = PAUSE;
 
@@ -381,7 +380,7 @@ struct Vcpu : Genode::Thread
 					reason = Fiasco::l4_vm_vmx_read_32(vmcs, Vmcs::EXI_REASON);
 
 					{
-						Lock::Guard guard(_remote_lock);
+						Mutex::Guard guard(_remote_mutex);
 						_state_request = NONE;
 						_state_current = PAUSE;
 
@@ -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)
 		{
@@ -1208,7 +1207,7 @@ struct Vcpu : Genode::Thread
 
 		void resume()
 		{
-			Lock::Guard guard(_remote_lock);
+			Mutex::Guard guard(_remote_mutex);
 
 			if (_state_request == RUN || _state_request == PAUSE)
 				return;
@@ -1221,7 +1220,7 @@ struct Vcpu : Genode::Thread
 
 		void pause()
 		{
-			Lock::Guard guard(_remote_lock);
+			Mutex::Guard guard(_remote_mutex);
 
 			if (_state_request == PAUSE)
 				return;
@@ -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/doc/panda.txt

@@ -1,97 +0,0 @@
-
-            ===============================================
-            Getting started with 'base-hw' on PandaBoard A2
-            ===============================================
-
-
-                            Martin Stein
-
-Abstract
-########
-
-This is a short tutorial that depicts a handy way to get a Genode ELF-image,
-build with 'base-hw', started on the PandaBoard A2. For informations
-about how to build Genode images with 'base-hw', have a look at
-'<GENODE_DIR>/repos/base-hw/doc/hw.txt'. This tutorial is dedicated to common
-Linux systems, but all examples originate from a Ubuntu 11.10.
-
-
-Tutorial
-########
-
-Connect the PandaBoard to your local Ethernet through its RJ45 connector.
-Additionally connect the PandaBoard to your machine through its COM port.
-Ensure that you have installed the genode tool chain that is available at:
-
-:[http://genode.org/download/tool-chain]:
-  Genode tool-chain
-
-Ensure that '<GENODE_TOOL_CHAIN_DIR>/bin/' is in your 'PATH' variable.
-Get the Linaro U-Boot repository and compile U-Boot for PandaBoard:
-
-! git clone git://git.linaro.org/boot/u-boot-linaro-stable.git
-! cd <UBOOT_DIR>
-! make CROSS_COMPILE=genode-arm- omap4_panda_config
-! make CROSS_COMPILE=genode-arm-
-
-During the compilation i had some errors. The first was in assembly code,
-it seemed to originate from a slip with the typo and was easy to fix.
-The second kind of errors occured because the GCC version had no support for
-direct array initialization, thus i avoided them by simply initialize
-the array elements separately.
-
-Now install the following packages to communicate with the PandaBoard:
-
-! apt-get install tftp-hpa minicom
-
-Open '/etc/default/tftpd-hpa' with a text editor and ensure that it has
-the following content:
-
-! TFTP_USERNAME="tftp"
-! TFTP_DIRECTORY="/var/lib/tftpboot"
-! TFTP_ADDRESS="0.0.0.0:69"
-! TFTP_OPTIONS="-l"
-
-Tell TFTP wich image to provide:
-
-! cd /var/lib/tftpboot/
-! ln -s <GENODE_BOOT_ELF> image.elf
-
-Where '<GENODE_BOOT_ELF>' is the absolute path of the targeted ELF image.
-Start TFTP to enable the upload of the image:
-
-! service tftp-hpa restart
-
-Start Minicom in configuration mode:
-
-! minicom -s
-
-Go to 'Serial port setting' and ensure that the device is set to the
-TTY of the COM port you've conntected PandaBoard with. In my case it was
-'/dev/ttyS0'. Configure the other settings for a baud rate of '115200',
-8 bit char length, no parity and 1 stop bit. Quit Minicom and start
-it once more:
-
-! minicom
-
-Mount your SD-card and copy the U-Boot files to its boot partition:
-
-! cd <UBOOT_DIR>; cp MLO /media/boot/; cp u-boot.bin /media/boot/
-
-Unmount the SD card and insert it into the appropriate PandaBoard slot.
-Plug in the power connector or push the 'S1' button if the PandaBoard is
-already powered. Minicom should now show the following message below some
-bootloader info:
-
-! Hit any key to stop autoboot:
-
-We have to stop autoboot and type in this line to load and boot the genode
-image via ethernet:
-
-! usb start; dhcp; bootelf 0x82000000
-
-Now your Genode scenario should start and offer its debug output
-in Minicom. You can boot other images by redirecting the link
-'/var/lib/tftpboot/image.elf' accordingly, restarting your PandaBoard
-and instructing U-boot again as described above.
-

repos/base-hw/include/hw_native_pd/hw_native_pd.h

@@ -30,7 +30,7 @@ struct Genode::Hw_native_pd : Pd_session::Native_pd
 	 *********************/
 
 	GENODE_RPC_THROW(Rpc_upgrade_cap_slab, void, upgrade_cap_slab,
-	                 GENODE_TYPE_LIST(Out_of_ram));
+	                 GENODE_TYPE_LIST(Out_of_ram, Out_of_caps));
 	GENODE_RPC_INTERFACE(Rpc_upgrade_cap_slab);
 };
 

repos/base-hw/include/kernel/interface.h

@@ -36,13 +36,12 @@ namespace Kernel
 	constexpr Call_arg call_id_cancel_next_await_signal() { return 10; }
 	constexpr Call_arg call_id_ack_signal()               { return 11; }
 	constexpr Call_arg call_id_print_char()               { return 12; }
-	constexpr Call_arg call_id_update_data_region()       { return 13; }
-	constexpr Call_arg call_id_update_instr_region()      { return 14; }
-	constexpr Call_arg call_id_ack_cap()                  { return 15; }
-	constexpr Call_arg call_id_delete_cap()               { return 16; }
-	constexpr Call_arg call_id_timeout()                  { return 17; }
-	constexpr Call_arg call_id_timeout_max_us()           { return 18; }
-	constexpr Call_arg call_id_time()                     { return 19; }
+	constexpr Call_arg call_id_cache_coherent_region()    { return 13; }
+	constexpr Call_arg call_id_ack_cap()                  { return 14; }
+	constexpr Call_arg call_id_delete_cap()               { return 15; }
+	constexpr Call_arg call_id_timeout()                  { return 16; }
+	constexpr Call_arg call_id_timeout_max_us()           { return 17; }
+	constexpr Call_arg call_id_time()                     { return 18; }
 
 
 	/*****************************************************************
@@ -176,26 +175,16 @@ namespace Kernel
 	}
 
 	/**
-	 * Globally apply writes to a data region in the current domain
+	 * Enforce coherent view (I-/D-Caches) on memory region
 	 *
 	 * \param base  base of the region within the current domain
 	 * \param size  size of the region
 	 */
-	inline void update_data_region(addr_t const base, size_t const size)
+	inline void cache_coherent_region(addr_t const base, size_t const size)
 	{
-		call(call_id_update_data_region(), (Call_arg)base, (Call_arg)size);
+		call(call_id_cache_coherent_region(), (Call_arg)base, (Call_arg)size);
 	}
 
-	/**
-	 * Globally apply writes to an instruction region in the current domain
-	 *
-	 * \param base  base of the region within the current domain
-	 * \param size  size of the region
-	 */
-	inline void update_instr_region(addr_t const base, size_t const size)
-	{
-		call(call_id_update_instr_region(), (Call_arg)base, (Call_arg)size);
-	}
 
 	/**
 	 * Send request message and await receipt of corresponding reply message