On Thu, 2012-07-26 at 14:57 -0700, Joe Perches wrote: > 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? Fully agreed! One cannot use printk in performance path. Thanks, -Toshi > 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-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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
