Date: Mon, 02 Oct 2000 14:58:21 +0900 From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> To: msmith@freebsd.org Cc: iwasaki@jp.FreeBSD.org, 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: <20001002145821S.iwasaki@jp.FreeBSD.org> In-Reply-To: <200010012007.e91K7Sh03718@mass.osd.bsdi.com> References: <20001001220452O.iwasaki@jp.FreeBSD.org> <200010012007.e91K7Sh03718@mass.osd.bsdi.com>
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 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. OK. > 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 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?20001002145821S.iwasaki>