Embedded OS Application Programming

This Assignment allows for a team of 4 or 5 members to be responsible for the design and implementation of a simple system of tasks and various IPC mechanisms on a target Linux platform (one of your computers). Each task(subsystem) will be owned by a team member and will be held responsible to oral inquires from me on the: what, how, and design logic employed. Yes, an oral presentation (not formal) on how your system works and proof (exercising a test plan) that it does work. I suggest choosing a team lead who will coordinate (not dictate) the IPC Interface Control Design (Document, but not required for this assignment)(ICD) and as a team, design a comprehensive test plan.

This is a client, server, and data monitoring system. Each subsystem will be defined below. This is a simple data passing IPC where Client tasks gather their respective CPU affinity and priority of niceness, communicate with the Server (msgQ), and some simple information modifications on each Client, is passed to the Data Monitoring subsystem (SHM) for console display.

The Tuesday lecture provided any clarification to the intent and requirements not covered in this assignment. Additional clarification may be elicited via email or office visits.

Process flow: Client / Server / Data Monitoring / Test Plan: yes, I did not use a process flow diagram, not enough hours in a day.. However, your team could make one for any review questions I may have.

A new Client attaches to a msgQ and sends a message with a message type “42”, included in the message is the PID of the Client. The PID becomes the message ID (message type) between the Client and Server, after this initial connection. This is a prelude to secured messaging in SELinux.

The data from the Clients are monitored, augmented, and stored in SHM asynchronously by the Server. The Data monitoring subsystem will read the SHM on demand and display the current information from the Client and Server.

The Test Plan could be manual, but I suggest the team develop a simple script to cause measurable (visible) changes in the specifics of the clients.

Constraints:

Data Structures, named shared resources, and other ICD design requirements are part of your design. Any periodic rates management or synchronization is also part of your IPC design. Even the names of your subsystem application are your design.

The only constraint is the intent of the overall Process is met and proved.

Subsystems (Applications/tasks): All files and applications will be in a directory Hw8

1.The Client Application

a.A single task which will be launched at least 4 times

b.These tasks connect to the MsgQ

c.Each task sends a request to connect message to the Server (message type 42), and it’s PID

d.The task waits for a comply message from the Server with it’s PID as the message type

e.Once accepted

i.The task will loop forever

ii.Sending a message to the Server with its CPU affinity, current CPU assignment, and Priority (niceness)

2.The Server

a.Responsible for the creation of the MsgQ and SHM.

b.Loops forever

i.If a message type 42 is received

1.Creates a place in SHM for this new client managed by the Clients PID

2.Returns a message with the PID from the connect request message to the MsgQ

ii.If a message type PID is received (this is not the order of the steps, just the coverage)

1.The basic information is recorded in the managed SHM

a.Current CPU Affinity

b.Current CPU Assignment

c.Current Priority of niceness

2.If the Client’s new CPU Affinity differs from the current CPU affinity in the managed SHM

a.Increment a CPU Affinity change Count in the managed SHM

b.Counts the changes by the test script, forced change

3.If the Client’s new CPU assignment differs from the current CPU assignment in the managed SHM

a.Increment a CPU Assignment change Count in the managed SHM

b.Counts the CPU migration by the OS

4.If the Client’s new Priority differs from the current Priority in the managed SHM

a.Increment a Priority change Count in the managed SHM

b.Counts the changes of niceness by the test script, forced change

3.The Data Monitor

a.Command line execution

b.Attaches to the SHM

c.Prints the current load being monitored : the number of Clients

d.Prints each Client’s current values

i.Prints must have a column header for each element of the Clients saved data from the Server

ii.Each Client information is printed per line

4.Test Plan

a.A process to prove the proper data of each Client is being presented.

b.Performed during the demonstration

5.For teams of 4 and 5

a.Modify the Child Forking Homework.

i.Connect to the MsgQ and interface as the Client’s Task in section 1 above

ii.Once accepted

1.Each child “behaves” based on the Signals received.

2.If SIGURS1 is caught: change the Priority of the Child Niceness +1

3.If SIGURS2 is caught: change the Priority of the Child Niceness -1

4.If SIGINT is caught: set the Child’s affinity to MAX of your system

5.If SIGHUP is caught: reduce the Child’s affinity by one CPU

All errors and system constraints must be tested to make sure the applications do not fail during runtime.

Deliverables:

1.A “Readme” text file

a.includes the names of the team members

b.a “How Too” to explain how to run the systems from startup, testing and any termination

2.All students will submit a zip or tar file of the applications and test script

a.All these files and applications in a directory “Hw8”

b.Hw8.t or Hw8.zip is submitted to evaltools

3.Present the application in operation via our class Zoom or at the podium in the classroom