Experiences in portable mobile application development

In the software world portability means power. The more operating environments you can support out of the same code tree means more potential users for your software. If done right, additional platforms can be supported with little extra maintenance cost. If done wrong, maintaining additional platforms will become a veritable nightmare. This paper describes experiences undergone when creating truly portable soft- ware. Our software is a real time rendered 3D map and messaging application, which runs on UNIX (Linux, Mac OS X, NetBSD), Windows 98/2000/XP, Windows CE and Symbian Series 60. It is Symbian which makes this mix of platforms interesting and challenging. However, with the knowledge of potential problems, we found that this set of platforms is totally manageable for a portable mobile 3D application.1st International Workshop on Advanced Software Engineering: Expanding the Frontiers of Software Technology - Session 4: Experiences in Software DevelopmentRed de Universidades con Carreras en Informática (RedUNCI

Experiences in portable mobile application development

In the software world portability means power. The more operating environments you can support out of the same code tree means more potential users for your software. If done right, additional platforms can be supported with little extra maintenance cost. If done wrong, maintaining additional platforms will become a veritable nightmare. This paper describes experiences undergone when creating truly portable soft- ware. Our software is a real time rendered 3D map and messaging application, which runs on UNIX (Linux, Mac OS X, NetBSD), Windows 98/2000/XP, Windows CE and Symbian Series 60. It is Symbian which makes this mix of platforms interesting and challenging. However, with the knowledge of potential problems, we found that this set of platforms is totally manageable for a portable mobile 3D application.1st International Workshop on Advanced Software Engineering: Expanding the Frontiers of Software Technology - Session 4: Experiences in Software DevelopmentRed de Universidades con Carreras en Informática (RedUNCI

LibrettOS: A Dynamically Adaptable Multiserver-Library OS

We present LibrettOS, an OS design that fuses two paradigms to simultaneously address issues of isolation, performance, compatibility, failure recoverability, and run-time upgrades. LibrettOS acts as a microkernel OS that runs servers in an isolated manner. LibrettOS can also act as a library OS when, for better performance, selected applications are granted exclusive access to virtual hardware resources such as storage and networking. Furthermore, applications can switch between the two OS modes with no interruption at run-time. LibrettOS has a uniquely distinguishing advantage in that, the two paradigms seamlessly coexist in the same OS, enabling users to simultaneously exploit their respective strengths (i.e., greater isolation, high performance). Systems code, such as device drivers, network stacks, and file systems remain identical in the two modes, enabling dynamic mode switching and reducing development and maintenance costs. To illustrate these design principles, we implemented a prototype of LibrettOS using rump kernels, allowing us to reuse existent, hardened NetBSD device drivers and a large ecosystem of POSIX/BSD-compatible applications. We use hardware (VM) virtualization to strongly isolate different rump kernel instances from each other. Because the original rumprun unikernel targeted a much simpler model for uniprocessor systems, we redesigned it to support multicore systems. Unlike kernel-bypass libraries such as DPDK, applications need not be modified to benefit from direct hardware access. LibrettOS also supports indirect access through a network server that we have developed. Applications remain uninterrupted even when network components fail or need to be upgraded. Finally, to efficiently use hardware resources, applications can dynamically switch between the indirect and direct modes based on their I/O load at run-time. [full abstract is in the paper]Comment: 16th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE '20), March 17, 2020, Lausanne, Switzerlan

Joustavat käyttöjärjestelmät: Jokaytimen ja Tynkäytimien suunnittelu ja toteutus

The monolithic kernel architecture is significant in the real world due to the large amount of working and proven code. However, the architecture is not without problems: testing and development is difficult, virtualizing kernel services can be done only by duplicating the entire kernel, and security is weak due to a single domain where all code has direct access to everything. Alternate kernel architectures such as the microkernel and exokernel have been proposed to rectify these problems with monolithic kernels. However, alternate system structures do not address the common desire of using a monolithic kernel when the abovementioned problems do not apply. We propose a flexible anykernel architecture which enables running kernel drivers in a variety of configurations, examples of which include microkernel-style servers and application libraries. A monolithic kernel is shown to be convertible into an anykernel with a reasonable amount of effort and without introducing performance-hindering indirection layers. The original monolithic mode of operation is preserved after the anykernel adjustments, and alternate modes of operation for drivers are available as a runtime choice. For non-monolithic modes of operation, the rump kernel is introduced as a lightweight container for drivers. A rump kernel runs on top of a hypervisor which offers high-level primitives such as thread scheduling and virtual memory. A production quality implementation for the NetBSD open source OS has been done. The anykernel architecture and rump kernels are evaluated both against four years of real-world experience from daily NetBSD development as well as against synthetic benchmarks.Monoliittisen ytimen käyttöjärjestelmät ovat merkittäviä, koska ne sisältävät suuren määrän olemassaolevia ja testattja ajureita. Monoliittinen arkkitehtuuri ei kuitenkaan ole ongelmaton: virtualisointi onnistuu vain virtualisoimalla ydin kokonaisuutena, ytimen testaus on vaikeaa ja tietoturva on heikkoa johtuen siitä, että ytimessä suoritettavalla ohjelmistolla on suora pääsy käyttöjärjestelmän kaikkiin osiin. Vaihtoehtoisia ydinarkkitehtuureita, kuten mikroydin ja eksoydin, on ehdotettu korjaamaan monoliittisen arkkitehtuurin ongelmia. Vaihtoehtoisissa malleissa on kuitenkin ongelmana se, etteivät ne tue yleistä halua käyttää monoliittista ydintä, kun yllämainitut ongelmat eivät ole relevantteja. Tässä työssä luodaan joustava jokaydin. Se mahdollistaa ajureiden suorittamisen monissa konfiguraatioissa, esimerkkejä joista ovat mikroydin-tyyliset palvelimet ja sovelluskirjastot. Monoliittisen ytimen muuntamisen jokaytimeksi näytetään onnistuvan säädyllisellä vaivalla ilman suorituskykyä heikentäviä abstraktioita. Mahdollisuus suorittaa ajureita monoliittisessä ytimessä säilyy ja muut suorituskonfiguraatiot tarjotaan ajonaikaisena valintana. Muita kuin monoliittisista suorituskonfiguraatiota varten määritellään tynkäydin, joka on ajoympäristö ajureille. Tynkäytimen suoritus tapahtuu hyperkaihtimen päällä. Hyperkaihdin tarjoaa tynkäytimelle korkean tason palveluita kuten säieskeduloinnin ja virtuaalimuistin. Toteutus on tehty tuotantotasoisena NetBSD-nimiselle avoimen lähdekoodin käyttöjärjestelmälle. Jokaydinarkkitehtuuri ja tynkäytimet arvioidaan sekä neljän vuoden reaalikokemuksen että synteettisten kokeiden perusteella

Sovellusvetoisten tarkistuspisteiden käyttö kuumavarmennetun korkean käytettävyyden saavuttamiseksi

For critical services, downtime is not an option. The downtime of a service can be addressed by replicating the units which provide the service. However, if the session state is important, it is not enough to simply replicate units: sharing the continuously updated internal state of the units must also be made possible. If execution can be continued on another unit after the point-of-failure without any significant loss of state, the unit is said to have a Hot Spare. Saving the state of a unit so that it can be restored at a later point in time and space is known as check pointing. For the check pointing approach to be a viable option in interactive services, it must not disrupt the normal program operation in any way noticeable to the user. The goal of this work is to present a check pointing facility which can be used in applications where check pointing should and cannot disrupt normal program operation. To accomplish this, the responsibility of taking a checkpoint is left up to the application. The implications are twofold: check pointing will be done at exactly the right time and for exactly the right set of data, but each application must be individually modified to support check pointing. A framework is provided for the application programmer so that it is possible to concentrate on the important issues when adding Hot Spare capabilities: what to checkpoint and when to checkpoint. Check pointing efficiency is further increased by introducing kernel functionality to support incremental checkpoints.Kriittisillä palveluilla ei ole varaa olla epäkunnossa. Palvelun saatavuutta voidaan parantaa monistamalla yksiköt, jotka tarjoavat palvelua. Jos istunnon sisäinen tila on tärkeä, ei pelkkä yksiköiden monistaminen riitä; istunnon sisäinen tila tulee myös kyetä siirtämään varayksiköihin. Jos suoritusta voidaan jatkaa varayksikössä ilman merkittävää sisäisen tilan häviötä, sanotaan yksikön olevan kuumavarmennettu. Yksikön tilan tallentamista mahdollista palautusta varten sanotaan tarkistuspisteen ottamiseksi. Jotta tarkistuspisteen ottaminen interaktiivisessa palvelussa olisi mahdollista, se ei saa häiritä normaalia suoritusta haitaksi asti. Tämän työn päämääränä on luoda tarkistuspisteiden ottamista varten kehys, jonka avulla tarkistuspisteiden ottaminen täyttää aiemmin määritellyn tehokkuuskriteerin. Ongelman ratkaisemiseksi tarkistuspisteiden ottaminen jätetään sovelluksen vastuulle. Tämän hyvänä puolena on se, että oman semanttisen käyttäytymisensä tuntevana sovellus voi ottaa tarkistuspisteen juuri oikealle datajoukolle juuri oikeaan aikaan. Huonona puolena on luonnollisesti se, että jokainen sovellus pitää yksitellen muokata tukemaan tarkistuspisteiden ottamista. Työssä laaditun ohjelmointikirjaston tarkoitus on päästää sovelluksen muokkaaja painimaan keskeisten kysymysten parissa: milloin tarkistuspiste otetaan ja mitä siihen sisältyy. Tarkistuspisteiden ottamista tehostetaan entisestään muokkaamalla käyttöjärjestelmän ydintä niin, että se tarjoaa tarkistuspisteiden ottamiseen sopivia rajapintoja