> > Yes, we can have large benefit by migrating to ACPICA. I suggest that
> > we make ACPICA version of AML interpreter run in userland as a
> > debugger for the first evaluation. By doing this work we can make
> > sure it works actually on FreeBSD and estimate the work volume of
> > kernel porting. Also we know the amldb is very useful from our
> > development experience.
> Indeed. I've just taken the hard path to start with, and got the kernel
> integration (mostly) resolved. Fortunately, the ACPICA code includes a
> complete user-space ACPI interpreter for just this purpose. I think some
> of their test code has rotted a bit (eg. their AcpiDump tool), but it
> shouldn't be too hard to get this going.
I and acpi-jp folks discussed ACPICA migration last night, there is no
objections so far. Most of them agreed that evaluation must be done
at least. Some people already started lerning ACPICA with documents and
Mike, I'm feeling we need to have a migration plan. Do you have any
plan on this?
# I have to learn first before my participation to the discussion :-)
> > Another suggestion is that this migration should be done prudently.
> > During ACPICA porting, we add ACPICA compatible wrappers to current
> > aml code (e.g. AcpiWalkNamespace() -> aml_apply_foreach_found_objects())
> > and modify acpi driver code so that we migrate to ACPICA smoothly.
> This would be very difficult.
OK, but I'll try, this will be my private project. I won't complain
anything if most of the code is deleted after migration. I hope I'll
get some understanding on ACPICA programming.
> > OK, before making our decision, I want to make sure something.
> > - Licence
> > Linux folks apply GPL for it. Is it possible to apply BSD style
> > licence for FreeBSD version of ACPICA? or should we put it sys/contrib?
> The Intel licence on the "generic Unix" version of ACPICA is suitable for
> direct inclusion in FreeBSD. I'm not sure that the Intel code shouldn't
> be in sys/contrib *anyway*.
I see. I found that we may have additional license terms, but I leave
it to your discretion.
> > - Support from Intel
> > My major concern is this one. I wonder whether our local changes
> > for ACPICA can feed back to original code. If not, maintenance will
> > become hard...
> If we do things right, we should have little trouble with this. We have
> some pretty good relations with the right parts of Intel, and as long as
> we keep the code changes clean, they should be happy to accept them.
> Given how much work the Intel people went through just to get their code
> into the Linux kernel, I think they will find us *much* more friendly. 8)
# Welcome new committers from Intel :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message