On Thu, 2012-07-26 at 15:50 -0600, Bjorn Helgaas wrote: > On Thu, Jul 26, 2012 at 3:43 PM, Joe Perches <joe@xxxxxxxxxxx> wrote: > > On Thu, 2012-07-26 at 15:37 -0600, Bjorn Helgaas wrote: > >> PNP0C01:00: new device for \_SB_.PCI0.ISA_.MBIO > >> > >> I fiddled with this a while ago; it would look something like this: > > [] > >> +static noinline_for_stack > >> +char *acpi_name_string(char *buf, char *end, acpi_handle handle, > >> + struct printf_spec spec, const char *fmt) [] > Yes. I'm hesitant about this approach in general, because I don't > think printing the ACPI path is something we should be doing often. > It's not like a struct resource or a MAC address, where there are > dozens or hundreds of users. I really think we should only print ACPI > paths in one or two places, so adding a %p extension would waste a > letter and encourage the wrong behavior. I don't much care for adding ACPI specific calls to vsprintf as acpi is supposed to be OS generic anyway. I don't think there's anything wrong with Toshi's approach. Anyone that looks for speed in a logging message is looking for an oddly fitting thing. Tracing sure, but logging? I also don't see anything wrong with renaming it to just acpi_<level>, but that's a different discussion. cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
