About reentrant in Kernel modules / Device drivers

[Lokesh]

Hi All,

Few points needs to be addressed here about the kernel module
programming and the device driver which has a great impact on writing
the code for the kernel on reentrant.!!!!!

Yes, the question is does a device driver a reentrant ?
OR does any part (function) of the module (device driver) can be
reentrant ?
If yes, how do we write the code / measures to make them reentrant ?

What is reentrant mean to me here ?
It mean calling a device driver program again when a program (driver)
is already running.
Calling a function is the module again while the same is still under
run ?

Lets put across the views and opinios on this.

Regards
Lokesh

[nomius]

Hello,

Well, there are several considerations and ways to achieve re-entrant
code in a SMP preemptive kernel.

For example atomic operators is one of those. See for example the one
line code "x++". If x would be accessible, we read x, increment it and
write it back to memory in one uninterrupted operation. There's no
race condition in this matter. Atomic operators provide these
uninterrupted operations in this way:

atomic_t x;
atomic_set(&x, 1);
atomic_dec(&x);
printk(KERN_DEBUG "echo 2: %u\n", atomic_read(&x));

Another method are the spinlocks. Basically, a spinlock is like a
thread mutex, and its usage is pretty similar:

spinlock_t mylock = SPIN_LOCK_UNLOCKED;
unsigned long flags;
spin_lock_irqsave(&mylock, flags);
/* Re-entrant code here */
spin_unlock_irqrestore(&mylock, flags);

Using spin_lock_irqsave() will disable interrupts locally and provide
the spinlock on SMP, which covers both, interrupt and SMP concurrency
issues, while spin_unlock_irqrestore do the "unlock".
Spinlocks is these can be used anywhere, however, do not do anything
that will sleep while holding a spinlock, since the usage of spinlocks
bounded to situations of a small amount of time.

Anyways, there are several other ways to achieve re-entrant code in
device drivers.

I hope this light up the situation a little.

[Lokesh]

The atomic_t type is good for performing integer arithmetic. It
doesn't work as well enough when
you need to manipulate individual bits in an atomic way. For that
purpose, instead, the kernel offers
an alternative set of functions that modify or test single bits
atomically. Because the whole operation
happens in a single step, no interrupt (or other processor) can
interfere.

Atomic bit operations are very fast, since they perform the operation
using a single machine instruction
without disabling interrupts whenever the underlying platform can do
that. The functions are architecture
dependent and are declared in <asm/bitops.h>.

They are guaranteed to be atomic even on SMP machines and are useful
to keep coherence across processors.
Unfortunately, data typing in these functions is architecture
dependent as well. The nr argument (describing
which bit to manipulate) is usually defined as int but is unsigned
long for a few architectures.
The address to be modified is usually a pointer to unsigned long, but
a few architectures use void * instead.

--
You received this message because you are subscribed to the Google Groups "linuxgurus" group.
To post to this group, send email to linux...@googlegroups.com.
To unsubscribe from this group, send email to linuxgurus+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/linuxgurus?hl=en.