> I don't think glibc is the source of the problem:
> 1) In-kernel stuff, kmod included, dosn't link against/use [g]libc --
> doing so would open a nice big curcular-logic hole. Libc should map
> user-space calling conventions to kernel conventions, so the kernel
> has no need of it. Also, you can't assume that the Linux kernel will
> be compiled on a Linux system -- otherwise, where can we compile it
> before we have Linux up and running?
> 2) Take a look at kmod.c -- it dosn't use any glibc headers anyway.
>
> If this change fixes the problem, then it is because the Alpha's
> sigfillset is broken -- possibly because it is defined as a struct of
> unsigned long sig[_NSIG_WORDS] instead of unsigned int sig[_NSIG_WORDS]?
> It would seem to me (with no experiance with non-ia32 processors, I
> should note) that we want somthing with sizeof(foo)==1, which is more
> likely int then long.
Well, this is what the kernel defines for sigfillset:
extern inline void sigfillset(sigset_t *set)
{
switch (_NSIG_WORDS) {
default:
memset(set, -1, sizeof(sigset_t));
break;
case 2: set->sig[1] = -1;
case 1: set->sig[0] = -1;
break;
}
}
I'm not used to seeing the 'default:' identifier placed first in a case
statement, but my K&R book is at work. Is this legal if we wish the other
cases to be considered? I always thought that the first lexical match won
out..
Given that _NSIG_WORDS == 1 in an alpha, then we either execute the
memset() operation (which looks exactly equivalent to what my hack does),
or set->sig[0] = -1. In the latter case, I assume that (int) -1 is
promoted to the equivalent value in (unsigned long) which _should_ also be
correct. Either I'm missing something very obvious (likely), or the
problem is subtle. Anyone?
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu