On Fri, Jul 01, 2005 at 05:30:36PM +0100, David Goodenough wrote:
> On Friday 01 July 2005 11:42, A Mennucc wrote:
> > hi there
> >
> > I am very interested in patches for custom DSDT support (I own
> > an ASUS notebook which has a broken DSDT, so ACPI suspend does not work;
> > and there is a fixed DSDT in acpi.sf.net that I would love to try);
> >
> > I hope that they would accepted in Debian's shipped kernel
> > (see bug 251023).
> >
> > So I want to point a very important fact: the command /usr/sbin/mkinitrd
> > in Debian Sarge already supports those patches: at the end it
> > sports the lines
> >
> >
> > if [ -e /etc/mkinitrd/DSDT ]; then
> > echo -n "INITRDDSDT123DSDT123" >>${initrd_file}
> > cat /etc/mkinitrd/DSDT >>${initrd_file}
> > fi
> >
> > so the Debian user would just need to put the fixed DSDT in
> > /etc/mkinitrd/DSDT and it would be included in mkinitrd, and ....
> > (as soon as the patch is accepted in default Debian kernels)....
> > it would be loaded at startup: easy and clean.
> >
> > I guess that for the above mkinitrd snippet , we would need the patch
> > http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-patch-v0.7d-2.
> >6.9.patch (for kernel >= 2.6.9 ) and the patch
> > http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-
> >cleanup.patch (for kernel == 2.6.10 )
> >
> > Unfortunately this last patch fails on the standard kernel in Sarge, that
> > is 2.6.8 ... I will need to look into it ..
> >
> > a.
>
> I agree that this would be useful. When I raised it several months ago
> I was told that this INITRD method was not the prefered route in the
> kernel currently as they prefer the route of statically linking the DSDT
> into the kernel. I think this is daft as most people do not want to get
> involved in building kernels. Actually I think that while this method is
> better than a whole kernel build that really the best solution would be
> to modify the kernel and LILO/GRUB/whatever_boot_loader to take a
> file name for the DSDT and then all that is needed is to create the
> file - much easier for Joe User.
I imagine this followed from not wanting to include the code in question
in the debian kernel, which in turn I would guess boils down to either or
both of the following:
1. The Debian kernel doesn't add patches that aren't upstream.
2. The Debian kernel can only include DFSG free code.
And I imagine the road to finding a solution that doesn't completely
suck for users, has to keep both of these points in mind. On the
other hand, I haven't checked the code in question, and both of
these points may be invalid.
> The problem obviously is that this has to be done VERY early in the
> kernel boot process so no solution is going to be trivial, but it must
> be as easy as possible for Joe User as many laptops have these
> problems.
--
Horms
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
