> -----Original Message----- > From: Rafael J. Wysocki [mailto:rjw@xxxxxxx] > Sent: Thursday, June 20, 2013 12:42 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 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? > Many times that would help. However, I describe only the major changes in the release notes; I don't mention things like cleanups or any other changes which don't affect functionality. Also, I don't mention really minor bug fixes. > Rafael > > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
