Date: Sun, 01 Oct 2000 13:07:28 -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: <200010012007.e91K7Sh03718@mass.osd.bsdi.com> In-Reply-To: Your message of "Sun, 01 Oct 2000 22:04:52 %2B0900." <20001001220452O.iwasaki@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > PowerResource code keeps pointers to the PowerResource objects, then
> > > finds a pointer to methods of the object dynamically. Can we do it in
> > > similar way for thermal management?
> >
> > Well, yes, but you have to go back and re-parse the actual AML. I'm not
> > even sure if it's safe to assume that the thermal zone is in the same
> > place in the bytecode (it should be, I guess).
>
> I also think it shoud be...
/me crosses his fingers
> > I went reading through the ACPICA documentation to work this out. They
> > acually have a very nice technique where they attach the I/O handlers to
> > a point in the namespace, and then when something attempts I/O, they
> > travel back up the namespace to the root, looking for the first matching
> > I/O handler.
> >
> > This means that when your EC driver finds an embedded controller, you
> > just attach your I/O handler to the EC object. Then anytime someone
> > tries to do I/O to the EC, your handler gets called.
>
> 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.
> 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.
> BTW, last time Watanabe-san tried to write EC stuff, but unfortunately
> his laptop was broken *twice* by testing.
> Be careful, otherwise your Dell will go to the hospital 8)
Ack. I'll bear that in mind.
> > Hmm. I guess I should spend some more time looking at this. I don't
> > mean to devalue all the work that's been put into the current AML code,
> > but ACPICA has already solved a lot of the problems that we haven't even
> > touched yet (Notify, locking, etc...)
>
> 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*.
> - 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)
--
... 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?200010012007.e91K7Sh03718>