EmbLogic's Blog

Implemented semaphore for 3 clients and sending result to respective client from server

RCS file: ./semaphore.c,v
Working file: ./semaphore.c
head: 1.6
branch:
locks: strict
root: 1.6
access list:
symbolic names:
keyword substitution: kv
total revisions: 6;    selected revisions: 6
description:
this is the intial file going to start the SEMAPHORE
—————————-
revision 1.6    locked by: root;
date: 2014/03/25 07:26:08;  author: root;  state: Exp;  lines: +66 -16
successfully implemented 3 clients :1st client gives 23+ as input to server and after processing from the server
server will send the result to the same ist client through result fifo and value is reflected in the client1
after the critical area of client1
viceversa we got the result in 3 different clients
problem is that the irregular output various time as we run the same code
sometime it will take client1 2 times for the addition operation and then the subtract and willnt display for multiple
sometime unpredictable result we get
—————————-
revision 1.5
date: 2014/03/24 10:40:23;  author: root;  state: Exp;  lines: +2 -2
successfully implemented for 3 different clients we have 3 clients client1(rahul),client2(hello),client3(GGOOD)
first of all activate server semaphore.c
tehn run the script containing ./client1,./client2,./client3
for every client server will send the string rebount to noticify that the processing is done
first the client1 send the string and server send back rebound for all the clients but the client get into block on read
—————————-
revision 1.4
date: 2014/03/24 10:11:26;  author: root;  state: Exp;  lines: +5 -5
sending the result ie rebound to client1 and client 1 is reciving the rebound and rebound to client2
—————————-
revision 1.3
date: 2014/03/24 09:13:31;  author: root;  state: Exp;  lines: +28 -13
in this file we have send 2 different values from the 2 different clients to the server and the client that is invoked in the critical region server got the value and display
the server is kept in the while loop to continuous accept the clients value
heading towards the program in while result of the client computing is send back to the same client
—————————-
revision 1.2
date: 2014/03/24 06:24:19;  author: root;  state: Exp;  lines: +37 -10
successfully executed for 1 client file name client2
in this we are writting hello from the server and getting hello from the server through the fifo
heading towards the second client ie client1.c
—————————-
revision 1.1
date: 2014/03/20 10:09:35;  author: root;  state: Exp;
Initial revision
=============================================================================

Posted in Project 03: Client Server Communication using Linux and IPC | Leave a comment

Cross compiler

Introduction to Cross Compilation

This post is the first in a series on cross compilation. In this series I’ll introduce the concept of cross compilation, and how to used it. Although there are many different uses for cross compilation, I’ll focus in this series in its use for embedded Linux systems development.

What is Cross Compilation?

When you develop a desktop or server application, almost always the development platform (the machine that runs your compiler) and the target platform (the machine that runs your application) are the same. By “platform” I mean the combination of CPU architecture, and Operating System. The process of building executable binaries on one machine, and run them on another machine when the CPU architecture or the Operating System are different is called “cross compilation”. A special compiler is needed for doing cross compilation that is called “cross compiler“, and sometimes just “toolchain”.

For example, desktop PC application developers for Windows or Linux can build and run their binaries on the very same machine. Even developers of server applications generally have the same basic architecture and Operating System on both their development machine and server machine. The compiler used in these cases is called “native compiler”.

On the other hand, developers of an embedded Linux application that runs on a non PC architecture (like ARM, PowerPC, MIPS, etc.) tend to use a cross compiler to generate executable binaries from source code. The cross compiler must be specifically tailored for doing cross compilation from the development machine’s architecture (sometimes called “host”), to the embedded machine’s architecture (called “target”).

Note: cross compilation is only needed when generating binary executables from source code written in a compiled language, like C or C++. Programs written in interpreted language, like Perl, Python, PHP, or JavaScript, do not need a cross compiler. In most cases interpreted programs should be able run unchanged on any target. You do need, however, a suitable interpreter running on the target machine.

What is Cross Compilation Good for?

I have covered above one reason for doing cross compilation, that is, the target machine has a different CPU architecture that the development host. In this case cross compilation is necessary because the binaries that the native compiler generates won’t run on the target embedded machine.

Sometimes cross compilation is not strictly necessary, but native compilation in not practical, or inconvenient. Consider, for example, a slow ARM9 based target machine running Linux. Having the compiler run on this target will make the build process painfully slow. In many cases target machine is just under-powered, in terms of storage and RAM, for the task of running a modern compiler.

Practically speaking, almost all embedded Linux development is being done with cross compilers. Strong PC workstation machines are used as development hosts to run the development environment (text editor, IDE), and the cross compiler.

In the next post in this series I’ll show how get a cross compiler for embedded Linux development.

Posted in Uncategorized | Leave a comment

Inter Process Communication using semaphores and message queues

