RE: [patch 1/3] acpi: dock driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux