Whatever makes the most sense for the host OS. I think the original linux/acpi drivers were developed and debugged at the same time we were debugging the ACPICA core code, and it became very convenient to use the ACPI tracing and debugging mechanism to grab information about everything that was going on, ACPI-wise. This may or may not be important today. Also, there may come a time when we will decide to remove the tracing mechanism in ACPICA. However, over the years, this mechanism has proven very useful in finding problems. The execution trace is very helpful because of the nature of the AML interpretation and internal state changes. Bob > -----Original Message----- > From: Patrick Mochel [mailto:mochel@xxxxxxxxxxxxxxx] > Sent: Wednesday, April 19, 2006 10:37 AM > To: Moore, Robert > Cc: Accardi, Kristen C; Prarit Bhargava; Andrew Morton; Brown, Len; > greg@xxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; pcihpd- > discuss@xxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > arjan@xxxxxxxxxxxxxxx; muneda.takahiro@xxxxxxxxxxxxxx; pavel@xxxxxx; > temnota@xxxxxx > Subject: Re: [patch 1/3] acpi: dock driver > > On Wed, Apr 19, 2006 at 10:14:46AM -0700, Moore, Robert wrote: > > This is something to think about before we rip out all the ACPI > > core-style debug stuff. > > Not sure which part you're referring to, but maybe these: > > > > > > --- /dev/null > > > > > +++ 2.6-git-kca2/drivers/acpi/dock.c > > > > > @@ -0,0 +1,652 @@ > > > > > > > > > +#define ACPI_DOCK_COMPONENT 0x10000000 > > > > > +#define ACPI_DOCK_DRIVER_NAME "ACPI Dock Station Driver" > > > > > +#define _COMPONENT ACPI_DOCK_COMPONENT > > > > > > > > These aren't necessary for code that is outside of the ACPI-CA. > > > > > > Originally I did not include these, but it turns out if you wish to > > use > > > the ACPI_DEBUG macro, you need to have these things defined. I did go > > > ahead and use this macro in a couple places, mainly because I felt > > that > > > even though this isn't strictly an acpi driver (using the acpi driver > > > model), it does live in drivers/acpi and perhaps people might expect > > to > > > be able to debug it the same way. > > > Some of us have already thought about it. :-) > > We have standard debugging macros that are used in many driver subsystems > defined in include/linux/device.h (dev_printk(), dev_dbg(), dev_err(), and > friends). The ACPI drivers are not very different than other Linux driver > subsystems (at a very basic level). They are very Linux-specific (not > portable like the CA), and should be using Linux-specific constructs as > much as possible to match the rest of the kernel. This makes it much > eaiser for people to understand exactly what those drivers are doing.. > > > Pat - 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
