Messages in this thread | | | Date | Thu, 05 Aug 2004 20:35:10 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [PATCH] cleanup ACPI numa warnings |
| |
--Alex Williamson <alex.williamson@hp.com> wrote (on Thursday, August 05, 2004 15:25:42 -0600):
> On Thu, 2004-08-05 at 14:01 -0700, Dave Hansen wrote: >> On Thu, 2004-08-05 at 13:46, Alex Williamson wrote: >> > +#ifdef ACPI_DEBUG_OUTPUT >> > +#define acpi_print_srat_processor_affinity(header) { \ >> > + struct acpi_table_processor_affinity *p = \ >> > + (struct acpi_table_processor_affinity*) header; \ >> > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "SRAT Processor (id[0x%02x] " \ >> > + "eid[0x%02x]) in proximity domain %d %s\n", \ >> > + p->apic_id, p->lsapic_eid, p->proximity_domain, \ >> > + p->flags.enabled?"enabled":"disabled")); } >> > + >> > +#define acpi_print_srat_memory_affinity(header) { \ >> > + struct acpi_table_memory_affinity *p = \ >> > + (struct acpi_table_memory_affinity*) header; \ >> > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "SRAT Memory (0x%08x%08x length " \ >> > + "0x%08x%08x type 0x%x) in proximity domain %d %s%s\n",\ >> > + p->base_addr_hi, p->base_addr_lo, p->length_hi, \ >> > + p->length_lo, p->memory_type, p->proximity_domain, \ >> > + p->flags.enabled ? "enabled" : "disabled", \ >> > + p->flags.hot_pluggable ? " hot-pluggable" : "")); } >> >> Is there a reason that this can't be a normal function instead of a >> 9-line #define? > > Well, it's 9 lines, but it boils down to one printk. I'm not sure > putting it in a function would make it any more readable, long printks > are ugly by design. Either way would work.
Multi-line #defines are inherently eeeeevil ;-) I'd agree with Dave - static inlines are the normal way to do this.
M.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |