On 17-Jan-2003 Terry Lambert wrote: > John Baldwin wrote: >> > For Intel, this is a win-win. >> > >> > For FreeBSD, unless Windows adopts the same code (which it will >> > not do, since doing so will limit their market, just as using >> > the code is currently limiting FreeBSD's market), it's a lose-lose. >> >> Are you offering to write a new ACPI parser? If not, then put up or >> shut up. It's not exactly a trivial task. > > This was in the context of a discussion about what could be > done about the problem. It's really the original poster > you should be asking to write code. That's basically what > I was doing (asking him to write the code) by posting the > list of available options. > > I was under the impression that the Intel ACPI parser was > source code? > > So what we're really talking about here is taking over the > maintenance of, and forking, the Intel code, unless you think > Microsoft wrote their code from scratch...
I do think M$ wrote their code from scratch prior to the existence of the Intel ACPICA code. > In any case, for anything for which there is a specification, > was long as the specification is complete, implementation is > really pretty trivial. Haha, you are full of it if you say that. The _exact_ problem here is that M$'s ACPI interpreter is buggy and _doesn't_ follow the spec, and so BIOS writer's have hacked their AML's to work around the bugs in M$ interpreter. Thus, if you were to write an interpreter _to the spec_, you end up with what Intel has, and certain machines don't work with it. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
