DESIGNING A MINI KERNEL

A PROJECT REPORT Submitted by

E. Sridhar (90405205048) S. Deepak Kumar (90405205009)

In partial fulfillment for the award of the degree Of

BACHELOR OF TECHNOLOGY
In INFORMATION TECHNOLOGY

K.L.N.COLLEGE OF ENGINEERING POTTAPALAYAM SIVAGANGAI-630611

ANNA UNIVERSITY: CHENNAI 600 025

APRIL 2009

ANNA UNIVERSITY: CHENNAI 600 025

BONAFIDE CERTIFICATE
Certified that this project report DESIGNING

A DEVICE DRIVER

FOR PARALLEL PORT IN KERNEL SPACE is the bonafide

work of E. Sridhar (90405205048) & S. Deepak Kumar (90405205009) who carried out the project work under my supervision.

SIGNATURE Prof.R.T.Sakthidaran HEAD OF THE DEPARTMENT Information Technology K.L.N.College of Engineering Pottapalayam P.O Madurai-Nedungulam Road Sivagangai District. DATE:

SIGNATURE Mrs.J.S.Kanchana ASSISTANT PROFESSOR Information Technology K.L.N.College of Engineering Pottapalayam P.O Madurai-Nedungulam Road Sivagangai District.

Submitted for the practical Examination held on_________________

INTERNAL EXAMINER

EXTERNAL EXAMINER

ACKNOWLEDGMENT

We express our heartfelt gratitude to the Founder Mr. K.L.N. KRISHNAN, K.L.N. College of Engineering for inspiring us to achieve great heights. We would like to express our sincere gratitude to Dr. S. GANAPATHY, B.Sc, B.E., M.Sc (Engg.), Ph.D., Principal, K.L.N.College of Engineering for his kind patronage and all facilities offered. With gratitude, We record our indebtness Prof. R.T.SAKTHIDARAN, M.TECH (IITM)., DM (AIMA)., FIE., SMIEEE (USA)., Head of the Department of Information Technology who helped us to fire on all, cylinders during the course of the project work. With deep respect I express my gratitude to our faculty guide Mrs.J.S.KANCHANA M.E., ASSISTANT PROFESSOR, Department of Information Technology for helping us maintaining the momentum during the project work. And finally, we extended our sincere thanks to the teaching and non-teaching staff, our family, friends and well-wishers for their love, concern and moral support throughout the project.

SYMBOLS AND DESCRIPTIONS

SYMBOLS

DESCRIPTION

ACTOR

FLOW

USECASE

ACTIVE STATE

TO START PROCESS

TO END THE PROCESS

1. INTRODUCTION

1.1 PROBLEM STATEMENT:

Developing a kernel which will perform all basic functionalities like initialization of code, stack, GDT etc with capability of handling exceptions & interrupts like timer & keyboard.

1.2 OBJECTIVE:
To design a device Mini Kernel this will perform all basic functionality of OS.

1.2.1 EXISTING SYSTEM VS PROPOSED SYSTEM:

Existing system User space drivers Proposed System kernel space drivers Today most of the drivers are running in user space of our Primary Memory

1.3 METHODOLOGY:
Methodology is defined as

The analysis of the principles of methods, rules, and postulates employed by a discipline The systematic study of methods that are, can be, or have been applied within a discipline A particular procedure or set of procedures The common idea here is the collection, the comparative study, and the critique of the individual method that are used in a given discipline or field of inquiry. Methodology refers to more than a simple set of methods; rather it refers to the rationale and the philosophical assumption that underlie a particular study.

1.4 SOFTWARE LIFE CYCLE:

Software life cycle model (SLCM) is a representation of the major component of software development work and their interrelation in a graphical framework that can be easily understood and communicated. Just as the WBS partition the deliverable into its component parts so the SLCM apportion the work to be done into manageable work units. SLCM is needed for the project to: 1. Define the work to be performed. 2. Divide up the work into manageable pieces. 3. Determine project milestones at which project performance can be evaluated. 4. Define the sequence of work units. 5. Define the framework for definition and storage of the deliverable produced by the project.

FUNDAMENTAL PROCESS ACTIVITIES:

Four Fundamental Process Activities 1) Software Specification. 2) Software Development. 3) Software Validation. 4) Software Evaluation. To solve actual problems, a software engineer or a team must incorporate a development Strategy that encompasses the process, method and tools layers and the generic phases. This Strategy is often referred as Process Model.

1.4.1 PROCESS MODEL:

A process model for software engineering is chosen based on the nature of the project and application, the method and tools to be used, and the controls and deliverable that is required.

Development of software product

