Re: acpica5 and acpi sub-modules (Re: cvs commit: src/sys/dev Ma
On Tue, May 25, 2004 at 11:44:39PM -0700, Matthew Dillon wrote:
> The first issue with the patch is that you have to move the acpi.h and
> acenv.h generation back into acpica5/Makefile and remove it from
> /usr/src/sys/Makefile.inc. The problem is that /usr/src/sys/Makefile.inc
> covers *everything* under sys and those acpica dependancies not only
> do not belong there, but the ../../.... paths won't be correct for many
> subdirectories under sys. This leads to make depend problems (amoung
> other things).
That's probably because you didn't specify -p to patch program:
$ zcat acpi-update.patch.gz | patch -d /sys -p0
Sorry that I didn't mention this in the previous mail.
> The second issue is the addition of dev/acpi. This seems to have taken
> over the build that used to be in acpica5. The build should really be
> in acpica5 with appropriate rearrangements to accomodate your new
> subdirectory structure (which I think is fine). Putting the build
> in dev/acpi creates a lot of confusion between dev/acpi and dev/acpica5.
The only reason that I created dev/acpi was so as I could
immitate /sys/modules/acpi tree in FreeBSD-CURRENT. Originally
I was planning to populate acpi submodule directories under
/sys/dev/acpica5 and use bsd.subdir.mk, but then, because of my
lack of knowledge, nothing in acpica5 was compiled. IMHO calling it
acpi is more intuitive than as acpica, but I'll try to rewrite the
patch as you suggested. I also considered moving freebsd acpi code
under /sys/contrib and keeping our local changes as patches, but
maybe it's a bit too far.
> I am also a bit unsure about the idle hook you added, but since acpica5
> is still experimental I think we can run with it until we find a better
> way.
>
> If you can fix those two issues and supply a new patch, I think it
> could be committed.
Too bad Nate has imported newer ACPI-CA code a few days after I posted
the patch...
討論串 (同標題文章)
完整討論串 (本文為第 5 之 15 篇)：