Bug#251023: upstream status of acpi-dsdt-initrd patch

[Oleg Verych <olecom@flower.upol.cz>]

> From: dann frazier
> Newsgroups: gmane.linux.debian.devel.kernel
> Subject: Bug#251023: upstream status of acpi-dsdt-initrd patch
> Date: Sat, 24 Mar 2007 14:53:58 -0600
>
> hey,
>  I did a little research this morning to try to formulate an opinion -
> here's what I found:[...]

A little bit outdated, i'd say.

> I also wonder if ACPI upstream would re-consider including this patch
> if DSDT-tainting was implemented?[...]

>From legal to technical sides of the question, fresh one is below:

Newsgroups: gmane.linux.kernel
From: Ben Collins
Message-ID: <1164998179.5257.953.camel@gullible>

(if you're lazy to find and read whole thread, and using
pretty-brain-damaging-webbrowser :) here are some key points:

<http://permalink.gmane.org/gmane.linux.kernel/471868>
<http://permalink.gmane.org/gmane.linux.kernel/472440>
<http://permalink.gmane.org/gmane.linux.kernel/471936>
<http://permalink.gmane.org/gmane.linux.kernel/471999>
<http://permalink.gmane.org/gmane.linux.kernel/472076>

As for me, technical reasoning is mostly from the-kernel-developer:

knowing, how request_firmware() ugly (from userspace _and_ in-kernel
implementation points of view), suggestion to use vmlinuz && objcopy
(with ACPI_CUSTOM_DSDT) is rather the same as initrd patch (see last
link).

Only thing i agree, is multiple ugly hacks to have in mainstream, just to
load yet another bin-blob in the right place in the right time.

Thus, pushing BIOS updates is the only plausible way. Maybe those
pro-Intel-ACPI dudes finaly got one ACPI-standard ACPI-BIOS-updating
ACPI-interface, one can hack for all UNIX-like OSes.

While Dell pushed it in "Firmware Drivers" in the kernel, Intel have its
microcode updates there. *Sigh*!
____