Device Driver for Kernel

8/2/2019 Device Driver for Kernel

1/24

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 025APRIL 2009

ANNA UNIVERSITY: CHENNAI 600 025


2/24

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 SIGNATURE

Prof.R.T.Sakthidaran Mrs.J.S.Kanchana

HEAD OF THE DEPARTMENT ASSISTANT PROFESSOR

Information Technology Information Technology

K.L.N.College of Engineering K.L.N.College of EngineeringPottapalayam P.O Pottapalayam P.OMadurai-Nedungulam Road Madurai-Nedungulam RoadSivagangai District. Sivagangai District.

DATE:

Submitted for the practical Examination held on_________________

INTERNAL EXAMINER EXTERNAL EXAMINER


3/24

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.


4/24

SYMBOLS AND DESCRIPTIONS

SYMBOLS DESCRIPTION

ACTOR

TO STARTPROCESS

USECASE

ACTIVE STATE

FLOW

TO END THEPROCESS


5/24

1. INTRODUCTION


6/24

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


7/24

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 asimple 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:


8/24

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:


9/24

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 modelA 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?


10/24

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:

Increment 2:

Increment 3:

1.6 PROJECT SCHEDULE:

Kernel

Kernel Times Interrupt Handler

Kernel Keyboard Handler


11/24

Review

No.

Description

Of

Completion

Date of

Completion

Duration First

Month

Second

Month

Third

Month

Fourth

Month

1 s t w e e

k

2 n d

w e e

k

3 r d

w e e

k

4 t h

w e e

k

1 s t w e e

k

2 n d

w e e

k

3 r d

w e e

k

4 t h

w e e

k

1 s t w e e

k

2 n d

w e e

k

3 r d

w e e

k

4 t h

w e e

k

1 s t w e e

k

2 n d

w e e

k

3 r d

w e e

k

Project

Approval

1 Abstract

2 Requirement

Specification

And design

3 Demo and

Draft project

Report4 Final project

Submission

3.1OBJECT ORIENTED ANALYSIS AND DESIGN:

UML:


12/24

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


13/24

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.


14/24

3.1.1.4. COLLABORATION DIAGRAM:

Collaboration diagrams illustrate the relationship and interaction betweensoftware 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 asystem, 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:


15/24

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:


16/24

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


17/24

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.


18/24

DEPLOYMENT DIAGRAM:

Calls Assembly File

Initializing, Setting updescriptor & loading

GDT

Initializing, Setting updescriptor & 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 keyboardhandler to IRQ 1

Linker Script

Code for displayingcharacter in screen by

defining putch(), cls() etc


19/24

COLLABORATION DIAGRAM:

: U s e r

: S y s t e m

: B IO S

: B o o tD e v i c e

: K e r n e l: M a i n

f u n c t i o n

: S t a c k

: ID T

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

1 : P o w e r o . ..11 : S w i tc h o ff () 2 : c a l ls B I O S r o u t in e s ( )

3 : P O S T fo r a ll d e v ic e s ( )

4 : L o a d s O S ()5 : L in k a ll fi le s a n d c a l l m a i . ..1 2 : K i ll a ll p r o c e s s ( )

6 : I n it ia l iz e s S t a c k ( )

7 : S e t u p ID T ( )

8 : S e t u p r o u t in e s f o r IR Q ( )9 : H a n d l e r f o r k e y b o a r d ( )

1 0 : T im e r h a n d l e r( )


20/24

SEQUENCE DIAGRAM:


21/24

: S y s t e m: U s e r

: B IO S :B o o tD e v i c e

: K e r n e l: M a i nf u n c t i o n

: S t a c k :ID T : IR Q :K e y b o a r

: T i

P o w e r o n ( )

P O S T f o r a l l d e v ic e s ( )

L o a d s O S ( )

L in 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 I D T ( )

S e t u p r o u t in e s f o r IR Q ( )

H a n d l e r fo r k e y b o a r d

T im e r h a n d l e r ( )

S w i t c h o f f ( )

K il l a l l p r o c e s s ( )

c a l ls B IO S r o u t i n e s ( )

USE-CASE DIAGRAM:


22/24


23/24

Install and initialize GDT

Install and initialize IDT

Define routines for ISR

IRQ initialization and handler

Timer handler

Keyboard handler

Display manager

Kill all process

Select the type of OS to be booted

Call kernels main

User

Shutdown the system


24/24

Device Driver for Kernel

Documents

Transcript of Device Driver for Kernel