JakubFloty´nski ADistributedSoftwareDevelopmentEnvironmentforNetworkDeviceDrivers

(1)

POZNA ´NSKIE WARSZTATY TELEKOMUNIKACYJNE 2011 1

A Distributed Software Development Environment

for Network Device Drivers

Jakub Floty´nski

Abstract—Complex low-level distributed systems like network device drivers require convenient software development environ-ments. Currently, only high-level development environments are satisfactorily supported by software providers. However, some frameworks, mainly for wireless sensor networks, can provide hints to design platforms for building low-level distributed appli-cations. In this paper, a novel Distributed Software Development Environment aiming at development of network device drivers is presented.

Index Terms—development environment, distributed system, network device drivers.

I. INTRODUCTION

Nowadays, applications are becoming increasingly complex, and the software development process requires more advanced tools. The process is especially complicated for network systems distributed among many devices. For such systems, a crucial issue is to provide a convenient software development environments (SDEs) that allow programmers to concentrate on the software development process instead of the set of used tools.

A distributed software development process may be un-derstood in two ways. First, people working on the same project may be the source of distribution [16] in which case a crucial issue is to provide efﬁcient communication among them. Second, the distribution may be a feature of a system [18] which is launched across many nodes.

On the one hand, providers of SDEs focus mainly on high-level application development, which reﬂect current market demand. A lot of advanced application servers integrated with robust integrated SDEs are available (e.g., [9][8]). On the other hand, convenient solutions for low-level programming (e.g., network device drivers) are still missing. The deployment process consists of a few activities: writing code, distributing it among network nodes, compiling, installing and running. The most satisfactory approaches are used for wireless sensor net-works (e.g., [17]). Due to the number of nodes, the solutions must support automatic deployment.

The main contribution of this paper is a novel Distributed Software Development Environment (DSDE) designed for programming low-level network applications. It is partially similar to SDEs for sensor networks, but is adjusted to local area networks and offers some additional features.

The paper is structured as follows. First, software develop-ment for network systems is brieﬂy described with focus on low-level programming. Second, requirements for an SDE for

J. Floty´nski is with the Department of Information Technology, the Poznan University of Economics, e-mail: ﬂotynski@kti.ue.poznan.pl.

low-level network systems are speciﬁed. Third, the idea and components of a novel Distributed Software Development En-vironment are described. Next, an example of using the DSDE is presented. Conclusions and future research are considered at the end of the article.

II. SOFTWAREDEVELOPMENT FORNETWORKSYSTEMS

Development of network software is often linked with the distribution of particular system components. Two types of distribution may be distinguished: the distribution of workers and the distribution of applications installed among different network nodes.

To deal with the ﬁrst type of distribution and improve the cooperation of a large number of employees, different tools enabling communication, work organization and the exchange of data have been proposed. Subversion systems [3] (e.g.,

CollabNet [2]) are used to store and serve subsequent versions

of the software developed. Issue (e.g., Jira [4]), project (e.g.,

Conﬂuence [5]) or bug trackers [7] (e.g., Trac [6]) improve

project management and enable sharing of information. To accomplish the second type of distribution, convenient SDEs have been proposed. Distributed high-level applications are usually launched on robust application servers like

Glass-Fish [8] or Oracle BPEL Project Manager [9]. Software

deployment and management on such servers may be done remotely - a development environment does not need to be installed together with the server on the same computer. The software developed is usually deployed on the server installed on a single machine. High-level platforms are usually designed for object-oriented programming [12] like Java or C#.

Another approach is presented by SDEs designed typically for network distributed systems, e.g., Message Passing Inter-face (MPI) [10] or Parallel Virtual Machine (PVM) [11]. In the case of such platforms, the code compilation is coupled with the automatic distribution of an application among network nodes.

Software deployment and update is an important issue in the area of wireless sensor networks [13]. Both low (e.g., in C [19]) or high-level (e.g., in Java [17]) programming may be utilized for such networks. In these SDEs nodes are programmed remotely, because of their number, and the software development is similar to MPI and PVM in terms of the automatic deployment of distributed applications.

III. REQUIREMENTS FOR ANETWORKDEVICEDRIVERS

DEVELOPMENTENVIRONMENT