RCS file: ipc_fifoserver.c,v
Working file: ipc_fifoserver.c
head: 1.3
branch:
locks: strict
root: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;    selected revisions: 3
description:
created common fifo for requesting clients(3)
implemented semaphore
created common result fifo and have send resutl back to their respective requestints
sucessfully
—————————-
revision 1.3    locked by: root;
date: 2014/03/26 09:57:18;  author: root;  state: Exp;  lines: +40 -19
implemented message ques and got sucessfull in sending my result back to the requesting clients
—————————-
revision 1.2
date: 2014/03/26 07:24:43;  author: root;  state: Exp;  lines: +0 -30
implemented semaphore using 4 clients sucessfully
—————————-
revision 1.1
date: 2014/03/26 07:23:13;  author: root;  state: Exp;
Initial revision
=============================================================================

Posted in Project 03: Client Server Communication using Linux and IPC, Uncategorized | Tagged | Leave a comment

MESSAGE QUEUES

MESSAGE QUEUES
message queues are like pipes, only difference is that in pipes data go byte by byte. but in message queues ,message go block by block.
message queues use user free space.
message have 2 parts—
1. contol
2.data

BLOCK is define as-
struct_msg
{
unsigned long type;
char *payload;
};
where type is process pid
payload is message.
In message queues, both sender and receiver are independent of each other.
MSGMAX——-maximum size of payload
MSGMNB——-maximum number of blocks

1. msgget–
int msgget(key_t key,int msgflg);
2. msgctl—-
int msgctl(int msqid,
int command,
struct msqid_ds *buf);
commands are——
IPC_STAT—structure initialized
IPC_SET—-assigne value to message queqe
IPC_RMID—delete message queue
3. msgsend
int msgsend( int msqid,
const void *msg_ptr,
size_t msg_sz,
int msgflg,);

Posted in Uncategorized | Leave a comment

srand &rand

please tell how rand & srand function work.

Posted in Uncategorized | Leave a comment

receiver of message queue..

?
RCS file: mes_rc.c,v
Working file: mes_rc.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
message queues reciver ….recieve data in string..
=============================================================================

Posted in Uncategorized | Leave a comment

implementation of message queues

?
RCS file: mes_que.c,v
Working file: mes_que.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
implement message queues for learn it’s working
—————————-
revision 1.1 locked by: root;
date: 2014/03/26 06:06:15; author: root; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

semaphores

RCS file: ipc_fifoserver.c,v
Working file: ipc_fifoserver.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
created common fifo for requesting clients(3)
implemented semaphore
created common result fifo and have send resutl back to their respective requestints
sucessfully
=============================================================================

Posted in Project 03: Client Server Communication using Linux and IPC, Uncategorized | Leave a comment

SEMAPHORES

Semaphores

Semaphores are used to protect critical regions of code or data structures. Remember that each access of a critical piece of data such as a VFS inode describing a directory is made by kernel code running on behalf of a process. It would be very dangerous to allow one process to alter a critical data structure that is being used by another process. One way to achieve this would be to use a buzz lock around the critical piece of data that is being accessed, but this is a simplistic approach that would degrade system performance.

Instead Linux uses semaphores to allow just one process at a time to access critical regions of code and data; all other processes wishing to access this resource will be made to wait until it becomes free. The waiting processes are suspended, other processes in the system can continue to run as normal.

A Linux semaphore data structure contains the following information:

count
This field keeps track of the count of processes wishing to use this resource. A positive value means that the resource is available. A negative or zero value means that processes are waiting for it. An initial value of 1 means that one and only one process at a time can use this resource. When processes want this resource they decrement the count and when they have finished with this resource they increment the count,
waking
This is the count of processes waiting for this resource which is also the number of process waiting to be awakened when this resource becomes free,
wait queue
When processes are waiting for this resource they are put onto this wait queue,
lock
A buzz lock used when accessing the waking field.

Suppose the initial count for a semaphore is 1, the first process to come along will see that the count is positive and decrement it by 1, making it 0. The process now “owns” the critical piece of code or resource that is being protected by the semaphore. When the process leaves the critical region it increments the semphore’s count. The most optimal case is where there are no other processes contending for ownership of the critical region. Linux has implemented semaphores to work efficiently for this, the most common case.

If another process wishes to enter the critical region whilst it is owned by a process it too will decrement the count. As the count is now negative (-1) the process cannot enter the critical region. Instead it must wait until the owning process exits it. Linux makes the waiting process sleep until the owning process wakes it on exiting the critical region. The waiting process adds itself to the semaphore’s wait queue and sits in a loop checking the value of the waking field and calling the scheduler until waking is non-zero.

Posted in Project 03: Client Server Communication using Linux and IPC | Leave a comment

DHCP server

The Dynamic Host Configuration Protocol is used by computers for requesting Internet Protocol parameters, such as an IP address from a network server. The protocol operates based on the client-server model. DHCP is very common in all modern networks[1] ranging in size from home networks to large campus networks and regional Internet service provider networks. Most residential network routers receive a globally unique IP address within the provider network. Within a local network, DHCP assigns a local IP address to devices connected to the local network.

When a computer or other networked device connects to a network, its DHCP client software in the operating system sends a broadcast query requesting necessary information. Any DHCP server on the network may service the request. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, time servers. On receiving a request, the server may respond with specific information for each client, as previously configured by an administrator, or with a specific address and any other information valid for the entire network, and the time period for which the allocation (lease) is valid. A host typically queries for this information immediately after booting, and periodically thereafter before the expiration of the information. When an assignment is refreshed by the client computer, it initially requests the same parameter values, but may be assigned a new address from the server, based on the assignment policies set by administrators.

