Re: daemon-less kmod & Alpha no-go!

Andreas Schwab (schwab@issan.informatik.uni-dortmund.de)
22 Apr 1998 14:25:55 +0200


Steven N Hirsch <shirsch@ibm.net> writes:

|> On Tue, 21 Apr 1998, James Mastros wrote:

|>> 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.

If you want sizeof(foo) == 1 then foo should be char.

|> 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..

You can place the labels anywhere you like. Since all case labels must
have unique values there is no ambiguity.

|> 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?

I see nothing that prevents this piece of code working on alpha.
Everything is completely defined within the C standard.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu