Darryl Miles writes:
> Hmm, what about common symbol generation? i.e. the linker looses the
> ability to throw out "multiply defined symbol" errors where you fail
> to initialise it to a value.
We need to build with -fno-common to be 100% safe in this case. I'll
run several compilations with th
Russell King <[EMAIL PROTECTED]> writes:
>The only difference is the size on disk; if we go around setting every
>bss variable to zero, the kernel/module data size will unnecessarily
>huge.
Hmm, what about common symbol generation? i.e. the linker looses the
ability
to throw out "multiply defin
On Wed, 29 Nov 2000, Peter Samuelson wrote:
> It would probably also be reasonable to document it and provide an
> option to switch it off.
yes, that is perfectly fine by me. Now, who is going to do the _work_? :)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux
[Tigran Aivazian <[EMAIL PROTECTED]>]
> no, I was not talking about ISO C standards but about the normal
> expected C environment under any UNIX. I guess, we just mean
> different things by "trivially equivalent" since neither of us said
> anything about what that actually meant. What I meant by
Albert D. Cahalan writes:
> Oh, bullshit. We break the C standard left and right already.
> This is the kernel, and the kernel can initialize BSS any damn
> way it feels like initializing it. The kernel isn't ever going
> to be standard C.
>
> Choosing an initializer that tends to catch unintende
On Tue, 28 Nov 2000, Peter Samuelson wrote:
> [Tigran Aivazian]
> > First, they are not trivially equivalent. In fact, they are not
> > equivalent at all. Any good C book should tell you that one places
> > data in "data segment" and another in "bss segment" (with a footnote
> > explaining histor
[Keith Owens]
> Binary patches against bss on disk cannot work, there is nothing to
> patch.
OK, me dumkopf.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Tue, 28 Nov 2000 17:53:48 -0600,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>Binary patching? If you are binary patching something you need to get
>the exact location, one way or another. Whatever tool you use to
>extract the location of a symbol in an object file, that same tool
>should tel
[Albert D. Cahalan]
> Choosing an initializer that tends to catch unintended reliance on
> zeroed data would be good. Too bad it is too late to fix.
Why would that be good? Why is it bad to accidentally rely on zeroed
data, if the data is in fact guaranteed to be zeroed? It's not like
this is
Russell King writes:
> Albert D. Cahalan writes:
>> It is too late to fix things now. It would have been good to
>> have the compiler put explicitly zeroed data in a segment that
>> isn't shared with non-zero or uninitialized data, so that the
>> uninitialized data could be set to 0xfff00fff to c
[Tigran Aivazian]
> First, they are not trivially equivalent. In fact, they are not
> equivalent at all. Any good C book should tell you that one places
> data in "data segment" and another in "bss segment" (with a footnote
> explaining historical meaning of "block started by symbol")
Do you ha
On Tue, 28 Nov 2000, David Hinds wrote:
> I would contend that it is a compiler bug in gcc if it treats the two
> statements differently, since they are trivially equivalent. I guess
> that it has been decided that linux kernel coding style dictates no
> zero initializers, so that's that. Person
> What information is lost? Unless you're working on a really strange
> machine which does not zero bss, the following means the same from the
> codes point of view:
>
> static int foo = 0;
> static int foo;
I think the argument is that "static int foo;" implies you don't
actually care how "foo"
On Tue, Nov 28, 2000 at 05:09:48PM +0100, Andreas Schwab wrote:
> including the Linux kernel. :-)
As it's a worthless extension it's always trivial to fixup after its removal :).
The fixup also shown that the sis_300 and sis_301 driver would break if used at
the same time (probably unlikely to h
On Tue, Nov 28, 2000 at 04:16:12PM +0100, Andrea Arcangeli wrote:
> On Tue, Nov 28, 2000 at 10:55:06AM +0100, Andreas Schwab wrote:
> > Alexander Viro <[EMAIL PROTECTED]> writes:
> >
> > |> On Tue, 28 Nov 2000, Andrea Arcangeli wrote:
> > |>
> > |> > On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EM
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
|> On Tue, Nov 28, 2000 at 10:55:06AM +0100, Andreas Schwab wrote:
|> > Alexander Viro <[EMAIL PROTECTED]> writes:
|> >
|> > |> On Tue, 28 Nov 2000, Andrea Arcangeli wrote:
|> > |>
|> > |> > On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED]
On Tue, Nov 28, 2000 at 10:55:06AM +0100, Andreas Schwab wrote:
> Alexander Viro <[EMAIL PROTECTED]> writes:
>
> |> On Tue, 28 Nov 2000, Andrea Arcangeli wrote:
> |>
> |> > On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote:
> |> > > If you have two files:
> |> > > test1.c:
> |> >
On Tue, Nov 28, 2000 at 02:19:23PM +1100, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you write:
> > On Thu, Nov 23, 2000 at 10:01:53PM +1100, Rusty Russell wrote:
> > > What irritates about these monkey-see-monkey-do patches is that if I
> > > initialize a variable to NULL, it's because
Andrea Arcangeli <[EMAIL PROTECTED]> said:
> On Mon, Nov 27, 2000 at 02:34:45PM -0500, Richard B. Johnson wrote:
> > The following shell-script shows that gcc-2.8.1 produces code with
> > data allocations adjacent. However, they are reversed!
> same with 2.95.* :).
The point was if gcc did use t
Alexander Viro <[EMAIL PROTECTED]> writes:
|> On Tue, 28 Nov 2000, Andrea Arcangeli wrote:
|>
|> > On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote:
|> > > If you have two files:
|> > > test1.c:
|> > > int a,b,c;
|> > >
|> > > test2.c:
|> > > int a,c;
|> > >
|> > > Which is _s
On Mon, Nov 27, 2000 at 10:35:45PM -0500, Alexander Viro wrote:
>
>
> On Tue, 28 Nov 2000, Andrea Arcangeli wrote:
>
> > On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote:
> > > If you have two files:
> > > test1.c:
> > > int a,b,c;
> > >
> > > test2.c:
> > > int a,c;
> > >
>
On Tue, 28 Nov 2000, Andrea Arcangeli wrote:
> On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote:
> > If you have two files:
> > test1.c:
> > int a,b,c;
> >
> > test2.c:
> > int a,c;
> >
> > Which is _stronger_?
>
> Those won't link together as they aren't declared static.
T
On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote:
> If you have two files:
> test1.c:
> int a,b,c;
>
> test2.c:
> int a,c;
>
> Which is _stronger_?
Those won't link together as they aren't declared static.
If they would been static they could be ordered file-per-file (note: I'
On Mon, Nov 27, 2000 at 02:34:45PM -0500, Richard B. Johnson wrote:
> The following shell-script shows that gcc-2.8.1 produces code with
> data allocations adjacent. However, they are reversed!
same with 2.95.* :).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
[Tigran Aivazian]
> _BUT_ never let this to be a default option, please. Because there
> are valid cases where a programmer things "this is in .data" and that
> means this should be in .data.
If you are writing the sort of code that cares which section it ends up
in, you need to use __attribute
[EMAIL PROTECTED] (H. Peter Anvin) wrote on 26.11.00 in
<8vrstp$o7d$[EMAIL PROTECTED]>:
> The problem is that it doesn't. One could argue this is a gcc bug or
> rather missed optimization.
>
> One can, of course, also write:
>
> static int a /* = 0 */;
>
> ... to make it clear to human pro
Albert D. Cahalan writes:
> It is too late to fix things now. It would have been good to
> have the compiler put explicitly zeroed data in a segment that
> isn't shared with non-zero or uninitialized data, so that the
> uninitialized data could be set to 0xfff00fff to catch bugs.
> It would take m
[EMAIL PROTECTED] (Michael Meissner) writes:
> On Mon, Nov 27, 2000 at 06:21:13PM +0100, Andrea Arcangeli wrote:
> > On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> > > Also I believe linkers are allowed to arbitrarily reorder members in
> > > the data and bss sections. I coul
Andries Brouwer writes:
> Do I explain things so badly? Let me try again.
> The difference between
>
> static int a;
>
> and
>
> static int a = 0;
>
> is the " = 0". The compiler may well generate the same code,
> but I am not talking about the compiler. I am talking about
> the programme
On Mon, 27 Nov 2000, Andrea Arcangeli wrote:
> On Mon, Nov 27, 2000 at 12:36:55PM -0500, Michael Meissner wrote:
> > wrong to depend on two variables winding up in at adjacent offsets.
>
> I'd like if it will be written explicitly in the specs that it's forbidden to
> rely on that. I grepped the
On Mon, Nov 27, 2000 at 12:36:55PM -0500, Michael Meissner wrote:
> wrong to depend on two variables winding up in at adjacent offsets.
I'd like if it will be written explicitly in the specs that it's forbidden to
rely on that. I grepped the specs and I didn't find anything. So I wasn't sure
if I
On Mon, 27 Nov 2000, Andrea Arcangeli wrote:
> On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> > Also I believe linkers are allowed to arbitrarily reorder members in
> > the data and bss sections. I could be wrong on this one though.
>
> I'm not sure either, but we certainly
On Mon, Nov 27, 2000 at 09:41:39AM +0100, Werner Almesberger wrote:
> Adam J. Richter wrote:
> > At the moment, I have started daydreaming about instead
> > writing an "elf squeezer" to do this and other space optimizations
> > by modifying objdump.
>
> Hmm, this would require that gcc never
On Mon, Nov 27, 2000 at 06:21:13PM +0100, Andrea Arcangeli wrote:
> On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> > Also I believe linkers are allowed to arbitrarily reorder members in
> > the data and bss sections. I could be wrong on this one though.
>
> I'm not sure eithe
On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> Also I believe linkers are allowed to arbitrarily reorder members in
> the data and bss sections. I could be wrong on this one though.
I'm not sure either, but we certainly rely on that behaviour somewhere.
Just to make an exampl
Andries Brouwer wrote:
>
> On Sun, Nov 26, 2000 at 09:11:18AM +1100, Herbert Xu wrote:
>
> > No information is lost.
>
> Do I explain things so badly? Let me try again.
> The difference between
>
> static int a;
>
> and
>
> static int a = 0;
>
> is the " = 0". The compiler may well gene
David S. Miller wrote:
> There is no guarentee that contiguous data or bss section members
> will appear contiguous and in the same order, in the final object.
That's a different issue and actually okay in this case.
What I meant to show is an example where the compiler happens to
allocate the v
Date: Mon, 27 Nov 2000 09:41:39 +0100
From: Werner Almesberger <[EMAIL PROTECTED]>
egcs-2.91.66 indeed doesn't seem to make this optimization on i386.
(Maybe the pointer increment or pointer offset solution would
actually be slower - didn't check.) But I'm not sure if this is
Adam J. Richter wrote:
> At the moment, I have started daydreaming about instead
> writing an "elf squeezer" to do this and other space optimizations
> by modifying objdump.
Hmm, this would require that gcc never calculates the location of an
explicitly initialized static variable based on
Michael Meissner wrote:
>On Sat, Nov 25, 2000 at 11:55:11PM +, Tim Waugh wrote:
>> On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:
>>
>> > Which is silly. The variable is explicitly defined to be zero
>> > anyway, whether you put this in your code or not.
>>
>> Why doesn'
On Sat, Nov 25, 2000 at 11:55:11PM +, Tim Waugh wrote:
> On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:
>
> > Which is silly. The variable is explicitly defined to be zero
> > anyway, whether you put this in your code or not.
>
> Why doesn't the compiler just leave out e
Elmer Joandi wrote:
>
> Nice to see again a two cutting-edge-killing opinions.
>
> Every time I really wonder, how such brilliant hackers can be that stupid
> that they can not have cake and eat it the same time, and have to scratch
> each-others eyes every time.
>
> Use macros.
>
> Kernel has
Hi!
> Sorry, John, I _have_ to [give good example to others]. The above says
> that _you_ my dear friend, do not know where the BSS clearing code is. It
> is not in setup.S. It is not even in the same directory, where setup.S is.
> It is in arch/i386/kernel/head.S, starting from line 120:
>
> /*
Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> That isnt what Andries is arguing about. Read harder. Its semantic differences
> rather than code differences.
>
> static int a=0;
>
> says 'I thought about this. I want it to s
On Sun, 26 Nov 2000, Alexander Viro wrote:
> I would suggest you to read through the following book and files:
> * Kernighan & Pike, "The Practice of Programming"
> * Documentation/CodingStyle
> * drivers/net/aironet4500_proc.c
> and consider, erm, discrepancies. On the second
On Sun, 26 Nov 2000, Elmer Joandi wrote:
>
> Kernel has become so big that it really needs universal debugging macros
> instead of comments. Comments are waste of brain&fingerpower, if the same
> can be explained by long variable names and debug macros.
>
> static Subsystem_module_LocalVaria
Nice to see again a two cutting-edge-killing opinions.
Every time I really wonder, how such brilliant hackers can be that stupid
that they can not have cake and eat it the same time, and have to scratch
each-others eyes every time.
Use macros.
Kernel has become so big that it really needs univ
> "AC" == Alan Cox <[EMAIL PROTECTED]> writes:
AC> Sure it generates the same code
If you accept that code == .text, as do I, then there is no code
generated for either of the forms being argued.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
Is there some reason why gcc does not put static data that
is explicitly initialized to zero in .bss? If not, then fixing
gcc would provide more space savings than these patches, and
improve more software than just the Linux kernel.
Adam J. Richter __ __ 4880 Steven
On Sun, Nov 26, 2000 at 10:37:07AM +, Tigran Aivazian wrote:
> On Sat, 25 Nov 2000, Tim Waugh wrote:
> > Why doesn't the compiler just leave out explicit zeros from the
> > 'initial data' segment then? Seems like it ought to be tought to..
>
> yes, taught to, _BUT_ never let this to be a def
On Sun, Nov 26, 2000 at 10:52:05AM +, Tigran Aivazian wrote:
> that _you_ my dear friend, do not know where the BSS clearing code is. It
> is not in setup.S. It is not even in the same directory, where setup.S is.
> It is in arch/i386/kernel/head.S, starting from line 120:
On a related note,
On Sun, Nov 26, 2000 at 04:25:05AM +, Alan Cox wrote:
> static int a=0;
>
> says 'I thought about this. I want it to start at zero. I've written it this
> way to remind of the fact'
>
> Sure it generates the same code
I agree it would be best if gcc would generate the same code; unfo
John Alvord wrote:
> On Sun, 26 Nov 2000 04:25:05 + (GMT), Alan Cox
> <[EMAIL PROTECTED]> wrote:
>
> >> AB> of changes that yield a negligable advantage and reduce stability
> >> AB> a tiny little bit. That is pushing Linux in the direction of this
> >> AB> abyss. You notice that the view
On Sun, 26 Nov 2000, John Alvord wrote:
> It also says "I do not know much about the details of the kernel C
> environment. In particular I do not know that all static variables are
> initialized to 0 in the kernel startup. I have not read setup.S."
On Sun, 26 Nov 2000, John Alvord wrote:
> It also says "I do not know much about the details of the kernel C
> environment. In particular I do not know that all static variables are
> initialized to 0 in the kernel startup. I have not read setup.S."
John, please stop insulting Andries, you would
On Sat, 25 Nov 2000, Tim Waugh wrote:
> On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:
>
> > Which is silly. The variable is explicitly defined to be zero
> > anyway, whether you put this in your code or not.
>
> Why doesn't the compiler just leave out explicit zeros from t
Andries Brouwer writes:
> Oh, please - something is wrong with your reading comprehension.
> Don't you understand the word "irrelevant"? It means that the
> initial value does not matter. It does not mean undefined.
> Please reread my letter and comment when you understand my point.
So now you tr
Hi Andries!
> All these really good people, unable to capture a simple idea.
> Let me try one more time.
> There is information. The information is:
> "this variable needs initialization"
> Now you tell me to know simple rules. OK, I know them.
> But what do they tell me about my variables
On Sun, 26 Nov 2000, Keith Owens wrote:
> >Are you positive for modules too...
>
> Yes.
I know this, I am being punchy.
Cheers,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
On Sat, 25 Nov 2000 21:10:19 -0800 (PST),
Andre Hedrick <[EMAIL PROTECTED]> wrote:
>On Sun, 26 Nov 2000, John Alvord wrote:
>> It also says "I do not know much about the details of the kernel C
>> environment. In particular I do not know that all static variables are
>> initialized to 0 in the ke
Andries Brouwer wrote:
> On Sat, Nov 25, 2000 at 10:27:15PM +, Tigran Aivazian wrote:
I think it's a bad sign if people like the two of you start flaming
each other ...
On the issue of static int foo = 0; vs. static int foo; I'd agree
with Andries' view. It's a common enough idiom that i
On Sun, 26 Nov 2000, John Alvord wrote:
> On Sun, 26 Nov 2000 04:25:05 + (GMT), Alan Cox
> <[EMAIL PROTECTED]> wrote:
>
> >> AB> of changes that yield a negligable advantage and reduce stability
> >> AB> a tiny little bit. That is pushing Linux in the direction of this
> >> AB> abyss. You
On Sun, 26 Nov 2000 04:25:05 + (GMT), Alan Cox
<[EMAIL PROTECTED]> wrote:
>> AB> of changes that yield a negligable advantage and reduce stability
>> AB> a tiny little bit. That is pushing Linux in the direction of this
>> AB> abyss. You notice that the view gets better, and I get nervous.
> AB> of changes that yield a negligable advantage and reduce stability
> AB> a tiny little bit. That is pushing Linux in the direction of this
> AB> abyss. You notice that the view gets better, and I get nervous.
>
> Can somebody stop this train load of bunk?
>
> Uninitialized global variabl
On Sat, 25 Nov 2000, Tim Waugh wrote:
>
> On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:
>
> > Which is silly. The variable is explicitly defined to be zero
> > anyway, whether you put this in your code or not.
>
> Why doesn't the compiler just leave out explicit zeros from
> "AB" == Andries Brouwer <[EMAIL PROTECTED]> writes:
AB> No insult intended. It is just that if there is an abyss
AB> somewhere, I like to stay at least a meter away from it. Someone
AB> else may think that one inch suffices. I see you propose a lot
AB> of changes that yield a negligab
On Sat, Nov 25, 2000 at 06:02:51PM -0500, Jeff Garzik wrote:
> Andries Brouwer wrote:
> > In a program source there is information for the compiler
> > and information for the future me. Removing the " = 0"
> > is like removing comments. For the compiler the information
> > remains the same. For t
On Sat, Nov 25, 2000 at 10:27:15PM +, Tigran Aivazian wrote:
: Hello Andries,
Hi Tigran,
: ... I am quite free to _rely_ on this fact and will possibly do so.
Yes, you are. But some programmers have learned that it is a good
idea to code in a way that is informative to the programmer.
: >
On Thu, 23 Nov 2000, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you write:
> > > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > Quick removal of unnecessary initialization to 0.
> >
> > Quite the contrary. The patch seems correct and useful to me. What
On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:
> Which is silly. The variable is explicitly defined to be zero
> anyway, whether you put this in your code or not.
Why doesn't the compiler just leave out explicit zeros from the
'initial data' segment then? Seems like it ough
On Sat, Nov 25, 2000 at 11:46:24PM +0100, Andries Brouwer wrote:
>
> But if the program
>
> static int a = 0;
>
> int main() {
> /* do something */
> }
>
> is used as part of a larger program, it has to become
>
> static int a;
>
> int do_something() {
> a = 0;
>
Andries Brouwer wrote:
> In a program source there is information for the compiler
> and information for the future me. Removing the " = 0"
> is like removing comments. For the compiler the information
> remains the same. For the programmer something is lost.
This is pretty much personal opinion
On Sat, 25 Nov 2000, Andries Brouwer wrote:
> On Sun, Nov 26, 2000 at 09:11:18AM +1100, Herbert Xu wrote:
>
> > No information is lost.
>
> Do I explain things so badly? Let me try again.
> The difference between
>
> static int a;
>
> and
>
> static int a = 0;
>
> is the " = 0". The comp
On Sun, Nov 26, 2000 at 09:11:18AM +1100, Herbert Xu wrote:
> No information is lost.
Do I explain things so badly? Let me try again.
The difference between
static int a;
and
static int a = 0;
is the " = 0". The compiler may well generate the same code,
but I am not talking about the com
Hello Andries,
On Sat, 25 Nov 2000, Andries Brouwer wrote:
> What a strange reaction. If I write
>
> static int foo;
>
> this means that foo is a variable, local to the present compilation unit,
> whose initial value is irrelevant because it will be assigned to before use.
> If I write
>
> s
Andries Brouwer <[EMAIL PROTECTED]> wrote:
>
> int foo = 0; /* just for gcc */
> when the initialization in fact is not necessary.
Only for non-static foo.
> It is a bad programming habit to depend on this zero initialization.
> Indeed, very often, when you have a program that does something
On Sat, Nov 25, 2000 at 09:07:08PM +, Russell King wrote:
> Andries Brouwer writes:
> > What a strange reaction. If I write
> >
> > static int foo;
> >
> > this means that foo is a variable, local to the present compilation unit,
> > whose initial value is irrelevant
>
> Wrong. The initi
Andries Brouwer writes:
> What a strange reaction. If I write
>
> static int foo;
>
> this means that foo is a variable, local to the present compilation unit,
> whose initial value is irrelevant because it will be assigned to before use.
Wrong. The initial value is well-defined. Go and read
On Sat, Nov 25, 2000 at 11:50:20AM +, Russell King wrote:
> Rusty Russell writes:
> > What irritates about these monkey-see-monkey-do patches is that if I
> > initialize a variable to NULL, it's because my code actually relies on
> > it; I don't want that information eliminated.
>
> What info
Rusty Russell writes:
> What irritates about these monkey-see-monkey-do patches is that if I
> initialize a variable to NULL, it's because my code actually relies on
> it; I don't want that information eliminated.
What information is lost? Unless you're working on a really strange
machine which
J . A . Magallon writes:
> ANSI rules for C say that uninitialized vars get a 0, but you can't trust
> on the ANSI behaviour of a compiler.
It has nothing to do with the compiler, but everything to do with the
C startup code. In the Linux kernel, we have complete control over the
C startup code
On Thu, 23 Nov 2000 12:01:53 Rusty Russell wrote:
>
> What irritates about these monkey-see-monkey-do patches is that if I
> initialize a variable to NULL, it's because my code actually relies on
> it; I don't want that information eliminated.
>
What I understood from the previous answer from
On Thu, Nov 23, 2000 at 10:01:53PM +1100, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you write:
> > > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > Quick removal of unnecessary initialization to 0.
> >
> > Quite the contrary. The patch seems correct and
In message <[EMAIL PROTECTED]> you write:
> > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > >
> > > Quick removal of unnecessary initialization to 0.
>
> Quite the contrary. The patch seems correct and useful to me. What do you
> think is wrong with it? (Linus accepted megaby
J . A . Magallon writes:
> On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > -static int basePort = 0; /* base port address */
> > -static int regPort = 0;/* port for register number */
> > -static int dataPort = 0; /* port for register data */
> > +static int baseP
"J . A . Magallon" wrote:
> On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > -static int dataPort = 0; /* port for register data */
> > +static int dataPort; /* port for register data */
>
> That is not too much confidence on the ANSI-ness of the compiler ???
There is nothin
On Wed, 22 Nov 2000 00:26:23 Tigran Aivazian wrote:
> On Wed, 22 Nov 2000, J . A . Magallon wrote:
>
> In the case of kernel, we have to do many things manually, can't rely on
> some compiler (sometimes :). So, the code I pointed you at
> arch/i386/kernel/head.S (look for "Clear BSS") is in fact
On Wed, 22 Nov 2000, J . A . Magallon wrote:
>
> On Wed, 22 Nov 2000 00:04:53 Tigran Aivazian wrote:
> > On Tue, 21 Nov 2000, J . A . Magallon wrote:
> >
> > Quite the contrary. The patch seems correct and useful to me. What do you
> > think is wrong with it? (Linus accepted megabytes worth of
On Wed, 22 Nov 2000 00:04:53 Tigran Aivazian wrote:
> On Tue, 21 Nov 2000, J . A . Magallon wrote:
>
> Quite the contrary. The patch seems correct and useful to me. What do you
> think is wrong with it? (Linus accepted megabytes worth of the above in
> the past...)
>
Sorry, i should look at th
On Tue, 21 Nov 2000, J . A . Magallon wrote:
>
> On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> >
> > Quick removal of unnecessary initialization to 0.
> >
> >
> > -static int basePort = 0; /* base port address */
> > -static int regPort = 0;/* port for registe
On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
>
> Quick removal of unnecessary initialization to 0.
>
>
> -static int basePort = 0; /* base port address */
> -static int regPort = 0; /* port for register number */
> -static int dataPort = 0; /* port for re
Hi
Quick removal of unnecessary initialization to 0.
--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>
diff -uNr linux-240t11/drivers/ide/ali14xx.c linux/drivers/ide/ali14xx.c
--- linux-240t11/drivers/ide/ali14xx.c Tue Jun 13 20:32:00 2000
+++ linux/drivers/ide/ali14xx.c Tue Nov 21 14:35:59 2
92 matches
Mail list logo
