Date: Sun, 01 Oct 2000 23:42:04 -0700 From: Mike Smith <msmith@freebsd.org> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch Message-ID: <200010020642.e926g4h00359@mass.osd.bsdi.com> In-Reply-To: Your message of "Mon, 02 Oct 2000 14:58:21 %2B0900." <20001002145821S.iwasaki@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
> source code.
> Mike, I'm feeling we need to have a migration plan. Do you have any
> plan on this?
I have an enormous patch that I can put up later tonight on Freefall.
I have the ACPICA 20000915 release fully integrated, and I've ported
their sample OSPM components just for fun (there are problems with these,
and I think we will only want them as examples). I also ported their
ACPI dump utility, but it's output is much uglier than ours.
The Intel code is clean, and the operating system interfaces are well
documented. I've mailed a promising contact at Intel to see how they
feel about accepting our changes.
There is still a lot of work to be done. I want to at least have one
sample acpi child device ready - I'll try converting their thermal
management OSPM component so that you can play with it. 8)
(There is a chicken-and-egg problem with their bus manager component and
the embedded controller support which means that I still have a hot
laptop. Grrr. 8)
> # I have to learn first before my participation to the discussion :-)
I hope that you will find ACPICA well documented. You should read the
developer's guide first, as it contains lots of very useful information.
> > > 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.
I think that it will be easier just to adapt existing code to the new
interfaces than to write a compatibility layer.
> > 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.
The additional terms are just Intel's legal department trying to make the
BSD license look big and scary. 8) We've talked to Intel about this same
license text in other contexts before; it is the same as the 4-clause BSD
license.
> > 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 :-)
Now *that* would be *nice*. 8)
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010020642.e926g4h00359>