> 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: <[EMAIL PROTECTED]> (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*! ____ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