1.5 LIFE CYCLE MODELS:

Life cycle models describe the interrelationships between software development phases.

1.5.1 TYPES:
The common life cycle models are: Spiral model Waterfall model Throwaway prototyping model Evolutionary prototyping model Incremental/iterative development Reusable software model A model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required. In this project we are using Incremental Software Lifecycle Model.

1.5.2 INCRMENTAL MODEL:

The incremental build model is a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. Incremental model->CORE AROUND MULTIPLE ITERATIONS

At last after some iteration final product is designed.

1.5.2.1 Why people choose incremental model?

Since developer cannot gather all ideas for development of product so he develops the product with minimum requirements. On the further increments he will get the final indented product.

1.5.2.2 Why we chose incremental model?

Because we cannot directly feed data from device driver to printer.We first check the flow of data by connecting LEDS to parallel port. for this we connected 25pin male connector to the parallel port and soldered wires to that of it. So by connecting LEDs we can check data from device driver module.

1.5.2.3 INCREMENTAL STEPS: Increment 1:

Kernel

Increment 2:
Kernel Times Interrupt Handler

Increment 3:
Kernel Keyboard Handler

1.6 PROJECT SCHEDULE:

Review No.

Description Of Completion

Date of Completion

Duration

First Month 2nd week 3rd week 1st week

Second Month 4th week 1st week 2nd week 3rd week

Third Month 4th week 1st week 2nd week 3rd week

Fourth Month 4th week 1st week 2nd week 3rd week 4th week

Project Approval

Abstract

Requirement Specification And design

Demo and Draft project Report Final project Submission

3.1OBJECT ORIENTED ANALYSIS AND DESIGN: UML:

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing objects oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects.

GOALS:
The primary goals in the design of the UML were as follows: 1) Provide users a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. 2) Provide extensibility and specialization mechanisms to extend the core concepts. 3) Be independent of particular programming languages and development processes. 4) Provide a formal basis for understanding the modeling language. 5) Encourage the growth of the OO tools market. 6) Support higher-level development concepts such as collaborations, frameworks, patterns, and components. 7) Integrate best practices.

TYPES:
The following are the types of UML diagrams followed in this project: Use Case Diagram Activity Diagram Sequence Diagram

Collaboration Diagram Class Diagram

 Package Diagram Deployment Diagram

3.1.1. DETAILED DESIGN: 3.1.1.1. USE CASE DIAGRAM:

In many design processes, the use case diagram is the first that designers will work with when a project. Creating Use Case diagram for describing the behavior of the target system from an external point of view. A Use Case is made up of a set of scenarios. Each scenario is a sequence of steps that encompass an interaction between a user and a system. For each type of users there is one use case diagram.

3.1.1.2. ACTIVITY DIAGRAM:

Activity Diagrams describe the workflow behavior of a system. Activity Diagrams are also useful for analyzing a use case by describing what actions need to take place and when they should occur; describing a complicated sequential algorithm; and modeling applications with parallel processes. The diagrams describe the state of activities by showing the sequence. For every use case there is an activity diagram.

3.1.1.3. SEQUENCE DIAGRAM:

The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. Sequence diagrams can be used to document how objects in an existing (Call it legacy) system currently interacts. This documentation is very useful when transitioning a system to another person or organization. For each activity diagram there is one sequence diagram.

3.1.1.4. COLLABORATION DIAGRAM:

Collaboration diagrams illustrate the relationship and interaction between software projects. The Collaboration diagram illustrates messages being sent between classes and objects. Collaboration diagrams show the sequence by numbering the messages on the diagram. This makes it easier to show how the objects are linked together. For each sequence diagram there will be a collaboration diagram.

3.1.1.5. CLASS DIAGRAM:

Class diagram are widely used to describe the types of objects in a system and their relationships. It describes the types of objects in the system and the static relationships between them. Class diagram describe three different perspectives when designing a system, conceptual, specification, and implementation.

3.1.1.6. DEPLOYMENT DIAGRAM:

The deployment diagram shows how the components of the completed system are physically related (i.e. what hardware will the system be running on and how will it all be connected). A deployment diagram shows how and when the system will be deployed.

6.1SOFTWARE TESTING:

Software testing is the process used to help identify the correctness, completeness, security, and quality of developed computer software.

6.1.1. PURPOSE OF TESTING:

Testing is a process of executing a program or application with intent of finding errors. There are many approaches to software testing, but effective testing of complex products is essentially a process of investigation, not merely a matter of creating and following routine procedure: 1) Reducing the cost of developing the program. 2) Ensuring that the application behaves exactly as explained to the user. 3) Reducing the total cost of ownership. 4) Finding success with the program that offers quality.

