[lkml]   [2000]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Full preemption issues

On Fri, 27 Oct 2000, George Anzinger wrote:
> First, as you know, we have added code to the spinlock macros to count
> up and down a preemption lock counter. We would like to not do this if
> the macro also turns off local interrupts. The issue here is that in
> some places in the code, spin_lock_irq() or spin_lock_irqsave() is
> called but spin_unlock_irq() or spin_lock_irqrestore() is not. This, of
> course, confuses the preemption count. Attached is a patch that
> addresses this issue. At this time we are not asking you to apply this
> patch, but to indicate if we are moving in an acceptable direction.

Looks entirely sane to me.

> The second issue resolves around the naming conventions used in the
> kernel. We want to extend this work to include the SMP kernel, but to
> do this we need to have several levels of names for the spinlock
> macros. We note that the kernel uses "_" and "__" prefixes in some
> macros, but can not, by inspection, figure out when to uses these
> prefixes. Could you explain this convention or is this wisdom written
> somewhere?

The "wisdom" is not written down anywhere, and is more a convention than
anything else. The convention is that a prepended "__" means that "this is
an internal routine, and you can use it, but you should damn well know
what you're doing if you do". For example, the most common use is for
routines that need external locking - the version that does its own
locking and is thus "safe" to use in normal circumstances has the regular
name, and the version of the routine that does no locking and depends on
the caller to lock for it has the "__" version.

Your proto code does not break this convention in any way..


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.042 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site