On large networks that consist of multiple links, a single DHCP server may service the entire network when aided by DHCP relay agents located on the interconnecting routers. Such agents relay messages between DHCP clients and DHCP servers located on different subnets.

Depending on implementation, the DHCP server may have three methods of allocating IP-addresses:

  • dynamic allocation: A network administrator reserves a range of IP addresses for DHCP, and each client computer on the LAN is configured to request an IP address from the DHCP server during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim (and then reallocate) IP addresses that are not renewed.
  • automatic allocation: The DHCP server permanently assigns an IP address to a requesting client from the range defined by the administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had.
  • static allocation: The DHCP server allocates an IP address based on a preconfigured mapping to each client’s MAC address. This feature is variously called static DHCP assignment by DD-WRT, fixed-address by the dhcpd documentation, address reservation by Netgear, DHCP reservation or static DHCP by Cisco and Linksys, and IP address reservation or MAC/IP address binding by various other router manufacturers.

DHCP is used for Internet Protocol version 4 (IPv4), as well as IPv6. While both versions serve the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they may be considered separate protocols.[2] IPv6 devices may alternatively use stateless address autoconfiguration. IPv4 hosts may use link-local addressing to achieve limited local connectivity.

Posted in Project 00: Linux System / Network Administration | Leave a comment

Memory management unit

Allocate available memory efficiently to multiple processes
Main functions

  • Allocate memory to processes when needed
  • Protect one process’s memory from another
  • Keep track of what memory is used and what is free.

Memory Allocation

  • Contiguous Allocation:Each process allocated a single contiguous chunk of memory

 

  • Non-contiguous Allocation
  • Parts of a process can be allocated non-
  • contiguous chunks of memory

 

Posted in Uncategorized | Leave a comment

Breif Discussion of fork ,pipe and execl.

Process:- Process is execution of set of statements in sequential way.

Fork():-It is a system call that create a duplicate process of the process which is evoking the system call(fork). After the fork statement the remaining part of a process is executed by two process if fork system call is used once. It creates one duplicate process with a new process id and and with parent process id same as that of process that is calling this system call. And program counter is given from where it is called. we can create as much process as we want in our project.As shown in Figure.

Pipe:- Pipe is a virtual link between the two process that are related in past for communicating between them. Pipe is a size of ram that is maximum 64kb but at a time you can just write 4kb in it. Pipe is form of circular queue which create array of least file descriptors available. At 0 index of that array you will find a file descriptor for reading from the pipe and at 1 index file descriptor of writing data into the pipe is available you can use any file descriptor at a time.And once the data is read from the pipe it is deleted automatically. and if you are reading from the pipe you need to write from another process otherwise if writer is not available then pipe will go in read on block condition and it will wait till something is written in the pipe and similarly the case is for write on block if their is no one to read from pipe.

Execl():- It is a statement which takes the execution process to other program given in its argument. And the current program is hijacked by other program.

Posted in Uncategorized | Leave a comment

about RCS

RCS (revision control system) is a project management tool. RCS uses a number of commands to manage source file. It works by tracking source file as its changed by maintaining a single file with list of changes in sufficient detail to recreate the previous version. It also allows you to store comment with every change , which can be very useful to look back in the history of changes that has made to the files. To RCS a file following commands are used.

1.   rcs -i filename

this creates a rcs file with name filenamec,v.

2. ci filename

3 . co -l filename

this locks the previous version of file and allow you to do further changes into it.

Posted in Uncategorized | Leave a comment

about RCS

RCS (revision control system) is a project management tool. RCS uses a number of commands to manage source file. It works by tracking source file as its changed by maintaining a single file with list of changes in sufficient detail to recreate the previous version. It also allows you to store comment with every change , which can be very useful to look back in the history of changes that has made to the files. To RCS a file following commands are used.

1. rcs -i filename

this creates a rcs file with name filenamec,v.

2. ci filename

3 . co -l filename

this locks the previous version of file and allow you to do further changes into it.

Posted in Uncategorized | Leave a comment

PIPE

we can use pipe between two related process only, related means both process has same pid in their past. after that we can read and write the data from any end.
To make a related process between two unrelated process, we have to do fork.
Now question is why we are using fork to make related process.
We are using fork to create a child process for our current process.
In this case child has its own pid but its ppid is same as current process pid.
It means both has a relation, but now problem is how we relate two different process.
we can create a relation between two different process with the help of execl().
We are using execl() in child only. besause if we are using execl() in parent thn it is not execute the whole process, it is terminated after the execl(). So it is compulsary to use execl() in child .
pipe has two descriptor one and zero.
zero for read abd One for write.
if pipe return zero it means it is created else it is not created.we have to pass the file descriptor to the other process through execl () in child.
Execl() takes string only and it is terminated by null.
and to make a string to pipe file descriptor, we are using sprintf function.
To take all the arrguments from child to other process we have to make the command line function to that funcion.
Now we can use pipe between two different process.

Posted in Uncategorized | Leave a comment