On Mon, 31 Mar 2008 00:53:32 +0800
"Peter Teoh" <htmldeveloper@xxxxxxxxx> wrote:
> Thanks Rik,
>
> On Mon, Mar 31, 2008 at 12:16 AM, Rik van Riel <riel@xxxxxxxxxxx> wrote:
> > On Sun, 30 Mar 2008 23:24:50 +0800
> > "Peter Teoh" <htmldeveloper@xxxxxxxxx> wrote:
> >
> > > Is there any guidelines on when and where can we insert printk() to do
> > > debugging?
> >
> > You can use it pretty much anywhere.
> >
>
> Ah....so I supposed it updates the memory directly, no I/O is involved
> right? Another daemon will then asynchronously read it from the
> memory to write to the system file (/var/log/message*) - correct?
> (this operation can sleep.) So since printk() DOES NOT sleep (as
> implied by u) we can pretty use it anywhere?
There is no daemon involved. Printk will print things to the console
when it can, and leave it in the buffer when it can't. The next caller
to printk will print whatever the previous caller left in the buffer,
if anything, plus its own message.
> > Multiple preempt_disable+preempt_enable sequences can nest, because
> > they simply keep a counter and preemption will not be enabled until
> > the counter reaches zero (the outer-most preempt_disable call).
>
> Ok, I am trying to understand this:
>
> spin_lock()-->_spin_lock():
>
> void __lockfunc _spin_lock(spinlock_t *lock)
> {
> preempt_disable();
> spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
> LOCK_CONTENDED(lock, _raw_spin_trylock, _raw_spin_lock);
> }
>
> For preempt_disable() (linux/preempt.h):
>
> #define preempt_disable() \
> do { \
> inc_preempt_count(); \
> barrier(); \
> } while (0)
>
> but inc_preempt_count() effectively just increase the
> current_thread_info()->preempt_count.
>
> and barrier() just put a barrier to cancel any potential internal CPU
> instructions reordering through optimization. So question is WHERE
> IS the preemption disabling? Ie, "cli" in x86 context?
> (but inside spin_acquire(), which called lock_acquire(), there is a
> check for irq_disabled(), and therefore the irq disabling must happen
> before this spin_acquire(), right?)
A spinlock does not count as a preemption. Only a context switch
does.
Before deciding whether or not to do a context switch, the kernel
checks the preempt count of the current process. If it is zero,
a preempt may be done, if it is non-zero, a preempt will have to
wait.
--
All rights reversed.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
