Towards an Operating System for the Campus Pengfei Yuan, Yao Guo, and Xiangqun Chen Key Laboratory of High-Confidence Software Technologies (Ministry of Education) School of Electronics Engineering and Computer Science, Peking University {yuanpf12, yaoguo, cherry}@sei.pku.edu.cn ABSTRACT data center or even the whole Internet as a computer, we can Almost every computing device runs an operating system, envision that many applications are \actually" running on which is responsible for managing different resources on the network of computers. Consequently, many researchers the device and providing higher-level programming abstrac- have proposed various operating systems for cloud or even tions. This paper proposes CampusOS, an operating system the Internet. For example, Tim O'Reilly proposed his vision which is responsible for managing networked resources on of an Internet Operating System [7]. At the same time, university campuses, including data of students, teachers, many other operating systems have been proposed for cloud courses, organizations, and even data generated from users' computing [10], networked home appliances [3], commercial computing devices. CampusOS provides flexible support for buildings [2], and even connected city blocks [4]. campus application development with SDKs consisting of In contrast, this paper focuses on the evolvement of campus-related APIs. CampusOS features and SDK APIs applications and services running on closely-connected com- can also be extended by developers easily. We discuss the munities such as a university campus, especially mobile design of CampusOS, as well as its challenges. applications targeting community members and activities. Developing applications for communities like university cam- puses requires a lot of trivial work. A developer would Categories and Subject Descriptors typically need to figure out how to retrieve and manage D.2.2 [Software Engineering]: Design Tools and Tech- users' personal information, schedules, social relations, etc. niques|software libraries; D.4 [Operating Systems]: Or- Large amount of time is spent on these lower-level details, ganization and Design instead of focusing on implementing and improving the key functionalities of the applications. For a closely-connected community such as a university General Terms or a similar organization, different applications have much Design, Management in common at the lower level. Providing higher-level APIs for commonly used lower-level features can improve the Keywords development process significantly. For example, identifying a specific place (such as a building on campus) with a Internet operating system, Middleware, Campus application smartphone requires access to the sensors on the device development, Internetware and the campus building layout information, as well as a positioning algorithm. As many campus applications 1. INTRODUCTION will require the same identification feature, we can provide Operating systems are running on almost all modern common APIs or services for outdoor (or even indoor) computing devices, such as PCs, smartphones, embedded location identification, such that all location-based campus systems and even sophisticated sensors. The key function- applications do not need to reinvent the wheel. alities of an operating system are managing various kinds In order to support the existing (and emerging) appli- of resources (CPU, storage, peripherals, etc.) and providing cations on campus, we argue that an operating system programming and runtime support. is needed to provide sufficient support during application With the prevalence of the Internet, many computers are development, deployment, execution and maintenance. We connected together, forming a grid or cloud, in order to design CampusOS as an open, community-oriented operat- support more complex applications. If we treat a cluster, a ing system for university campuses. Just like traditional operating systems, CampusOS provides programming inter- faces, libraries, and runtime management of applications, although at a higher level. Many components of CampusOS Permission to make digital or hard copies of all or part of this work for depend on traditional operating systems like Windows and personal or classroom use is granted without fee provided that copies are Linux, as well as networked resources in the cloud and on not made or distributed for profit or commercial advantage and that copies the Internet. bear this notice and the full citation on the first page. To copy otherwise, to Many people may wonder why we need another operating republish, to post on servers or to redistribute to lists, requires prior specific system as many features provided by CampusOS can be permission and/or a fee. Internetware ’13 October 23–24 2013, Changsha, China implemented separately. We illustrate the necessity of an Copyright 2013 ACM 978-1-4503-2369-7/13/10 ...$15.00. operating system, as well as the contributions of CampusOS, from the following aspects. Service Campus Campus Application • CampusOS can provide support for students who are Daemon Store App Development interested in building personalized applications and Client excited to share them with friends. CampusOS SDK • CampusOS can provide support for courseware and Feature Service Driver Development course-related applications with course-specific cus- Server tomizations. • CampusOS can help manage different communities on CampusOS Core System campus, such as student union, student clubs, interest Development groups, sports teams, etc. • CampusOS can also serve as a research platform Figure 1: The development architecture of Cam- where researchers can distribute applications for ex- pusOS perimental purposes and collect user information with permission. CampusOS belongs to a larger ongoing project, in which we are constructing a prototype of an Internet operating system, which is a development and runtime supporting Service Interface …… Service Interface environment for Internetware [5, 6]. Syscall over Network CampusOS SDK Network Communication 2. CAMPUSOS DESIGN Network We adopt a hierarchical architecture in CampusOS, which Network Communication is similar to traditional operating systems. In this section, Syscall over Network & Dispatcher CampusOS Core we first present our design goal to make CampusOS an open VFS Dispatcher and extensible ecosystem. Then we describe the specific Service Driver …… Service Driver design of CampusOS. Underlying Implementation 2.1 Goal CampusOS is intended to serve as an open platform Figure 2: The runtime architecture of CampusOS for campus applications, which means that not only can developers publish new applications to CampusOS, but they can also add new features to CampusOS. CampusOS is computing platforms in CampusOS, the CampusOS SDK designed with the principle of extensibility in mind, such supports multiple programming languages, such as C, C++, that new features can be easily added into it. When some Java, C#, JavaScript, etc. developers come up with interesting new features, they can For better extensibility, we adopt two abstractions that choose to share the features with other developers by adding are originated from traditional operating systems and use them to CampusOS. With more and more features added them in CampusOS. One is the system call (syscall) and the into CampusOS, more complex campus applications can other is the virtual file system (VFS). be built, which will in turn attract more users and more Figure 2 shows the hierarchical runtime architecture of developers, thus forming an ecosystem. CampusOS. It illustrates the relation between the Cam- Besides its open and extensible characteristics, Cam- pusOS SDK and the CampusOS Core. The top layer pusOS supports multiple computing platforms to better consists of various service interfaces, which provide campus adapt to the development and deployment of campus ap- applications with APIs for accessing various features. The plications, including traditional PCs, smartphones, tablet service interfaces invoke CampusOS syscalls, which are computers and web browsers. In the meanwhile, CampusOS encoded and passed to the CampusOS Core via network. should protect the security and privacy of users' data against The CampusOS Core running on the server side accepts attackers and malicious campus applications. syscalls, decodes and dispatches them accordingly. The VFS layer maps service interfaces to their corresponding service 2.2 Architecture drivers. This mapping actually correlates feature invoca- Figure 1 shows the hierarchical development architecture tions in campus applications to feature implementations in of CampusOS. The bottom layer is the CampusOS Core CampusOS. and the underlying implementations of the whole system. This layer corresponds to the development of the CampusOS 2.3 Feature Extension system. The middle layer consists of service drivers on the In our design, CampusOS features are attached to VFS server side and the CampusOS SDK and service daemons on nodes and accessed via syscalls. In this way, we achieve the client side. This layer corresponds to the development the principle of extensibility. On the one hand, we provide and extension of CampusOS features. The top layer is uniform interfaces for accessing different features in the based on the CampusOS SDK, including CampusStore and CampusOS SDK. On the other hand, we provide a general campus applications. The development of various campus approach to organizing different CampusOS features. In applications belongs to this layer. short,