Re: use of preempt_count instead of in_atomic() at leds-gpio.c

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Jonathan Corbet
Date: Tuesday, March 25, 2008 - 6:44 am

Junio C Hamano <gitster@pobox.com> wrote:


The "right situation" would appear to be "you're deep in the mm code and
really know what you're doing."  It is not a useful way for code to
determine whether it's running in atomic context - as was discussed
elsewhere in the thread, that information really needs to be passed in
by the caller.
 
Look for more detail on LWN, probably later today :)


The point being that "you just *might* be in atomic context, where
sleeping would be a bad idea, but I can't tell you" really isn't all
that useful.  It's a trap which can only lead to incorrect code.

What really needs to happen, IMHO, is that this macro should be ripped
out of hardirq.h entirely and cleverly hidden somewhere.  That can't be
done, though, until the drivers which use it are fixed.  But while that
is happening, we can at least put up a skull-and-crossbones sign to
discourage others from making the same mistake.

jon
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Sun Mar 16, 11:43 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Thu Mar 20, 3:56 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Thu Mar 20, 5:36 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Thu Mar 20, 7:10 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Fri Mar 21, 5:37 am)
Re: use of preempt_count instead of in_atomic() at leds-gp ..., Jonathan Corbet, (Tue Mar 25, 6:44 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Wed Mar 26, 9:17 am)