Although different SDEs for network systems are available, they are mainly adjusted to the development of high-level

(2)

Fig. 1. The GUI of Eclipse

Fig. 2. The text-based interface of Vim

applications. Solutions appropriate for low-level distributed software, e.g. network device drivers, are still lacking. This paper touches the problem of designing an SDE to enable the efﬁcient development of low-level network applications. The following requirements have been speciﬁed for the environ-ment.

1) Centralized programing: The programmer should use

only one machine (a workstation) to perform the entire de-velopment process on network nodes.

2) Use of free popular open-source tools: Components of

the environment should be free for use and distribution. This reduces the costs of the project and allows its results to be shared easily. The tools should be widely used and have extensive documentation to deal with problems that may occur. Additionally, the source code of the tools should be open to enable the introduction of upgrades.

3) Source code editors for graphical and text-based user interfaces: While target applications are usually low-level

(e.g., device drivers) and do not use a graphical user interface (GUI), development may be done using a graphical interface. A number of graphical source code editors are available for the most frequently used operating systems like Windows and Linux. In addition, using GUI is easier and more intuitive for many programmers then programming in text mode. However useful, the installation of GUI may be too demanding for work stations with limited capabilities. In such cases, programming in text mode should be supported by the environment as well.

4) Convenient compilation from inside a source code edi-tor: The code compilation should be initiated directly from

inside a source code editor or by invoking an additional appli-cation or a shell script, but without performing any complex activities (e.g, typing complicated commands manually).

5) Recompilation of the last modiﬁed parts of source code:

Only the last modiﬁed source code needs to be recompiled, instead of recompiling the entire application every time after the introduction of any modiﬁcations.

6) Remote installation and software launching : The new

version of software written on the workstation should be distributed among the nodes, installed on them remotely and launched on demand. The results of launching need to be available for the programmer.

7) Availability of previous software versions: Subsequent

versions of source code should be stored and available for the programmer. This is useful for retrieving an old version of the software (e.g., when the new one is defective) or retrieving a node after a crash.

8) Possibility of the exchange of software components: The

software components of the environment should be indepen-dent enough to be exchanged without complex modiﬁcations of the framework.

IV. COMPONENTS OF ADISTRIBUTEDSOFTWARE

DEVELOPMENTENVIRONMENT

In this section, a novel Distributed Software Development Environment (DSDE) that satisﬁes the above requirements is presented. It is assumed that the network the software is developed for consists of a workstation and several nodes. The workstation is used by a programmer to perform the entire development process: writing code, spreading it across the nodes, compiling, launching and viewing results. The modiﬁed software is installed and launched on the network nodes. The environment proposed is designed for the development of network device drivers for the Linux operating system, but it could be designed for other operating systems (e.g., Win-dows) as well by using equivalent software. The environment incorporates the following components.

9) Source code editors: The DSDE includes two code

editors for graphical and text-based user interfaces installed on the workstation.

Eclipse [20] is a complex framework enabling software

development in several languages, such as Java, C++, C, PHP and JavaScript. The tool is convenient for local [15] as well as for distributed [14] application development. It is an open-source project distributed under the Eclipse Public License, so it may be used and distributed for free. It is written in Java language and requires Java Virtual Machine (JVM) to run. The platform is modular. Many free open-source plugins, which extend its functionality are available, e.g., subversion client, UML diagram builder, code style analyzer, web servers, and many others. The plugins are often presented as separate small windows within the main one (Fig. 1). An important advantage of Eclipse is the excellent documentation, tutorials and support provided by a large community. In the project, Eclipse is used as a source code editor with the subversion client plugin [1] used to manage versions of source code.

(3)

Vim is used as a source code editor for Linux when only a

text-based user interface is available (Fig. 2). It is free software under a GPL compatible license. A graphical user interface may be added to Vim, but it is not needed - using Eclipse is a preferred solution when a GUI is available. Like Eclipse, Vim supports plugins, for instance a code browser or checking the code style.

10) Code compiler: Although Eclipse provides a code

compiler, it is not used to compile the code, because the compilation should be done individually on each network node. Such an approach enables the use of different hardware architectures within a single network. The DSDE uses GNU Compiler Collection (GCC) [21], installed on the nodes, which is currently the most commonly used code compiler for Unix-like operating systems. It supports various processor architec-tures and programming languages, e.g., Fortran, Pascal, Java or Ada.

11) Secure shell: OpenSSH is a software package enabling

remote shell commands for the DSDE. The ﬁrst tool in the package (SFTP) is used to copy source code from the workstation to the nodes. The second tool (SSH) is used to login to remote nodes, start the compilation and launch the application. Both the compilation and launching results may be sent back to the workstation and presented to the programmer.

OpenSSH incorporates a client and a server. The server is

installed on each network node. The client is installed on the workstation and connects to the servers to perform the commands remotely.

12) Shell scripts and tools: Shell scripts are written in

the Linux command line interpreter language. The language has functionality similar to that of widely used programming languages such as C or Pacal, e.g., conditional, switch and loop instructions, variables or structures. First, shell scripts have been developed and installed on the workstation to copy the software to the nodes using OpenSSH. Second, other shell scripts installed on the nodes are used to compile and run the code. The scripts call GCC and Modprobe - a command line tool responsible for the management of Linux modules. Linux modules includes device drivers, for instance for the MAC layer or Atheros network chips. Modules may be started and stopped independently until there are no dependencies among them.

Some additional tools may be also installed on the nodes (e.g., for conﬁguration) like ifconﬁg or iw responsible for setting the parameters of the network interfaces.

Another tool (Tar) is used in the DSDE to build an archive containing the upgraded code. It is installed on both the workstation (to pack data) and on the nodes (for unpacking it). In general, many other tools may be installed on the nodes (e.g., for conﬁguration) providing that they are invoked from the command line.

Shell scripts on the workstation are currently launched manually from the command line, which may be somewhat inconvenient for the programmer. This could be improved by introducing an appropriate plugin for the code editor.

13) Subversion system: Two systems for the management

of code versions are used under the DSDE. The ﬁrst is an

Eclipse plugin [1], being an SVN client. The second is the

CollabNet application [2], providing a client and a server.

The server installed on a separate device stores the subsequent versions of the code, while the client installed on the worksta-tion enables access to these versions. Using a separate SVN client (aside from the Eclipse plugin) may be useful when code versions are accessed from outside Eclipse. CollabNet is available for both the Linux and Windows operating systems. The project is available under a modiﬁed GPL.

V. THEEXAMPLE OFNETWORKDRIVERSDEVELOPMENT

The DSDE has been used under the Future Internet Engi-neering project [22] carried out at Chair of Wireless Com-munications (Poznan University of Technology) to extend the Linux network device drivers. Currently, the driver implements the primary functionality of a wireless mesh network (WMN). A deterministic medium access protocol, that has not been implemented yet will be added to the driver. The WMN consists of four nodes that must be updated simultaneously. A workstation is connected to the network and has the follow-ing components installed: Linux, Eclipse, Vim, the CollabNet subversion server, the OpenSSH client and shell scripts. Each WMN node includes the OpenSSH server, shell tools and GCC.

A programmer writes code in Eclipse or Vim depending on the user interface currently used . When the driver is updated all the changes are saved, and a software package with the new code is created using Tar and sent to the nodes using the shell scripts and SFPT (OpenSSH). After delivery, the code is compiled using GCC and started individually on each node using remote SSH commands to Modprobe. Compiler messages are transmitted to the workstation and presented to the programmer. After the compilation succeeds, the application is run on each node using scripts. Some additional conﬁguration tools (ifconﬁg, iw) are installed on the WMN nodes and called by scripts to set the node parameters.

VI. CONCLUSIONS ANDFUTURERESEARCH

In this paper a novel Distributed Software Development environment has been presented. The DSDE is satisfactory especially for programming network device drivers, but is tailored also for other low-level applications, e.g., text-mode monitoring tools. Currently, it is designed for Linux and includes a few software components compatible with it, but they can be exchanged to use the environment on an another operating system, e.g., Windows or Solaris.

Among future research tasks, an Eclipse plugin responsible for performing the entire deployment process can be created. First, it copies ﬁles to remote network nodes. Second, it compiles the code, installs and launches it remotely. Third, results of the compilation and launching are sent back to the programmer. This would increase the convenience of using of the DSDE.

REFERENCES

[1] Eclipse subversion plugin, http://www.eclipse.org/subversive.

(4)

[3] C. Jones, Using subversion as an aid in evaluating individuals working on

a group coding project, In: Journal of Computing Sciences in Colleges,

Volume 25 Issue 3, 2010.

[4] Jira Issue and Project tracking, http://www.atlassian.com/software/jira/. [5] Conﬂuence, http://www.atlassian.com/software/conﬂuence/.

[6] Trac - Integrated SCM and Project Management, http://trac.edgewall.org/. [7] D. Bertram, A. Voida, S. Greenberg and R. Walker, Communication,

collaboration, and bugs: the social nature of issue tracking in small, collocated teams, In: Proceedings of the 2010 ACM conference on

Computer supported cooperative work, Savannah, 2010.

[8] A. Alghamdi, M. Nasir, I. Ahmad and K.A. Nafjan, The implementation

of dynamite: an environment for migrating PVM tasks, In: Proceedings of

International Symposium on Information Technology 2010 (ITSim 2010), Kuala Lumpur, 2010.

[9] S. Takada, The implementation of dynamite: an environment for migrating

PVM tasks, In: Proceeding of the 3rd international workshop on

Search-driven development: users, infrastructure, tools, and evaluation, Honolulu, 2011.

[10] H. Kamal, S. M. Mirtaheri and A. Wagner, Scalability of communicators

and groups in MPI, In: Proceedings of the 19th ACM International

Symposium on High Performance Distributed Computing. Chicago, 2010. [11] K. A. Iskra, F. van der Linden, Z. W. Hendrikse, B. J. Overeinder, G. D. van Albada and P. M. A. Sloot, The implementation of dynamite: an

environment for migrating PVM tasks, In: Proceedings of ACM SIGOPS

Operating Systems Review, Volume 34 Issue 3, 2000.

[12] K. Tae-Hoon, S. Woo-Chang, P. Geun-Duk, L. Tae-Heun, K. Tae-Gyun, G. S. Yeong and W. Chi-Su, DOOD: distributed object-oriented software

development environment, In: Proceedings of the Software Engineering

Conference, 1997. Asia-Paciﬁc Software Engineering and International Computer Science Conference 1997. APSEC ’97 and ICSC ’97, Hoing Kong, 1997.

[13] W. Schroder-Preikschat, R. Kapitza, J. Kleinoder, M. Felser, K. Karmeier, T. H. Labella and F. Dressler, Robust and Efﬁcient

Soft-ware Management in Sensor Networks, In: Proceedings of the second

IEEE/Create-Net/ICST International Conference on COMmunication Sys-tem softWAre and MiddlewaRE (COMSWARE), Bangalore, 2007. [14] J.S. Rellermeyer, G. Alonso and T. Roscoe, Building, deploying, and

monitoring distributed applications with Eclipse and R-OSGI, In:

Pro-ceedings of the 2007 OOPSLA workshop on eclipse technology eX-change, 2007.

[15] A.R. Gregersen and B.N. Jorgensen, Towards dynamic plug-in

re-placement in Eclipse plug-in development, In: Proceedings of the 2007

OOPSLA workshop on eclipse technology eXchange, 2007.

[16] P.F. Tiako, T. Lindquist and V. Gruhn, Process support for distributed

team-based software development workshop, In: Newsletter ACM

SIG-SOFT Software Engineering Notes, Volume 26 Issue 6, November 2001 .

[17] R.B. Smith, SPOTWorld and the Sun SPOT, In:Proceedings of the 6th international conference on Information processing in sensor networks, Boston, 2007.

[18] E. Keenan and A. Steele, Developing a pedagogical infrastructure for

teaching globally distributed software development, In: Proceeding of the

2011 community building workshop on Collaborative teaching of globally distributed software development, Honolulu, 2011.

[19] AVR Studio, http://www.atmel.com/microsite/avr studio 5/.

[20] Eclipse, http://www.eclipse.org/.

[21] GCC, the GNU Compiler Collection, http://gcc.gnu.org/. [22] Future Internet Engineering, https://www.iip.net.pl/en/project/.