Re: daemon-less kmod & Alpha no-go!
James Mastros (root@jennifer-unix.dyn.ml.org)
Tue, 21 Apr 1998 21:33:10 -0400 (EDT)
(note: cc's cleaned out -- only linux-kernel now)
On Tue, 21 Apr 1998, Steven N. Hirsch wrote:
> I've found the underlying problem with daemonless 'kmod' on Alpha.
> Apparently, glibc header changes are to blame. I became suspicious after
> noticing that kmod is compiled with __KERNEL__ defined. Turns out to be a
> kernel vs. user space disagreement as to the storage type and size of
> sigset_t.
>
> The following quick hack brings kmod to life:
[reformated]
> the signal just right.
> */
> spin_lock_irq(¤t->sigmask_lock);
> - sigfillset(¤t->blocked);
> + memset (¤t->blocked, '\0xff', sizeof(current->blocked));
>
[...]
> I get dizzy trying to figure out who is getting which prototype from
> where, but maybe someone intimately familiar with the new glibc headers
> can suggest a cleaner fix?
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.
> Enjoy.
>
> Steve
--
Where do you want to go today?
We might support that sometime next year.
-=- Microsoft
(But I doubt it.)
-=- Me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu