Re: [PATCH 07/16] ACPICA: New: Portable acpidump utility (get system ACPI tables)

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

 



On Thursday, June 20, 2013 04:57:04 AM Moore, Robert wrote:
> 
> > -----Original Message-----
> > From: Rafael J. Wysocki [mailto:rjw@xxxxxxx]
> > Sent: Wednesday, June 19, 2013 4:11 PM
> > To: Moore, Robert
> > Cc: Len Brown; Zheng, Lv; Wysocki, Rafael J; Brown, Len; linux acpi
> > Subject: Re: [PATCH 07/16] ACPICA: New: Portable acpidump utility (get
> > system ACPI tables)
> > 
> > On Wednesday, June 19, 2013 12:48:56 AM Moore, Robert wrote:
> > > Sorry, I don't think the Linux version has been completed in version
> > > 20130517
> > > -- so perhaps you should ignore this patch after all, unless you want
> > > to simply establish the infrastructure for the final Linux version.
> > > The Linux-specific code is completed and will be part of the June
> > release.
> > 
> > Great, I'll take the patch at that time, then.
> > 
> > > However, we can still discuss the future of the changelog, etc. We
> > > seem to have an overall problem where the ACPICA commit log is
> > > "generic", but I'm seeing here a request to make the actual Linux
> > > patches more specific to Linux.
> > >
> > > As far as acpica and acpidump is concerned, I put specific generation
> > > instructions in the reference manual...
> > >
> > > Of course, the details for any individual operating system may be
> > > different (especially file locations), so I have to make the acpica
> > > changelog somewhat generic.
> > >
> > >
> > > Here is the actual acpica changelog text concerning acpidump, for
> > version 20130517:
> > >
> > > 2) iASL Compiler/Disassembler and Tools:
> > >
> > > New utility: Implemented an easily portable version of the acpidump
> > > utility to extract ACPI tables from the system (or a file) in an ASCII
> > > hex dump format. The top-level code implements the various command
> > > line options, file I/O, and table dump routines. To port to a new
> > > host, only three functions need to be implemented to get tables --
> > > since this functionality is OS-dependent. See the
> > > tools/acpidump/apmain.c module and the ACPICA reference for porting
> > instructions. ACPICA BZ 859. Notes:
> > > 1) The Windows version obtains the ACPI tables from the Registry.
> > > 2) The Linux version is under development.
> > > 3) Other hosts - If an OS-dependent module is submitted, it will be
> > > distributed with ACPICA.
> > 
> > Well, this is much better than what Lv sent, actually.
> > 
> > We could use it for Linux too, I think, only without the "Notes" part.
> > 
> > My general opinion is that we can simply use the same changelogs as the
> > ACPICA upstream does, possibly amended with a more detailed explanation of
> > the motivation behind the patch.
> > 
> > In this case, however, the changelog wasn't even similar to the original
> > one.
> > 
> 
> This is the text from the release notes which end up in the "changes.txt" file.

I see.  We don't get that information with the kernel patches, though.

> I usually expand upon the major changes in a format that is longer than the
> actual commit log.

So perhaps Lv (or whoever generates the Linux patches for the given release)
can simply add the information you put into "changes.txt" to the Linux patches
changelogs?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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