6.2. TYPES OF TESTING:

1) Static Testing 2) Black box Testing 3) White box Testing 4) Unit Testing The testing that we used in this project is 1) Unit Testing 2) Integration Testing 3) Verification & Validation Testing

6.3. UNIT TESTING:

A unit testing is a method of testing the correctness of a particular module of source code. The idea is to write test cases for every non-trivial function or method in the module so that each is separate from the others if possible.

BENEFITS:

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. It provides a written contract that the piece must satisfy.

ENCOURAGES:
Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly (regression testing). This provides the benefit of encouraging programmers to make changes to the code since it is easy for the programmer To Check if the Piece is Still Working Properly.

SIMPLIFIES:
Unit testing helps eliminate uncertainty in the pieces themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts will make integration testing easier.

DOCUMENTS:
Unit testing provides a sort of living document for the class being tested. Clients looking to learn how to use the class can look at the unit test to determine how to use the class to fit their needs.

6.4. INTEGRATION TESTING:

Integration is a systematic approach to build the complete software structure specified in the design from unit-tested modules. Integration testing identifies problems that occur when units are combined. By using a test plan that requires testing each unit and ensuring the viability of each combining units, any errors discovered when combining units are likely related to the interface between units. It is a logical extension of Unit testing. The Integration plan describes the sequence of integration, overhead software, test environment and resources required.

SYSTEM TESTING:
System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the systems compliance with its specified requirements. System testing falls within scope of black box testing, and as such, should require no knowledge of the inner design of the code of logic. System

testing tasks, as its input, all the integrated software components that have successfully passed integration testing and also the software system itself integrated with any applicable hardware system(s). System testing is a more limiting type of testing; it seems to detect defects both within the inter assemblages and also within the system as a whole.

6.5. VERIFICATIO AND VALIDATION: 6.5.1. VERFICATION:

Verification refers to the set of activities that ensure that software correctly implement a specific function Verification: Are we building the product right?

6.5.2. VALIDATION:
Software is completely assembled as a package, interfacing errors have been uncovered and corrected and a final series of software test-validation testing-may begin. Validation: Are we building the right product? After all validation test cases have been conducted one of two possible conditions exists. 1) Performance characteristics conform to specification and accepted. 2) A deviation from the specification is uncovered and deficiency list is created.

DEPLOYMENT DIAGRAM: Linker Script

Calls Assembly File

Initializing, Setting up descriptor & loading GDT

Initializing, Setting up descriptor & loading IDT

Defining, Installing ISR & its fault handler

Define IRQ with handler routine, remap & install IRQ

Define timer handler & install timer handler to IRQ 0

Define keyboard handler & install keyboard handler to IRQ 1

Code for displaying character in screen by defining putch(), cls() etc

COLLABORATION DIAGRAM:
1 : P o w e r o ... 1 1 : S w itc h o ff( ) : S y 2 tecm lls B IO S r o u tin e s ( ) s: a : U ser : B 3 : S O S T fo r a ll d e v ic e s ( ) IO P : Boot D e v ic e

: S ta c k 4 : L o a d s O S () 5 : L in k a ll file s a n d c a ll m a i... 6 : In itia lize s S ta c k ( ) 1 2 : K ill a ll p r o c e s s () : K e rn e l : M a in 7 : S e t u p ID T () fu n c tio n 1 0 : T im e r h a n d le r ( ) 9 : H a n d le r fo r k e y b o a r d ( ) 8 : S e t u p r o u tin e s fo r IR Q ( ) : IR Q : K e y b o a rd : T im e r : ID T

SEQUENCE DIAGRAM:

: S y s t e m: B IO S : B o o t : K e r n e :l M a i n : S t a c k : ID T : U ser D e v ic e f u n c t io n P o w e r o n () c a l ls B IO S r o u t i n e s ( ) P O S T f o r a ll d e v ic e s ( )

: IR Q

: : T im e r K e y b o a rd

L o a d s O S () L i n k a l l f i le s a n d c a l l m a i n ( ) In i t ia l i z e s S t a c k ( ) S e t u p ID T ( ) S e t u p r o u t i n e s f o r IR Q ( ) H a n d le r fo r k e y b o a r d ( ) T im e r h a n d l e r ( )

S w itc h o ff( ) K il l a l l p r o c e s s ( )

USE-CASE DIAGRAM:

Install and initialize GDT

Select the type of OS to be booted

Install and initialize IDT

User

Define routines for ISR Call kernels main

IRQ initialization and handler

Timer handler Shutdown the system

Kill all process

Keyboard handler

Display manager