[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] GNUMach 1.3 DMA Support
From: |
Alfred M. Szmidt |
Subject: |
Re: [patch] GNUMach 1.3 DMA Support |
Date: |
Thu, 16 Sep 2004 23:51:38 +0200 |
- Updates triton.c and hdreg.h to linux-2.0.40, for better support
of ALi controllers.
- Includes new PCIIDs (of known supported controllers) in ide.c
- Adds the flag "--enable-forcedma" to configure. The function
"config_drive_for_dma" of triton.c seems to be a bit old, and
doesn't detect DMA on drives that support it. This flag ignores
this detection. Enabling this could be dangerous for non-DMA or
very rare drives.
Wonderful! But can you do two small things? The first is to write a
ChangeLog entry (see the GNU Coding Standards, and the ChangeLog file
in the GNU Mach tree for details).
The second is the following bit of code:
diff -dur i386.orig/linux/configure i386/linux/configure
--- i386.orig/linux/configure 2001-05-27 14:44:22.000000000 +0200
+++ i386/linux/configure 2004-09-16 22:57:03.000000000 +0200
@@ -1788,6 +1788,16 @@
fi
fi
+if test "${enable_forcedma+set}" = set; then
+ enableval="$enable_forcedma"
+ if test "x$enableval" != xno; then
+cat >> confdefs.h <<\EOF
+#define CONFIG_BLK_DEV_FORCE_DMA 1
+EOF
+
+fi
+fi
+
fi
You shouldn't ever have to hack the configure script, it is generated
from a .in (Drivers.in in this case). So this change would be lost
the next time configure is regenerated. The correct way would be todo
something like (I don't know if this will actually work, so you need
to double check :) in Drivers.in at some approriate place:
AC_DRIVER(forcedma, CONFIG_BLK_DEV_FORCE_DMA, triton.o)
To regenerate i386/linux/configure you would do:
autoconf i386/linux/Drivers.in > i386/linux/configure
I haven't looked at the actual changes, but if they are sane then with
the above done, it should only be a matter of pokeing the Gods so that
they get of their asses to commit the patch.
Thanks!