Russell King wrote:
> On Mon, Jul 22, 2002 at 03:43:50PM +0200, Ingo Molnar wrote:
>
>>i'm not so sure about flags_t. 'unsigned long' worked pretty well so far,
>>and i do not see the need for a more complex (or more opaque) irqflags
>>type.
>
>
> A feature request then. Type checking. Too many people try to stuff
> the value into an int or signed long.
Amen.
well, if/when there's a concensus i'll do the type checking change in a
'second wave' patch, since it's a distinct issue not directly connected to
the naming cleanup.
there are some more IRQ subsystem cleanups for which i have patches: such
as the removal of the pt_regs parameter from the irq handler function,
it's unused in 99% of the drivers - and the remaining 1% can get at it via
other means.
Ingo
On Mon, Jul 22, 2002 at 04:05:00PM +0200, Ingo Molnar wrote:
> there are some more IRQ subsystem cleanups for which i have patches: such
> as the removal of the pt_regs parameter from the irq handler function,
> it's unused in 99% of the drivers - and the remaining 1% can get at it via
> other means.
If "other means" means knowing that its located in a certain place on the
stack, that's actually bogus. Any user space task started via exec from
a kernel thread has extra junk on the kernel stack. Been there already.
;(
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, 22 Jul 2002, Russell King wrote:
> If "other means" means knowing that its located in a certain place on
> the stack, that's actually bogus. Any user space task started via exec
> from a kernel thread has extra junk on the kernel stack. Been there
> already. ;(
no, i've added it to the irq descriptor structure, where it can be
accessed in normal ways by the driver. [the stack position thing doesnt
fly with vm86 tasks either.]
Ingo