All sockets programs and client server project is implemented successfully.
All sockets programs and client server project is implemented successfully.
suppose we define a binary semaphore why its starting value is 1???????
BeagleBoard
The Beagle Board is a pocket-sized reference board containing a Texas Instruments OMAP3530 system-on-a-chip (SoC) processor (ARM Cortex A-8 core) running at up to 600MHz. (Find a link to more system specs in Resources later in this article.) Tiny reference boards are not themselves necessarily newsworthy—companies such as Gumstix have been providing similar boards for several years, including some based on the OMAP3530 processor. I picked the Beagle Board because it is an inexpensive platform for learning how Linux and small systems work. It is a reasonable alternative for hobbyists designing projects for themselves, academics creating projects for classes, and professionals designing low-cost appliances or thin clients.
For More Board Information visit:
www.beagleboard.org/static/BBSRM_latest.pdf
Required Items To Bring-up :
Three items are required to boot the Beagle Board:
1.A desktop or laptop computer with a serial port (see the sidebar Notes on host platforms for more information)
2.A serial connector
3.A USB device cable, standard-A to mini-A
The Beagle Board comes with no cables or connectors. See the Beagle Board Shopping List (in Resources) for a list of required and optional items, as well as links to them. Most of the items shown here are available individually or as a package.
Serial connection:
For the serial connection, you need the following components:
1.IDC10-to-DB9M serial cable
2.DB9F-to-DB9F null modem cable
3.DB9M-to-USB cable (optional if your host platform has an RS-232 port)
4.USB mini-B male-to-USB A male cable
The combination of the first three cables gives you a serial connection, which enables you to watch and interact with the board’s bootloader and operating system through a terminal emulation program on your host platform.
Input and output:
For input and output, you need the following items:
1. Powered USB 3-port hub with Ethernet
2. 5mm barrel power plug-to-USB A male adapter
3. USB mini-A-to-USB A female On-The-Go (OTG) cable (optional; lets it be powered over its USB connection)
These items give you the maximum benefit from using a Linux distribution on your Beagle Board. The built-in Ethernet gives you a network connection. The hub itself gives you a USB port for providing power to the Beagle Board with the 5mm power plug.
Keyboard, video, mouse :
For keyboard-video-mouse (KVM) functionality, you need the following items:
1. HDMI male-to-DVI-D male cable
2. Digital monitor
3. USB keyboard
4. USB mouse
You may be tempted to use a PS/2 keyboard with a converter. Take my advice: buy a USB keyboard. A PS/2 keyboard would probably work with the Ångström Linux distribution, the demo described in this article, but you may well go further than this in the future, and not all distributions include a PS/2 driver.
You may also be tempted to try to use an analog (VGA) monitor or a DVI-D-to-VGA conversion cable. The Beagle Board does not emit the analog signal that would drive this setup, so using a converter or analog monitor would be fruitless. If your monitor does not accept digital (HDMI or DVI-D) input, consider using a TV and a 4-pin S-video cable, instead. Also note that audio does not work acceptably yet on Ångström, so don’t spend too much time trying to track down speakers or headphones.
SD cards :
You need at least one SD card to store Linux and its bootloaders. If you do not want to go through the process of downloading the software and partitioning the card, Special Computing (see Resources for a link) has a deal: You can order a 4GB SD card with the Ångström demo preloaded.
Connecting the components :
When you have all of the parts, it’s time to start plugging things in. First, connect the serial port by performing the following steps:
1. Plug the IDC10 cable into the Beagle Board with the cable’s pin 1 going to pin 1 of the connector (the pink wire on the ribbon cable faces the outer corner of the board).
2. Plug the DB9M end into the null-modem DB9F/DB9F cable.
3. Plug the DB9F/DB9F cable into your host platform, if it has a DB9 port. Otherwise, plug the cable into a DB9M/USB cable, then plug that into the host.
Next, connect USB and power:
1. Plug the USB mini-A end of the mini-A/USB A female cable into the Beagle Board’s USB mini-A connector.
2. Plug the powered USB hub into the USB A female end of the same cable.
3. Plug the USB end of the USB/5mm barrel cable into the hub.
4. Plug the 5mm barrel end into the Beagle Board’s barrel connector.
Note: Do not connect power to the hub yet.
Now, connect the keyboard, mouse, and video:
1. Plug the HDMI end of video cable into the Beagle Board’s HDMI connector.
2. Plug the DVI-D end into your monitor.
3. Plug the USB keyboard into the hub.
4. Plug the USB mouse into the hub.
Setting up the operating system:
The host system is ready and the Beagle Board is set up. All you need now is an operating system.
Downloadable binaries exist for many Linux distributions that run on the Beagle Board, with Ångström, Maemo, Ubuntu, and Android being the most popular. All are under active development, and all have been demonstrated in public by professionals and hobbyists alike. This article covers the Ångström distribution, which is well tested and lean enough that it turns the Beagle Board into a viable Linux desktop machine and not-so-thin client. See Resources for links to video demonstrations as well as to the Ångström binary download.
The Ångström Linux distribution :
1. First-stage bootloader
2. Second-stage bootloader
3. Linux boot image (uImage)
4. Linux file system
The Beagle Board’s firmware contains a first-stage bootloader called X-loader. X-loader can also be loaded from a removable storage space (such as an SD card) in a signed file called MLO. X-loader bootstraps the system only enough to load the second-stage bootloader, which otherwise would not fit into memory.
The second-stage bootloader provided in flash memory on the Beagle Board is U-boot, although most distributions provide their own version of U-boot in a file called u-boot.bin. U-boot initializes the system, then boots the Linux kernel. It can also be run from the console.
The Linux boot image, named uImage, finally boots the Linux kernel, which resides in the Linux file system in the /boot directory.
There are several ways to set up the file system; the method shown here requires a bit of work at the beginning but is flexible. Also note that this is the way the pre-built Ångström SD cards arrive if you order them from Special Computing.
How Linux Boot (For Intel x86 Architecture) :
Stage 1 Boot Loader :
The primary boot loader that resides in the MBR is a 512-byte image containing both program code and a small partition table (see Figure 2). The first 446 bytes are the primary boot loader, which contains both executable code and error message text. The next sixty-four bytes are the partition table, which contains a record for each of four partitions (sixteen bytes each). The MBR ends with two bytes that are defined as the magic number (0xAA55). The magic number serves as a validation check of the MBR.
The job of the primary boot loader is to find and load the secondary boot loader (stage 2). It does this by looking through the partition table for an active partition. When it finds an active partition, it scans the remaining partitions in the table to ensure that they’re all inactive. When this is verified, the active partition’s boot record is read from the device into RAM and executed.
Stage 2 Bootloader :
The secondary, or second-stage, boot loader could be more aptly called the kernel loader. The task at this stage is to load the Linux kernel and optional initial RAM disk.
The first- and second-stage boot loaders combined are called Linux Loader (LILO) or GRand Unified Bootloader (GRUB) in the x86 PC environment. Because LILO has some disadvantages that were corrected in GRUB, let’s look into GRUB.
The great thing about GRUB is that it includes knowledge of Linux file systems. Instead of using raw sectors on the disk, as LILO does, GRUB can load a Linux kernel from an ext2 or ext3 file system. It does this by making the two-stage boot loader into a three-stage boot loader. Stage 1 (MBR) boots a stage 1.5 boot loader that understands the particular file system containing the Linux kernel image. Examples include reiserfs_stage1_5 (to load from a Reiser journaling file system) or e2fs_stage1_5 (to load from an ext2 or ext3 file system). When the stage 1.5 boot loader is loaded and running, the stage 2 boot loader can be loaded.
With stage 2 loaded, GRUB can, upon request, display a list of available kernels (defined in /etc/grub.conf, with soft links from /etc/grub/menu.lst and /etc/grub.conf). You can select a kernel and even amend it with additional kernel parameters. Optionally, you can use a command-line shell for greater manual control over the boot process.
With the second-stage boot loader in memory, the file system is consulted, and the default kernel image and initrd image are loaded into memory. With the images ready, the stage 2 boot loader invokes the kernel image.
Kernel Image :
With the kernel image in memory and control given from the stage 2 boot loader, the kernel stage begins. The kernel image isn’t so much an executable kernel, but a compressed kernel image. Typically this is a zImage (compressed image, less than 512KB) or a bzImage (big compressed image, greater than 512KB), that has been previously compressed with zlib. At the head of this kernel image is a routine that does some minimal amount of hardware setup and then decompresses the kernel contained within the kernel image and places it into high memory. If an initial RAM disk image is present, this routine moves it into memory and notes it for later use. The routine then calls the kernel and the kernel boot begins.
When the bzImage (for an i386 image) is invoked, you begin at ./arch/i386/boot/head.S in the start assembly routine (see Figure 3 for the major flow). This routine does some basic hardware setup and invokes the startup_32 routine in ./arch/i386/boot/compressed/head.S. This routine sets up a basic environment (stack, etc.) and clears the Block Started by Symbol (BSS). The kernel is then decompressed through a call to a C function called decompress_kernel (located in ./arch/i386/boot/compressed/misc.c). When the kernel is decompressed into memory, it is called. This is yet another startup_32 function, but this function is in ./arch/i386/kernel/head.S.
In the new startup_32 function (also called the swapper or process 0), the page tables are initialized and memory paging is enabled. The type of CPU is detected along with any optional floating-point unit (FPU) and stored away for later use. The start_kernel function is then invoked (init/main.c), which takes you to the non-architecture specific Linux kernel. This is, in essence, the main function for the Linux kernel.
With the call to start_kernel, a long list of initialization functions are called to set up interrupts, perform further memory configuration, and load the initial RAM disk. In the end, a call is made to kernel_thread (in arch/i386/kernel/process.c) to start the init function, which is the first user-space process. Finally, the idle task is started and the scheduler can now take control (after the call to cpu_idle). With interrupts enabled, the pre-emptive scheduler periodically takes control to provide multitasking.
During the boot of the kernel, the initial-RAM disk (initrd) that was loaded into memory by the stage 2 boot loader is copied into RAM and mounted. This initrd serves as a temporary root file system in RAM and allows the kernel to fully boot without having to mount any physical disks. Since the necessary modules needed to interface with peripherals can be part of the initrd, the kernel can be very small, but still support a large number of possible hardware configurations. After the kernel is booted, the root file system is pivoted (via pivot_root) where the initrd root file system is unmounted and the real root file system is mounted.
The initrd function allows you to create a small Linux kernel with drivers compiled as loadable modules. These loadable modules give the kernel the means to access disks and the file systems on those disks, as well as drivers for other hardware assets. Because the root file system is a file system on a disk, the initrd function provides a means of bootstrapping to gain access to the disk and mount the real root file system. In an embedded target without a hard disk, the initrd can be the final root file system, or the final root file system can be mounted via the Network File System (NFS).
Root File System (Init Process):
After the kernel is booted and initialized, the kernel starts the first user-space application. This is the first program invoked that is compiled with the standard C library. Prior to this point in the process, no standard C applications have been executed.
In a desktop Linux system, the first application started is commonly /sbin/init. But it need not be. Rarely do embedded systems require the extensive initialization provided by init (as configured through /etc/inittab). In many cases, you can invoke a simple shell script that starts the necessary embedded applications.
Resources :
http://www.ibm.com/developerworks/linux/library/l-beagle-board/
http://www.ibm.com/developerworks/linux/library/l-linuxboot/
What’s the difference between insmod and modprobe commands to load a kernel module ?
Getting followong error msg while installing the kernel 3.0.4
WARNING: modpost: Found 5 section mismatch(es).
To see full details build your kernel with:
‘make CONFIG_DEBUG_SECTION_MISMATCH=y’
A device driver has three sides: one side talks to the rest of the kernel, one talks to the hardware, and one talks to the user.
In order to talk to the kernel, the driver registers with subsystems to respond to events. Such an event might be the opening of a file, a page fault, the plugging in of a new USB device, etc.
User Interface of a Device driver
Since Linux follows the UNIX model, and in UNIX everything is a file, users talk with device drivers through device files. Device files are a mechanism, supplied by the kernel,
precisely for this direct User-Driver interface.
Anatomy of scull device driver
The user talks with scull through the /dev/scull device file.When the user opens /dev/scull, the kernel calls scull’s open routine. When the user closes /dev/scull, the kernel calls scull’s release routine
Scull talks to the kernel through its initialization function . . . and through register_chrdev
. . . and through hooking into the timer interrupt .
Driver Initialization Code
static int __init scull_module _init ( void )
{
int ret ;
pr_debug ( ” Scull module init called \ n ” ) ;
i f ( ( ret = register_chrdev (SCULL_MAJOR_NUM, ” scull ” , & scull _ fops printk(KERN_ERR ” register_chrdev : %d \ n ” , ret ) ;
return ret ;
}
Driver Initialization
One function (init) is called on the driver’s initialization.
One function (exit) is called when the driver is removed from the system.
Question: what happens if the driver is compiled into the kernel, rather than as a module?
The init function will register hooks that will get the driver’s code called when the appropriate event happens.
Question: what if the init function doesn’t register any hooks?
There are various hooks that can be registered: file
operations, pci operations, USB operations, network operations – it all depends on what kind of device this is.
Registering Chardev Hooks
struct file_operation scull_fops = {
. owner = THIS_MODULE,
. open = scull_open ,
. release = scull _ release ,
. read = scull _read ,
. wr i t e = scull _write ,
.mmap = scull_mmap ,
. ioctl = scull _ ioctl
} ;
. . .
i f ( ( ret = register_chrdev (SCULL_MAJOR_NUM, ” scull ” , & scull _fops ) ) < 0 )
printk (KERN_ERR ” register_chrdev : %d \ n ” , ret ) ;
User Space Access to the Driver
The driver registers a character device tied to a given major number, but how does the user create such a file?
# mknod /dev/scull c 250 0
And how does the user open it?
if ((kfd = open(“/dev/scull”, O_RDWR)) < 0) {
perror(“open /dev/scull”);
exit(EXIT_FAILURE);
}
File Operations
. . . and then you start talking to the device. scull uses the following device file operations:
open for allocating resources.
release for finishing releasing resources.
write for seting the starting positions
read for generating and then reading the next state .
mmap for potentially faster but more complex direct access .
The open and release Routines
open and release are where you perform any setup not done in initialization time and any cleanup not done in module unload time.
Scull_open
scull’s open routine allocates the scull structure which holds all of the state
static int scull_open ( struct inode *inode , struct file *filp )
{
struct scull *k ;
int ret ;
ret = alloc_scull (&k ) ;
if ( ret )
return ret ;
filp->private_data = k ;
return 0 ;
}
scull_release
scull’s release routine frees the resource allocated during open time.
static int scull_release ( struct inode *inode , struct file *filp )
{
struct scull *k = filp->pr i vate_data ;
…..
…..
free_scull ( k ) ;
return 0 ;
}
Open and Release
Beware of races if you have any global data . . . many a driver author stumble on this point.
Note also that release can fail, but almost no onechecks errors from close(), so it’s better if it doesn’t . . .
Question: what happens if the userspace program crashes while holding your device file open?
Use copy_from_user in case the user is passing a bad pointer.
Commentary on write
Note that even for such a simple function, care must be exercised when dealing with untrusted users.Users are always untrusted.
Always be prepared to handle errors!
memory mapping
The read-write mechanism, involves an overhead of a system call and related context switching and of memory copying. mmap maps pages of a file into memory, thus enabling
programs to directly access the memory directly and save the overhead, . . . but:
fast synchronization between kernel space and user space is a pain (why do we need it?),
and Linux read and write are really quite fast.
Referrence:-
Muli Ben-Yehuda IBM Haifa Research Labs and Haifux – Haifa Linux Club
Understanding the Linux Kernel, by Bovet and Cesati
Linux Device Drivers, 3rd edition, by Rubini et. al.
Linux Kernel Development, 2nd edition, by Robert Love
/usr/src/linux-xxx/
The Exec family calls
To create a new process, which initially is a near duplicate of its parent process . Often, the new process immediately executes a new program. The act of creating a new process is called forking, and this functionality is provided by the fork( ) system call. Two acts—first a fork, to create a new process, and then an exec, to load a new image into that process are thus required to execute a new program image in a new process.
The exec family of functions shall replace the current process image with a new process image. The new image shall be constructed from a regular, executable file called the new process image file. There shall be no return from a successful exec, because the calling process image is overlaid by the new process image.
There is no single exec function; instead, there is a family of exec functions built on a single system call. List of exec() family system calls are:
When a C-language program is executed as a result of this call, it shall be entered as a C-language function call as follows:
int main (int argc, char *argv[]);
where argc is the argument count and argv is an array of character pointers to the arguments themselves.
The argv array are each terminated by a null pointer. The null pointer terminating the argv array is not counted in argc. The arguments specified by a program with one of the exec functions shall be passed on to the new process image in the corresponding main() arguments. The argument path points to a pathname that identifies the new process image file.
The argument file is used to construct a pathname that identifies the new process image file. If the file argument contains a slash character, the file argument shall be used as the pathname for this file. Otherwise, the path prefix for this file is obtained by a search of the directories passed as the environment variable PATH
Signals set to the default action (SIG_DFL) in the calling process image shall be set to the default action in the new process image. Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling process image shall be set to be ignored by the new process image. Signals set to be caught by the calling process image shall be set to the default action in the new process image
The new process shall inherit at least the following attributes from the calling process image:
Upon successful completion, the exec functions shall mark for update the st_atime field of the file. If an exec function failed but was able to locate the process image file, whether the st_atime field is marked for update is unspecified.
Lets see a the some examples of exec() family calls.
Using execl()
The following example executes the ls command, specifying the pathname of the executable ( /bin/ls) and using arguments supplied directly to the command to produce single-column output.
#include <unistd.h> int ret; ret = execl ("/bin/ls", "ls", "-1", (char *)0);
The following example is similar to Using execl(). In addition, it specifies the environment for the new process image using the env argument.
#include <unistd.h> int ret; char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 }; ret = execle ("/bin/ls", "ls", "-l", (char *)0, env);
The following example searches for the location of the ls command among the directories specified by the PATH environment variable.
#include <unistd.h> int ret; ret = execlp ("ls", "ls", "-l", (char *)0);
The following example passes arguments to the ls command in the cmd array.
#include <unistd.h> int ret; char *cmd[] = { "ls", "-l", (char *)0 }; ret = execv ("/bin/ls", cmd);
The following example passes arguments to the ls command in the cmd array, and specifies the environment for the new process image using the env argument.
#include <unistd.h> int ret; char *cmd[] = { "ls", "-l", (char *)0 }; char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 }; ret = execve ("/bin/ls", cmd, env);
The following example searches for the location of the ls command among the directories specified by the PATH environment variable, and passes arguments to the ls command in the cmd array.
#include <unistd.h> int ret; char *cmd[] = { "ls", "-l", (char *)0 }; ret = execvp ("ls", cmd);
Return Value:
If one of the exec functions returns to the calling process image, an error has occurred; the return value shall be -1, and errno shall be set to indicate the error.(Refer man pages)
In our next article we will cover some more system calls like exit(),kill() and using fork and exec() family functions.
cvs server implemented in accordance with the document
@sidharth sir
please tell how to check its functioning
#include
int main()
{
printf(“done with semaphore\n”);
return 0;
}
