NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/linux/21298

Text File | 1992-12-22 | 2.0 KB | 40 lines

Newsgroups: comp.os.linux
From: [e-mail] (Jim Segrave)
Path: sparky!uunet!pipex!demon!grendel.demon.co.uk!jes
Subject: Re: IMPORTANT [BUG in 0.99] Re: [ANNOUNCE]: linux version 0.99
Keywords: kernel linux 0.99
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Segrave Software Services
Date: Sun, 20 Dec 1992 20:41:14 +0000
Message-ID: <[e-mail]>
Sender: [e-mail]
Lines: 27

In article <[e-mail]> [e-mail] (Lars Wirzenius) writes:
>In normal C programs, yes, but the kernel is a bit special.  Like, for
>instance, who is going to do the initialization?  Normally it is the
>kernel (which zeroes out all memory before it is given to a user
>process), the linker (which loads the pre-initialized variables from a
>file, i.e. those variables which are given an explicit initializer),
>and possbily the C startup code.  Trouble is, none of these are active
>when the kernel is booting...

Hmm... Obviously data with explicit initialisers is getting loaded from the
kernel image (I'm sure gcc doesn't generate startup code to individually
initialise static data). And I assume that the size of the kernel - code,
initialised data, and uninitialised statics is available at the a.out
stage. Shouldn't there be some way for setup.S to determine the size of
the uninitialised data area and have it zero this out (which is adequate,
since gcc's version of a NULL pointer is all bits zero)?

It's not a major issue, but if you're used to programming in C, I think
you may tend to assume that all statics are set to the apporpriate form
of zero, so I could see kernel hackers getting caught on this more than
once in the future. I just sort of assumed that the kernel did some
sort of a memset to the end of it's data area when it loaded, hence my
query.

--
Jim Segrave - Segrave Software Services       ([e-mail])