Xenomai Timer :Xenomai has two time sources: the sytem timer, which counts the number of nanoseconds since 1970, and a hardware dependent high resolution counter which counts the time since an unspecified point in time (usually the system boot time). This hardware dependent high resolution counter is called “tsc” on a PC, and gave its name to Xenomai native API calls.rt_timer_tsc returns the value of this hardware dependent high-resolution counter.
rt_timer_info returns the same thing in the tsc member of the RT_TIMER_INFO structure, and the value of the system timer at exactly the same time as when the high-resolution counter was read.

This allows to have a correspondence between the two time sources.

rt_alarm_inquire is not related to this and returns some information
about a given alarm. Now, if you allow me, a little advice for the implementation of a “timer library”: you could be tempted to create only one periodic alarm object with Xenomai, and to manage a timer list yourself. Don’t do this. Creating an alarm object for each timer library object make Xenomai aware of the existence of all your application timers, this has several

advantages:
– it gives you information about all your timers in /proc/xenomai
– it allows Xenomai to use its anticipation algorithm for all your timers
– if you are concerned about the scalability of Xenomai timers list
management, you can check the options in the “Scalability” menu of
Xenomai configuration menu (“Real-time subsystem” sub-menu of kernel
configuration menu).
more about timers

Xenomai POSIX skin supports two clocks:
CLOCK_REALTIME maps to the nucleus system clock, keeping time as the amount of time since the Epoch, with a resolution of one system clock tick.

CLOCK_MONOTONIC maps to an architecture-dependent high resolution counter, so is suitable for measuring short time intervals. However, when used for sleeping (with clock_nanosleep()), the CLOCK_MONOTONIC clock has a resolution of one system clock tick, like the CLOCK_REALTIME clock.[1]

Before understanding semaphore we should first discuss the critical section.
critical section is a piece of code that can be executed by two or more process at a time. Because of the simultaneous access of code our data might get inconsistent. To avoid this inconsistency we use synchronization methods.

so semaphore is one of the synchronization technique. It is a locking mechanism which is use to provide a lock for the access of critical section. If a process wants to access the critical section it has to acquire the lock first and free the lock once it has completed their work. When one process is already having the lock and other process try to acquire the lock then that process has to wait for the time till the lock is freed by previous process.

suppose we have total n number of same object and for that we have n number of lock. if a process try to acquire a lock and lock is available then the value of lock will be decreased by one or if lock is not available then that process has to wait till the time any lock is available. we can understand this by following example.

total number of objects = 3

total number of locks available =3

Process           Step                   Lock available                     Lock value        Status

 P1                acquire                       Yes                                    2                Acquired

 P2                acquire                       Yes                                    1                Acquired

 P3                acquire                       Yes                                    0                Acquired

 P4                acquire                       No                                     0                  Wait

 P2                release                       Yes                                    1                Released

 P4                acquire                      Yes                                     0                Acquired

Before understanding Xenomai it’s really important to understand the Normal Linux os and Real Time OS and how they execute their instructions.
Definition from Xenomai’s Website : Xenomai is a real-time development framework cooperating with the Linux kernel, in order to provide a pervasive, interface-agnostic, hard real-time support to user-space applications, seamlessly integrated into the GNU/Linux environment. Xenomai is based on an abstract RTOS core, usable for building any kind of real-time interfaces, over a nucleus which exports a set of generic RTOS services. Any number of RTOS personalities called “skins” can then be built over the nucleus, providing their own specific interface to the applications, by using the services of a single generic core to implement it. Xenomai runs over seven architectures (namely ppc, blackfin, arm, x86, x86_64, ia64 and ppc64), a variety of embedded and server platforms, and can be coupled to two major Linux kernel versions (2.4 and 2.6), for MMU-enabled and MMU-less systems. Supported real-time APIs include POSIX 1003.1b, VxWorks, pSOS+, VRTX and uITRON.

## Difference between RT os and Normal OS ##

– The Linux scheduler, like that of other OSes such as Windows or MacOS, is designed for best average response, so it feels fast and interactive even when running many programs. However, it doesn’t guarantee that any particular task will always run by a given deadline. A task may be suspended for an arbitrarily long time, for example while a Linux device driver services a disk interrupt.

– Scheduling guarantees are offered by real-time operating systems (RTOSes), such as QNX, LynxOS or VxWorks. RTOSes are typically used for control or communications applications, not for general purpose computing.

– The general idea of RT Linux is that a small real-time kernel runs beneath Linux, meaning that the real-time kernel has a higher priority than the Linux kernel. Real-time tasks are executed by the real-time kernel, and normal Linux programs are allowed to run when no real-time tasks have to be executed. Linux can be considered as the idle task of the real-time scheduler. When this idle task runs, it executes its own scheduler and schedules the normal Linux processes. Since the real-time kernel has a higher priority, a normal Linux process is preempted when a real-time task becomes ready to run and the real-time task is executed immediately.

How is the real-time kernel given higher priority than Linux kernel?

Basically, an operating system is driven by interrupts, which can be considered as the heartbeats of a computer:

1. All programs running in an OS are scheduled by a scheduler which is driven by timer interrupts of a clock to reschedule at certain times.
2. An executing program can block or voluntary give up the CPU in which case the scheduler is informed by means of a software interrupt (system call).
3. Hardware can generate interrupts to interrupt the normal scheduled work of the OS for fast handling of hardware.

RT Linux uses the flow of interrupts to give the real-time kernel a higher priority than the Linux kernel:

1. When an interrupt arrives, it is first given to the real-time kernel, and not to the Linux kernel. But interrupts are stored to give them later to Linux when the real-time kernel is done.
2. As first in row, the real-time kernel can run its real-time tasks driven by these interrupts.
3. Only when the real-time kernel is not running anything, the interrupts which were stored are passed on to the Linux kernel.
4. As second in row, Linux can schedule its own processes driven by these interrupt.

Hence, when a normal Linux program runs and a new interrupt arrives:

1. It is first handled by an interrupt handler set by the real-time kernel;
2. The code in the interrupt handler awakes a real-time task;
3. Immediately after the interrupt handler, the real-time scheduler is called ;
4. The real-time scheduler observes that another real-time task is ready to run, so it puts the Linux kernel to sleep, and awakes the real-time task.
Hence, to the real-time kernel and Linux kernel coexist on a single machine a special way of passing of the interrupts between real-time kernel and the Linux kernel is needed. Each flavor of RT Linux does this is in its own way. Xenomai uses an interrupt pipeline from the [Adeos project][1]. For more information, see also [Life with Adeos][2].
[1]: http://home.gna.org/adeos/
[2]: http://www.xenomai.org/documentation/xenomai-2.3/pdf/Life-with-Adeos-rev-B.pdf

Xenomai
———–

The Xenomai project was launched in August 2001.
Xenomai is based on an abstract RTOS core, usable for building any kind of real-time interfaces, over a nucleus which exports a set of generic RTOS services. Any number of RTOS personalities called “skins” can then be built over the nucleus, providing their own specific interface to the applications, by using the services of a single generic core to implement it.
The following skins on the generic core are implemented :
POSIX
pSOS+
VxWorks
VRTX
native: the Xenomai skin
uITRON
RTAI: only in kernel threads
Xenomai allows to run real-time threads either strictly in kernel space, or within the address space of a Linux process. A real-time task in user space still has the benefit of memory protection, but is scheduled by Xenomai directly, and no longer by the Linux kernel. The worst case scheduling latency of such kind of task is always near to the hardware limits and predictable, since Xenomai is not bound to synchronizing with the Linux kernel activity in such a context, and can preempt any regular Linux activity with no delay. Hence, he preferred execution environment for Xenomai applications is user space context.
But there might be a few cases where running some of the real-time code embodied into kernel modules is required, especially with legacy systems or very low-end platforms with under-performing MMU hardware. For this reason, Xenomai’s native API provides the same set of real-time services in a seamless manner to applications, regardless of their execution space. Additionally, some applications may need real-time activities in both spaces to cooperate, therefore special care has been taken to allow the latter to work on the exact same set of API objects.
In our terminology, the terms “thread” and “task” have the same meaning. When talking about a Xenomai task we refer to real-time task in user space, i.e., within the address space of a Linux process, not to be confused with regular Linux task/thread.

Here i am sharing a regex to validate the Email.

This is an standard version of regex.

^([a-zA-Z0-9\!\#\$\%\&\'\*\+\/\=\?\^\_\`\{\|\}\~\-]+)(?:\.[A-Za-z0-9\!\#\$\%\&\'\*\+\/\=\?\^\_\`\{\|\}\~\-]+)*@([a-zA-Z0-9]([\-]?[a-zA-Z0-9]+)*\.)+([a-zA-Z0-9]{0,6})\$

It can validate email like

Valid Emails

arungupta@gmail.com
arun+gupta+ramjiki+@gmail.com
a.little.lengthy.but.fine@dept.example.com
disposable.style.email.with+symbol@example.com
other.email-with-dash@example.com
arun@daiict.ac.in
arun_gupta@gmail.com

Invalid Emails

me@
@example.com
me.@example.com
.me@example.com
me@example..com
me.example@com
me\@example.com

I installed Vmware it was working well, i updated/upgraded OS firmware, now it’s not working. i googled it and found the solution. before telling the solution i wanna tell why this is coming.

VMware Player has a nice auto-detection of kernel changes, and requests the user to compile the required modules in order to load them. This happens from time to time after a regular update of your system. Usually, the dialog of VMware Kernel Module Updater pops up, asks for root access authentication, and completes the compilation.

In theory this is supposed to work flawlessly but in reality there are pitfalls occassionally. With the recent upgrade to Ubuntu 13.04 Raring Ringtail and the latest kernel 3.8.0-21 the actual VMware Kernel Module Updater simply disappeared and the application wouldn’t start as expected. When you launch VMware Player as super user (root) the dialog would stall.

Solution is :

sudo vmware-modconfig --console --install-all

This solution worked for me.

My machine was VMware Player 5.0.2 build-1031769

I have a Ubuntu 13.04 that I just installed fresh. Now if I try to do anything with apt-get, it tries to connect to archive.ubuntu.com .. It stays at [Connecting to archive.ubuntu.com (2001:67c:1360:8c01::1a)] phase for like 2 minutes, after which it actually starts to communicate and download stuff …

Eventually it always connects, but in waits at the [Connecting to archive.ubuntu.com (2001:67c:1360:8c01::1a)] phase everytime for like 2 minutes !

I didn’t have this problem previously on Ubuntu 13.04, right after reinstalling the OS ..

Solution:

I figured out the problem. Posted below as an answer!

Running the following command in Terminal tells if IPv6 is enabled or not:

cat /proc/sys/net/ipv6/conf/all/disable_ipv6

0 means its enabled, while 1 means its disabled.

To disable IPv6 from within Terminal, enter the following and reboot:

echo "#disable ipv6" | sudo tee -a /etc/sysctl.conf
echo "net.ipv6.conf.all.disable_ipv6 = 1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv6.conf.default.disable_ipv6 = 1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv6.conf.lo.disable_ipv6 = 1" | sudo tee -a /etc/sysctl.conf

After boot, re-run the first command, and it should be 1 now, after running this run

sudo sysctl -p

all output should be 1, now ipv6 is disable here.