Re: [PATCH 1/3] m68k: compile fix - hardirq checks were in wrong place

> You separate the definition from the check, now you push the 
> responsibility to get the order right to the header users.
> Sorry, but I prefer to fix the header dependencies than scatter things 
> which belong together over multiple files.

For 2.6.16 I'll submit a patch to merge asm/irq.h and asm/hardirq.h.
Until then this is the much better fix because it doesn't require
pointless include reordering all over the tree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Follow-Ups:
- Re: [PATCH 1/3] m68k: compile fix - hardirq checks were in wrong place
  - From: Roman Zippel <[email protected]>

References:
- [PATCH 1/3] m68k: compile fix - hardirq checks were in wrong place
  - From: Al Viro <[email protected]>
- Re: [PATCH 1/3] m68k: compile fix - hardirq checks were in wrong place
  - From: Roman Zippel <[email protected]>

Prev by Date: [PATCH/RFC] SPI: async message handing library update
Next by Date: Re: 2.6.15-rc5-mm3 -- BUG: using smp_processor_id() in preemptible [00000001] code: swapper/1
Previous by thread: Re: [PATCH 1/3] m68k: compile fix - hardirq checks were in wrong place
Next by thread: Re: [PATCH 1/3] m68k: compile fix - hardirq checks were in wrong place
Index(es):
- Date
- Thread

[Index of Archives] [Kernel Newbies] [Netfilter] [Bugtraq] [Photo] [Stuff] [Gimp] [Yosemite News] [MIPS Linux] [ARM Linux] [Linux Security] [Linux RAID] [Video 4 Linux] [Linux for the blind] [Linux Resources]