Re: IRC log
OK, here's what I think is happening.
X is working around a changed type in kd.h by #define rate period.
Then there's something in kbio.h which uses rate.
I don't see this as a kernel headers bug. Fix the rates to be periods
properly. Or do something like
#if defined(LINUX_VERSION_CODE) && defined(KERNEL_VERSION)
# if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,42)
# define kd_rate period
# else
# define kd_rate rate
# endif
#else
# define kd_rate rate
#endif
And then change the appropriate "rate" accesses to "kd_rate". The two
structures are different. I bet the latter rate really IS a rate, not
a period.
On Thu, Jan 08, 2004 at 03:52:46AM +0000, James Troup wrote:
> Nov 14 20:21:18 <elmo> !drow: could someone offhandly tell if the X build failure[1] is likely to be because of a missing update to l-k-h on sparc or
> more likely in X?
> Nov 14 20:23:10 <elmo> [1] http://buildd.debian.org/build.php?arch=sparc&pkg=xfree86&ver=4.2.1-14
> Nov 14 20:23:34 <elmo> or rather http://buildd.debian.org/fetch.php?&pkg=xfree86&ver=4.2.1-14&arch=sparc&stamp=1068838893&file=log&as=raw (large link)
> Nov 14 20:25:58 <pb_> the latter, I think. though I thought Branden included a patch for that very issue in -14.
> Nov 14 20:26:38 <elmo> err, actually, looking at #220814, I think it's the former?
> Nov 14 20:26:39 <pb_> the kernel h4x0rs renamed the "rate" member in struct kbd_repeat to "period" in 2.6.
> Nov 14 20:27:29 <pb_> well, it's not a missing update as such. I don't think we intended to revert that particular change from the kernel.
> Nov 14 20:27:44 <elmo> right, but err, am I on smack, or isn't X looking for period and not finding it on sparc?
> Nov 14 20:27:56 <pb_> oh, duh, you're right.
> Nov 14 20:28:06 <elmo> tho, I'm not sure why, I can see:
> Nov 14 20:28:18 <elmo> vore:/# grep period /usr/include/linux/kd.h
> Nov 14 20:28:18 <elmo> int period; /* in msec; <= 0: don't change */
> Nov 14 20:28:28 <elmo> /* earlier this field was misnamed "rate" */
> Nov 14 20:29:06 <pb_> do you still have the build tree around? could run the failing file through gcc -E and see where it's getting the struct from.
> Nov 14 20:29:25 <pb_> maybe sparc has its own private copy of kd.h in some special place.
> Nov 14 20:29:39 <elmo> I can't see it from a grep, but good plan
> Nov 14 20:30:56 <elmo> hmm, I always get the -d<foo> options confused
> Nov 14 20:32:55 <elmo> wah
> Nov 14 20:33:05 <elmo> gcc -E shows kbd_repeat with period defined
> Nov 14 20:34:15 <elmo> kbdrate_s.rate = (rate + 5) / 10; /* must be integer, so round up */
> Nov 14 20:34:18 * elmo goes insane
> Nov 14 20:34:48 <pb_> freaky
> Nov 14 20:35:07 <elmo> * Fix building against 2.6.x kernel headers by adding '#define rate period'
> Nov 14 20:35:07 <elmo> where needed; fixes FTBFS when linux-kernel-headers package installed.
> Nov 14 20:35:10 <elmo> jesus that's dubious
> Nov 14 20:35:46 <elmo> +/* Deal with gratuitous kernel header change */
> Nov 14 20:35:46 <elmo> +#if defined(LINUX_VERSION_CODE) && defined(KERNEL_VERSION)
> Nov 14 20:35:46 <elmo> +# if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,42)
> Nov 14 20:35:46 <elmo> +# define rate period
> Nov 14 20:40:32 <drow> try -dD and grep for rate\|period
> Nov 14 20:41:42 <elmo> -dD doesn't seem to do much ?
> Nov 14 20:41:49 <elmo> oh, cpp
> Nov 14 20:41:52 <elmo> sorry :/
> Nov 14 20:42:39 <elmo> aha
> Nov 14 20:42:49 <elmo> /usr/include/asm-sparc/kbio.h is the culprit
> Nov 14 20:42:58 <elmo> struct kbd_rate {
> Nov 14 20:42:58 <elmo> unsigned char delay; /* Delay in Hz before first repeat. */
> Nov 14 20:42:58 <elmo> unsigned char rate; /* In characters per second (0..50). */
> Nov 14 20:42:58 <elmo> };
> Nov 14 20:44:17 * elmo wonders why he didn't see that in the grep.. ah.. helps if you grep in the right chroot
> Nov 14 20:44:44 <pb_> ah, that old problem.
> Nov 14 20:45:36 <elmo> so, hmm, which would be the preferred fix? make it match or remove
> Nov 14 20:46:24 <elmo> or c) leave it to someone who knows what they're doing.. ;) anyway, work, bbiab
>
> --
> James
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: