Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
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 this flag tomorrow. > >We already argue about the extra couple of bytes that xx change to the > >kernel/a module would cost. With these change, we save kilo-bytes in > >disk space (which is important on some systems). > > PDAs!!! :) Excellent work Russell. Note that this only affects the storage; the run-time size is exactly the same in both cases. I hope my comment above was clear about that. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
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 defined symbol" errors where you fail to initialise it to a value. Okay extern global variables in the kernel need to be controlled and it is not like many get added, however it is possible that one developer may never know it is already in use by another part of the kernel, when their oh-no-new driver is added. Since the linkers assistance in this issue has just been disabled. Is 'gas' able to be configured to never emit common symbols, but emit BBS symbols instead, or is 'ld' able to be configured to never merge common symbols but throw up "multiply defined symbol" errors. Then everyone is safe. >We already argue about the extra couple of bytes that xx change to the >kernel/a module would cost. With these change, we save kilo-bytes in >disk space (which is important on some systems). PDAs!!! :) Excellent work Russell. -- Darryl Miles - 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/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
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-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
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 unintended reliance > on zeroed data would be good. Too bad it is too late to fix. Its not me talking bullshit here, its you. It is totally reasonable to rely on: static int foo; to be zero. If it is not, that is a bug in the C startup code. No two ways about it. If someone then says "I want to initialise the BSS to some magic value to catch this reliance" then we are breaking a lot of peoples expectations. (Least Surprise theory) To say again, relying on foo to be zero is not a bug. If you set the BSS to something non-zero, we already know that a lot will break. But it will break because someone has broken the BSS initialisation code, not because it is relying on something that is expected to be standard. By setting the BSS to something non-zero, you're not telling anyone anything new. About the only response will be "fix the BSS initialisation". If you want to try this, then that is up to you. Don't let us stop you. However, don't expect people to accept patches to "fix" your self-created problem. I look forward to your complaints about the disk subsystems, keyboard, console, and so forth apparantly being broken. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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/
Re: [PATCH] removal of static foo = 0
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 unintended reliance on zeroed data would be good. Too bad it is too late to fix. Its not me talking bullshit here, its you. It is totally reasonable to rely on: static int foo; to be zero. If it is not, that is a bug in the C startup code. No two ways about it. If someone then says "I want to initialise the BSS to some magic value to catch this reliance" then we are breaking a lot of peoples expectations. (Least Surprise theory) To say again, relying on foo to be zero is not a bug. If you set the BSS to something non-zero, we already know that a lot will break. But it will break because someone has broken the BSS initialisation code, not because it is relying on something that is expected to be standard. By setting the BSS to something non-zero, you're not telling anyone anything new. About the only response will be "fix the BSS initialisation". If you want to try this, then that is up to you. Don't let us stop you. However, don't expect people to accept patches to "fix" your self-created problem. I look forward to your complaints about the disk subsystems, keyboard, console, and so forth apparantly being broken. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
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-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
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 defined symbol" errors where you fail to initialise it to a value. Okay extern global variables in the kernel need to be controlled and it is not like many get added, however it is possible that one developer may never know it is already in use by another part of the kernel, when their oh-no-new driver is added. Since the linkers assistance in this issue has just been disabled. Is 'gas' able to be configured to never emit common symbols, but emit BBS symbols instead, or is 'ld' able to be configured to never merge common symbols but throw up "multiply defined symbol" errors. Then everyone is safe. We already argue about the extra couple of bytes that xx change to the kernel/a module would cost. With these change, we save kilo-bytes in disk space (which is important on some systems). PDAs!!! :) Excellent work Russell. -- Darryl Miles - 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/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
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 this flag tomorrow. We already argue about the extra couple of bytes that xx change to the kernel/a module would cost. With these change, we save kilo-bytes in disk space (which is important on some systems). PDAs!!! :) Excellent work Russell. Note that this only affects the storage; the run-time size is exactly the same in both cases. I hope my comment above was clear about that. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
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 historical meaning of "block started by symbol") > > Do you have an ISO C standard to refer to? I don't, but my guess is > that the standard does not even *mention* discreet data sections. It > *does* say that globals and statics are implicitly initialized to 0 -- > the rest is a mere implementation issue. > > So yes, the two statements *are* trivially equivalent, unless I'm wrong > and the standard *does* talk about data sections. 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 that was "not only imply the same logic for the program but correspond to the same physical locations (if any) on the resulting object file". In this sense, obviously, they are not "trivially equivalent" since in one case there is no physical location at all -- that is the whole point of having bss at all. > > > For example a programmer could expect the variable to be in .data for > > binary patching the object > > 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 tell you which section it is in. If the tool only looks in > '.data', it is flawed. Keith already pointed out why you are wrong there. > > [David Hinds] > > > Did the savings really work out to be measured in kb's of space? I > > > would have expected compression to eliminate most of the savings. > > Some boot targets are not compressed. And the variables are scattered > through the .data section rather than all in one place, so the 0s may > not compress as well as you'd think. > > Anyway, by some estimates 'vmlinux' has gone down by several kilobytes > due to these patches. Obviously the exact savings depend on .config . "several" kilobytes? _My_ patches alone (accepted by Linus ages ago) reduced it by >280K. Regards, Tigran - 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/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
[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/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
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 tell you which section it is in. If the tool only looks in >'.data', it is flawed. The whole point of bss is that it does not have any space allocated in the object on disk. bss is just a section entry saying "this size, at this location", the area is allocated and zeroed at load time. Binary patches against bss on disk cannot work, there is nothing to patch. - 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/
Re: [PATCH] removal of "static foo = 0"
[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 going to change out from under us in a year. You said it yourself: we can do whatever we want here. And I don't see why we would ever want to do anything other than zero it. > Go back and read the rest of this thread. Examples have been provided > (not by me) of such code leading to latter mistakes. Oh please, how hard can it be to type static int foo; // = 0 as opposed to static int foo = 0; If the two produced the same object code, the second would be better, but they don't, so it isn't. Patch gcc, if you care enough (and feel you can convince the gcc steering committee to care enough). 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/
Re: [PATCH] removal of "static foo = 0"
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 catch bugs. >> It would take much effort over many years to make that work. > > Oh dear, here's that misconception again. > > static int a; > > isn't a bug. Alone, it is not. > It is not "uninitialised data". It is defined to be > zero. Setting the BSS of any C program to contain non-zero data will > break it. Fact. The only bug you'll find is the fact that you're > breaking the C standard. 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 unintended reliance on zeroed data would be good. Too bad it is too late to fix. > All variables declared at top-level are initialised. No questions > asked. And its not a bug to rely on such a fact. Go back and read the rest of this thread. Examples have been provided (not by me) of such code leading to latter mistakes. - 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/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
[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 have an ISO C standard to refer to? I don't, but my guess is that the standard does not even *mention* discreet data sections. It *does* say that globals and statics are implicitly initialized to 0 -- the rest is a mere implementation issue. So yes, the two statements *are* trivially equivalent, unless I'm wrong and the standard *does* talk about data sections. > For example a programmer could expect the variable to be in .data for > binary patching the object 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 tell you which section it is in. If the tool only looks in '.data', it is flawed. [David Hinds] > > Did the savings really work out to be measured in kb's of space? I > > would have expected compression to eliminate most of the savings. Some boot targets are not compressed. And the variables are scattered through the .data section rather than all in one place, so the 0s may not compress as well as you'd think. Anyway, by some estimates 'vmlinux' has gone down by several kilobytes due to these patches. Obviously the exact savings depend on .config . 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/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
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. Personally, I prefer symmetry: if > I have a list of static variables initialized to various things, I > don't have to use a different form for ones that are zero initialized. I would contend that you are wrong -- it is not a compiler bug. 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") Second, If compiler did the ".data -> .bss" move on the fly then it would violate the principle of least surprize. For example a programmer could expect the variable to be in .data for binary patching the object (this reason is not applicable to the Linux kernel because section information is lost when converting vmlinux to raw binary and then onto bzImage). > > Did the savings really work out to be measured in kb's of space? I > would have expected compression to eliminate most of the savings. > if one doesn't count compression then -- hundreds of Kbs (K=1024 and b = byte, not bit!). Even Mbs if you count multiple architectures. Use Keith Owens' famous perl script to do the counting. Regards, Tigran - 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/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
> 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" is initialized, but adding the "= 0" is revealing that the code actually relies on the default value. The code is obviously equivalent. It is a readability issue, not an issue of what the code does. 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. Personally, I prefer symmetry: if I have a list of static variables initialized to various things, I don't have to use a different form for ones that are zero initialized. Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings. -- Dave - 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/
Re: [PATCH] removal of "static foo = 0"
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 happen as they're FB drivers though).
This patch compiles 2.4.0-test12-pre2 with -fno-common and it fixups some minor
compilation problem around the kernel. Karsten note the lc_start_delay_check
change I did to make it to compile, it's not implemented yet, it only compiles
right now.
Patch is verified to compile with almost everything linked into the kernel, and
it boots with my normal configuration.
--- 2.4.0-test12-pre2-fno-common/drivers/char/applicom.c.~1~Thu Jul 13 06:58:42
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/char/applicom.cTue Nov 28 19:07:05
+2000
@@ -63,8 +63,8 @@
#define PCI_DEVICE_ID_APPLICOM_PCIGENERIC 0x0001
#define PCI_DEVICE_ID_APPLICOM_PCI2000IBS_CAN 0x0002
#define PCI_DEVICE_ID_APPLICOM_PCI2000PFB 0x0003
-#define MAX_PCI_DEVICE_NUM 3
#endif
+#define MAX_PCI_DEVICE_NUM 3
static char *applicom_pci_devnames[] = {
"PCI board",
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/isdnl3.c.~1~Tue Nov 28
18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/isdnl3.cTue Nov 28 19:46:08
+2000
@@ -522,6 +522,11 @@
l3ml3p(st, DL_RELEASE | CONFIRM);
}
+static void
+lc_start_delay_check(struct FsmInst *fi, int event, void *arg)
+{
+ /* FIXME */
+}
/* *INDENT-OFF* */
static struct FsmNode L3FnList[] __initdata =
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_s.c.~1~ Tue Nov 28 18:40:29
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_s.c Tue Nov 28 19:47:21
+2000
@@ -75,7 +75,7 @@
(cs->hw.njet.last_is0 & NETJET_IRQM0_READ))
/* we have a read dma int */
read_tiger(cs);
- if (cs->hw.njet.irqstat0 & NETJET_IRQM0_WRITE) !=
+ if ((cs->hw.njet.irqstat0 & NETJET_IRQM0_WRITE) !=
(cs->hw.njet.last_is0 & NETJET_IRQM0_WRITE))
/* we have a write dma int */
write_tiger(cs);
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_u.c.~1~ Tue Nov 28 18:40:29
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_u.c Tue Nov 28 19:48:52
+2000
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "netjet.h"
const char *NETjet_U_revision = "$Revision: 2.8 $";
@@ -131,7 +132,7 @@
return(0);
}
-static struct pci_dev *dev_netjet __initdata;
+static struct pci_dev *dev_netjet __initdata = 0;
int __init
setup_netjet_u(struct IsdnCard *card)
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/config.c.~1~Tue Nov 28
18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/config.cTue Nov 28 20:04:59
+2000
@@ -376,7 +376,7 @@
#endif /* IO0_IO1 */
#endif /* MODULE */
-static int nrcards;
+int nrcards;
extern char *l1_revision;
extern char *l2_revision;
--- 2.4.0-test12-pre2-fno-common/drivers/media/video/bttv.h.~1~ Tue Nov 28 18:50:21
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/media/video/bttv.h Tue Nov 28 18:51:19
+2000
@@ -179,9 +179,9 @@
/* i2c */
#define I2C_CLIENTS_MAX 8
-struct i2c_algo_bit_data bttv_i2c_algo_template;
-struct i2c_adapter bttv_i2c_adap_template;
-struct i2c_client bttv_i2c_client_template;
+extern struct i2c_algo_bit_data bttv_i2c_algo_template;
+extern struct i2c_adapter bttv_i2c_adap_template;
+extern struct i2c_client bttv_i2c_client_template;
void bttv_bit_setscl(void *data, int state);
void bttv_bit_setsda(void *data, int state);
void bttv_call_i2c_clients(struct bttv *btv, unsigned int cmd, void *arg);
--- 2.4.0-test12-pre2-fno-common/drivers/net/arlan.h.~1~Tue Nov 28 19:10:06
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/net/arlan.hTue Nov 28 19:11:44 2000
@@ -321,7 +321,7 @@
int tx_queue_len;
};
-struct arlan_conf_stru arlan_conf[MAX_ARLANS];
+extern struct arlan_conf_stru arlan_conf[MAX_ARLANS];
struct TxParam
{
--- 2.4.0-test12-pre2-fno-common/drivers/usb/storage/usb.h.~1~ Tue Nov 28 19:25:37
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/usb/storage/usb.h Tue Nov 28 19:40:11
+2000
@@ -187,7 +187,7 @@
extern struct semaphore us_list_semaphore;
/* The structure which defines our driver */
-struct usb_driver usb_storage_driver;
+extern struct usb_driver usb_storage_driver;
/* Function to fill an inquiry response. See usb.c for details */
extern void fill_inquiry_response(struct us_data *us,
--- 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.h.~1~Tue Nov 28
18:40:01 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.hTue Nov 28 19:28:42
+2000
@@ -95,15 +95,6 @@
#endif
-USHORT P3c4,P3d4,P3c0,P3ce,P3c2,P3ca,P3c6,P3c7,P3c8,P3c9,P3da;
-USHORT
Re: [PATCH] removal of "static foo = 0"
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, [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. > > |> > > |> Try it. They _will_ link together. > > > > Not if you compile with -fno-common, which should actually be the default > > some day, IMHO. > > I thought -fno-common was the default behaviour indeed, and I agree it should > become the default since current behaviour can lead to sublte bugs. (better I > discovered this gcc "extension" this way than after some day of debugging :) > > I'm all for gcc extensions when they're powerful and useful, but this > one looks absolutely worthless. I don't see any advantage from the current > behaviour (avoid an "extern" in some include file that we have/want to write > anyways to write correct C code?), and at least in large project (like the > kernel) where different part of the project are handled by different people > using -fno-common is pretty much mandatory IMHO. Umm, the original Ritchie C compiler on the PDP-11 and the Johnson 'Portable' C compiler both had this extension, as well as every other C compiler under UNIX (tm) I've ever used or read the documentation for. It is also mentioned in the standards as a common extension (I wrote the initial draft for this section in the C89 standard). When asked why the disconnect between what K said (ref/def model) and what their compilers actually did (common model), the AT representative at the time said that the ref/def model was put into K when they tried to make a C compiler for their IBM mainframes, using the standard linker, and discovered that linker would page align each common variable (CSECT in IBM terminology IIRC). The IBM linker is also the reason why the K and the C89 standard had the rule that global names must be unique to 6 characters, one case (which is another extension that just about everybody has and depends on). The default for C++ is -fno-common. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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/
Re: [PATCH] removal of "static foo = 0"
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] 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. |> > |> |> > |> Try it. They _will_ link together. |> > |> > Not if you compile with -fno-common, which should actually be the default |> > some day, IMHO. |> |> I thought -fno-common was the default behaviour indeed, and I agree it should |> become the default since current behaviour can lead to sublte bugs. (better I |> discovered this gcc "extension" this way than after some day of debugging :) This is not really a gcc extension, but long Unix tradition. If you make -fno-common the default then many programs will not build any more, including the Linux kernel. :-) Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg - 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/
Re: [PATCH] removal of "static foo = 0"
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: > |> > > int a,b,c; > |> > > > |> > > test2.c: > |> > > int a,c; > |> > > > |> > > Which is _stronger_? > |> > > |> > Those won't link together as they aren't declared static. > |> > |> Try it. They _will_ link together. > > Not if you compile with -fno-common, which should actually be the default > some day, IMHO. I thought -fno-common was the default behaviour indeed, and I agree it should become the default since current behaviour can lead to sublte bugs. (better I discovered this gcc "extension" this way than after some day of debugging :) I'm all for gcc extensions when they're powerful and useful, but this one looks absolutely worthless. I don't see any advantage from the current behaviour (avoid an "extern" in some include file that we have/want to write anyways to write correct C code?), and at least in large project (like the kernel) where different part of the project are handled by different people using -fno-common is pretty much mandatory IMHO. Think at somebody writing a driver starting from another driver, maybe he renames most of the stuff but he forgets to rename an uninitialized global variable. This bug won't trigger for him because he's not using the other driver at the same time. It will trigger only when an unlucky user will happen to use both drivers at the same time because he owns both hardwares... I disagree with GCC documentation: `-fno-common' Allocate even uninitialized global variables in the bss section of the object file, rather than generating them as common blocks. This has the effect that if the same variable is declared (without `extern') in two different compilations, you will get an error when you link them. The only reason this might be useful is if ^^ you wish to verify that the program will work on other systems ^^ which always work this way. ^^ That's one reason, but it's really not the interesting one... Andrea - 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/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
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 my code actually relies on
> > > it; I don't want that information eliminated.
> >
> > Yes, but if it generates a bigger (== worse) binary?
>
> We're talking about a few bytes, here. If you're prepared to make my
> code less clear to save bytes, you can do much better than that...
Perhaps in your case you had just an
int a = 0;
then it's really just a few bytes, but many sources have for example
int a[1024] = { 0, 0, /* */ };
Which in turn is a big wastage.
On the other hand, if you save "just" a few bytes in every driver, in a
way that is safe and simple (and commenting out the = 0 is a safe way),
you get a lot of space saved in the sum.
--
Vojtech Pavlik
SuSE Labs
-
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/
Re: [PATCH] removal of "static foo = 0"
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 the fact that variables are adyacent in memory to generate better code, and this degenerated into the current discussion about where they are from the programmers perspective. - If gcc is going to use the fact that some variables are nearby for some optimization purposes, I do trust the gcc hackers to set stuff up so that they use it for variables that are nearby in VM, not just where defined together. If variables defined together end up adyacent or not is completely irrelevant. The compiler might even rearrange them to optimize for the access pattern observed. - As a C programmer, you are only entitled to assume that pieces of the same object (array or struct) are laid out in memory in the order given. With segmented VM different objects would probably end up in different segments anyway. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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/
Re: [PATCH] removal of "static foo = 0"
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 _stronger_? |> > |> > Those won't link together as they aren't declared static. |> |> Try it. They _will_ link together. Not if you compile with -fno-common, which should actually be the default some day, IMHO. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg - 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/
Re: [PATCH] removal of static foo = 0
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 the fact that variables are adyacent in memory to generate better code, and this degenerated into the current discussion about where they are from the programmers perspective. - If gcc is going to use the fact that some variables are nearby for some optimization purposes, I do trust the gcc hackers to set stuff up so that they use it for variables that are nearby in VM, not just where defined together. If variables defined together end up adyacent or not is completely irrelevant. The compiler might even rearrange them to optimize for the access pattern observed. - As a C programmer, you are only entitled to assume that pieces of the same object (array or struct) are laid out in memory in the order given. With segmented VM different objects would probably end up in different segments anyway. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
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 my code actually relies on
it; I don't want that information eliminated.
Yes, but if it generates a bigger (== worse) binary?
We're talking about a few bytes, here. If you're prepared to make my
code less clear to save bytes, you can do much better than that...
Perhaps in your case you had just an
int a = 0;
then it's really just a few bytes, but many sources have for example
int a[1024] = { 0, 0, /* */ };
Which in turn is a big wastage.
On the other hand, if you save "just" a few bytes in every driver, in a
way that is safe and simple (and commenting out the = 0 is a safe way),
you get a lot of space saved in the sum.
--
Vojtech Pavlik
SuSE Labs
-
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/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
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" is initialized, but adding the "= 0" is revealing that the code actually relies on the default value. The code is obviously equivalent. It is a readability issue, not an issue of what the code does. 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. Personally, I prefer symmetry: if I have a list of static variables initialized to various things, I don't have to use a different form for ones that are zero initialized. Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings. -- Dave - 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/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
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. Personally, I prefer symmetry: if I have a list of static variables initialized to various things, I don't have to use a different form for ones that are zero initialized. I would contend that you are wrong -- it is not a compiler bug. 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") Second, If compiler did the ".data - .bss" move on the fly then it would violate the principle of least surprize. For example a programmer could expect the variable to be in .data for binary patching the object (this reason is not applicable to the Linux kernel because section information is lost when converting vmlinux to raw binary and then onto bzImage). Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings. if one doesn't count compression then -- hundreds of Kbs (K=1024 and b = byte, not bit!). Even Mbs if you count multiple architectures. Use Keith Owens' famous perl script to do the counting. Regards, Tigran - 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/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
[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 have an ISO C standard to refer to? I don't, but my guess is that the standard does not even *mention* discreet data sections. It *does* say that globals and statics are implicitly initialized to 0 -- the rest is a mere implementation issue. So yes, the two statements *are* trivially equivalent, unless I'm wrong and the standard *does* talk about data sections. For example a programmer could expect the variable to be in .data for binary patching the object 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 tell you which section it is in. If the tool only looks in '.data', it is flawed. [David Hinds] Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings. Some boot targets are not compressed. And the variables are scattered through the .data section rather than all in one place, so the 0s may not compress as well as you'd think. Anyway, by some estimates 'vmlinux' has gone down by several kilobytes due to these patches. Obviously the exact savings depend on .config . 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/
Re: [PATCH] removal of static foo = 0
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 catch bugs. It would take much effort over many years to make that work. Oh dear, here's that misconception again. static int a; isn't a bug. Alone, it is not. It is not "uninitialised data". It is defined to be zero. Setting the BSS of any C program to contain non-zero data will break it. Fact. The only bug you'll find is the fact that you're breaking the C standard. 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 unintended reliance on zeroed data would be good. Too bad it is too late to fix. All variables declared at top-level are initialised. No questions asked. And its not a bug to rely on such a fact. Go back and read the rest of this thread. Examples have been provided (not by me) of such code leading to latter mistakes. - 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/
Re: [PATCH] removal of static foo = 0
[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 going to change out from under us in a year. You said it yourself: we can do whatever we want here. And I don't see why we would ever want to do anything other than zero it. Go back and read the rest of this thread. Examples have been provided (not by me) of such code leading to latter mistakes. Oh please, how hard can it be to type static int foo; // = 0 as opposed to static int foo = 0; If the two produced the same object code, the second would be better, but they don't, so it isn't. Patch gcc, if you care enough (and feel you can convince the gcc steering committee to care enough). 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/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
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 tell you which section it is in. If the tool only looks in '.data', it is flawed. The whole point of bss is that it does not have any space allocated in the object on disk. bss is just a section entry saying "this size, at this location", the area is allocated and zeroed at load time. Binary patches against bss on disk cannot work, there is nothing to patch. - 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/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
[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/
Re: [PATCH] removal of static foo = 0
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 happen as they're FB drivers though).
This patch compiles 2.4.0-test12-pre2 with -fno-common and it fixups some minor
compilation problem around the kernel. Karsten note the lc_start_delay_check
change I did to make it to compile, it's not implemented yet, it only compiles
right now.
Patch is verified to compile with almost everything linked into the kernel, and
it boots with my normal configuration.
--- 2.4.0-test12-pre2-fno-common/drivers/char/applicom.c.~1~Thu Jul 13 06:58:42
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/char/applicom.cTue Nov 28 19:07:05
+2000
@@ -63,8 +63,8 @@
#define PCI_DEVICE_ID_APPLICOM_PCIGENERIC 0x0001
#define PCI_DEVICE_ID_APPLICOM_PCI2000IBS_CAN 0x0002
#define PCI_DEVICE_ID_APPLICOM_PCI2000PFB 0x0003
-#define MAX_PCI_DEVICE_NUM 3
#endif
+#define MAX_PCI_DEVICE_NUM 3
static char *applicom_pci_devnames[] = {
"PCI board",
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/isdnl3.c.~1~Tue Nov 28
18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/isdnl3.cTue Nov 28 19:46:08
+2000
@@ -522,6 +522,11 @@
l3ml3p(st, DL_RELEASE | CONFIRM);
}
+static void
+lc_start_delay_check(struct FsmInst *fi, int event, void *arg)
+{
+ /* FIXME */
+}
/* *INDENT-OFF* */
static struct FsmNode L3FnList[] __initdata =
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_s.c.~1~ Tue Nov 28 18:40:29
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_s.c Tue Nov 28 19:47:21
+2000
@@ -75,7 +75,7 @@
(cs-hw.njet.last_is0 NETJET_IRQM0_READ))
/* we have a read dma int */
read_tiger(cs);
- if (cs-hw.njet.irqstat0 NETJET_IRQM0_WRITE) !=
+ if ((cs-hw.njet.irqstat0 NETJET_IRQM0_WRITE) !=
(cs-hw.njet.last_is0 NETJET_IRQM0_WRITE))
/* we have a write dma int */
write_tiger(cs);
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_u.c.~1~ Tue Nov 28 18:40:29
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_u.c Tue Nov 28 19:48:52
+2000
@@ -11,6 +11,7 @@
#include linux/pci.h
#include linux/interrupt.h
#include linux/ppp_defs.h
+#include linux/init.h
#include "netjet.h"
const char *NETjet_U_revision = "$Revision: 2.8 $";
@@ -131,7 +132,7 @@
return(0);
}
-static struct pci_dev *dev_netjet __initdata;
+static struct pci_dev *dev_netjet __initdata = 0;
int __init
setup_netjet_u(struct IsdnCard *card)
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/config.c.~1~Tue Nov 28
18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/config.cTue Nov 28 20:04:59
+2000
@@ -376,7 +376,7 @@
#endif /* IO0_IO1 */
#endif /* MODULE */
-static int nrcards;
+int nrcards;
extern char *l1_revision;
extern char *l2_revision;
--- 2.4.0-test12-pre2-fno-common/drivers/media/video/bttv.h.~1~ Tue Nov 28 18:50:21
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/media/video/bttv.h Tue Nov 28 18:51:19
+2000
@@ -179,9 +179,9 @@
/* i2c */
#define I2C_CLIENTS_MAX 8
-struct i2c_algo_bit_data bttv_i2c_algo_template;
-struct i2c_adapter bttv_i2c_adap_template;
-struct i2c_client bttv_i2c_client_template;
+extern struct i2c_algo_bit_data bttv_i2c_algo_template;
+extern struct i2c_adapter bttv_i2c_adap_template;
+extern struct i2c_client bttv_i2c_client_template;
void bttv_bit_setscl(void *data, int state);
void bttv_bit_setsda(void *data, int state);
void bttv_call_i2c_clients(struct bttv *btv, unsigned int cmd, void *arg);
--- 2.4.0-test12-pre2-fno-common/drivers/net/arlan.h.~1~Tue Nov 28 19:10:06
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/net/arlan.hTue Nov 28 19:11:44 2000
@@ -321,7 +321,7 @@
int tx_queue_len;
};
-struct arlan_conf_stru arlan_conf[MAX_ARLANS];
+extern struct arlan_conf_stru arlan_conf[MAX_ARLANS];
struct TxParam
{
--- 2.4.0-test12-pre2-fno-common/drivers/usb/storage/usb.h.~1~ Tue Nov 28 19:25:37
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/usb/storage/usb.h Tue Nov 28 19:40:11
+2000
@@ -187,7 +187,7 @@
extern struct semaphore us_list_semaphore;
/* The structure which defines our driver */
-struct usb_driver usb_storage_driver;
+extern struct usb_driver usb_storage_driver;
/* Function to fill an inquiry response. See usb.c for details */
extern void fill_inquiry_response(struct us_data *us,
--- 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.h.~1~Tue Nov 28
18:40:01 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.hTue Nov 28 19:28:42
+2000
@@ -95,15 +95,6 @@
#endif
-USHORT
Re: [PATCH] removal of static foo = 0
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 _stronger_? | | Those won't link together as they aren't declared static. | | Try it. They _will_ link together. Not if you compile with -fno-common, which should actually be the default some day, IMHO. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg - 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/
Re: [PATCH] removal of static foo = 0
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: | int a,b,c; | | test2.c: | int a,c; | | Which is _stronger_? | | Those won't link together as they aren't declared static. | | Try it. They _will_ link together. Not if you compile with -fno-common, which should actually be the default some day, IMHO. I thought -fno-common was the default behaviour indeed, and I agree it should become the default since current behaviour can lead to sublte bugs. (better I discovered this gcc "extension" this way than after some day of debugging :) I'm all for gcc extensions when they're powerful and useful, but this one looks absolutely worthless. I don't see any advantage from the current behaviour (avoid an "extern" in some include file that we have/want to write anyways to write correct C code?), and at least in large project (like the kernel) where different part of the project are handled by different people using -fno-common is pretty much mandatory IMHO. Think at somebody writing a driver starting from another driver, maybe he renames most of the stuff but he forgets to rename an uninitialized global variable. This bug won't trigger for him because he's not using the other driver at the same time. It will trigger only when an unlucky user will happen to use both drivers at the same time because he owns both hardwares... I disagree with GCC documentation: `-fno-common' Allocate even uninitialized global variables in the bss section of the object file, rather than generating them as common blocks. This has the effect that if the same variable is declared (without `extern') in two different compilations, you will get an error when you link them. The only reason this might be useful is if ^^ you wish to verify that the program will work on other systems ^^ which always work this way. ^^ That's one reason, but it's really not the interesting one... Andrea - 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/
Re: [PATCH] removal of static foo = 0
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, [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. | | Try it. They _will_ link together. Not if you compile with -fno-common, which should actually be the default some day, IMHO. I thought -fno-common was the default behaviour indeed, and I agree it should become the default since current behaviour can lead to sublte bugs. (better I discovered this gcc "extension" this way than after some day of debugging :) I'm all for gcc extensions when they're powerful and useful, but this one looks absolutely worthless. I don't see any advantage from the current behaviour (avoid an "extern" in some include file that we have/want to write anyways to write correct C code?), and at least in large project (like the kernel) where different part of the project are handled by different people using -fno-common is pretty much mandatory IMHO. Umm, the original Ritchie C compiler on the PDP-11 and the Johnson 'Portable' C compiler both had this extension, as well as every other C compiler under UNIX (tm) I've ever used or read the documentation for. It is also mentioned in the standards as a common extension (I wrote the initial draft for this section in the C89 standard). When asked why the disconnect between what KR said (ref/def model) and what their compilers actually did (common model), the ATT representative at the time said that the ref/def model was put into KR when they tried to make a C compiler for their IBM mainframes, using the standard linker, and discovered that linker would page align each common variable (CSECT in IBM terminology IIRC). The IBM linker is also the reason why the KR and the C89 standard had the rule that global names must be unique to 6 characters, one case (which is another extension that just about everybody has and depends on). The default for C++ is -fno-common. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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/
Re: [PATCH] removal of static foo = 0
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] 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. | | | | Try it. They _will_ link together. | | Not if you compile with -fno-common, which should actually be the default | some day, IMHO. | | I thought -fno-common was the default behaviour indeed, and I agree it should | become the default since current behaviour can lead to sublte bugs. (better I | discovered this gcc "extension" this way than after some day of debugging :) This is not really a gcc extension, but long Unix tradition. If you make -fno-common the default then many programs will not build any more, including the Linux kernel. :-) Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg - 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/
Re: [PATCH] removal of "static foo = 0"
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; > > > > > > Which is _stronger_? > > > > Those won't link together as they aren't declared static. > > Try it. They _will_ link together. This is a GCC extension (actually it is a pretty common UNIX extension, but the official standard says you can only have one definition of a global variable). Off the top of my head, here are some reasons variables could be put in different orders: 1) The compilation system has the concept of a small data pointer, which is a register that is assumed by the compiler to point to a small region of memory (it is never allocated by the compiler and setup in the initialization modules). The compiler decides to put some variables into the small data region and other variables outside of it. Typically the choice is based on size of the variable. Small data pointers are typically used when the machine has plenty of registers and it takes 2 or more instructions to build the address of a random variable in memory with load high/load low type instructions, and the small data pointer has the upper half already loaded, and uses special relocations to access the variable based off of the difference of a special symbol. 2) Even without a small data pointer, a compiler might decide to sort the variables emitted based on either size or number of accesses to take advantage of instructions with smaller offsets. 3) The above mentioned global, non-initialized variables (ie, the so-called 'common' variables). Where the linker puts the variables into the bss section in any order it chooses. For example, the VMS linker used to sort common variables alphabetically. 4) For static variables, the compilation system might decide to omit the variable until it sees a reference to the variable, and if the first variable is referenced in one function, and the second is referenced several functions later. 5) At some point in the future, on machines with many more registers than the normal 32, the linker might see all references to a variable, and decide to put it in a static register rather than memory. 6) A checkout compiler could randomly order things specifically to catch these type of errors (the problem with the normal checkout compilers that I'm aware of, is that the kernel uses structs to talk to real devices and interact with system calls with fixed layouts). -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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/
Re: [PATCH] removal of "static foo = 0"
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. Try it. They _will_ link together. - 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/
Re: [PATCH] removal of "static foo = 0"
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'm not suggesting anything like that and I'm more than happy the compiler is allowed to do sane optimizations with none downside :). Andrea - 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/
Re: [PATCH] removal of "static foo = 0"
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" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
[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__((section)). You probably will be using things like __attribute__((align)) as well. Relying on compiler behavior here is dangerous. I agree though that an option is called for, either -fassume-bss-zero or -fno-assume-bss-zero, not sure which should be the default. 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/
Re: [PATCH] removal of "static foo = 0"
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 much effort over many years to make that work. Oh dear, here's that misconception again. static int a; isn't a bug. It is not "uninitialised data". It is defined to be zero. Setting the BSS of any C program to contain non-zero data will break it. Fact. The only bug you'll find is the fact that you're breaking the C standard. There is only two places where you come across uninitialised data: 1. memory obtained from outside text, data, bss limit of the program (ie, malloced memory) 2. if you use auto variables which may be allocated on the stack All variables declared at top-level are initialised. No questions asked. And its not a bug to rely on such a fact. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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/
Re: [PATCH] removal of "static foo = 0"
[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 could be wrong on this one though.
> >
> > I'm not sure either, but we certainly rely on that behaviour somewhere.
> > Just to make an example fs/dquot.c:
> >
> > int nr_dquots, nr_free_dquots;
> >
> > kernel/sysctl.c:
> >
> > {FS_NRDQUOT, "dquot-nr", _dquots, 2*sizeof(int),
> >
> > The above is ok also on mips in practice though.
>
> That needs to be fixed ASAP to use an array (not a structure). It is simply
> wrong to depend on two variables winding up in at adjacent offsets.
This reminded me of an old bug which apparently still hasn't been
fixed (not in 2.2 at least). In init/main.c we have:
extern int rd_image_start; /* starting block # of image */
#ifdef CONFIG_BLK_DEV_INITRD
kdev_t real_root_dev;
#endif
#endif
int root_mountflags = MS_RDONLY;
and then in kernel/sysctl.c:
#ifdef CONFIG_BLK_DEV_INITRD
{KERN_REALROOTDEV, "real-root-dev", _root_dev, sizeof(int),
0644, NULL, _dointvec},
#endif
Because rd_image_start and root_mountflags are both int-aligned,
this happens to work on little endian platforms. On big endian
platforms however writing a value in the range 0-65535 to
/proc/sys/kernel/real-root-dev will place 0 in real_root_dev,
and the actual value in the two padding bytes...
(Yes, I'm one of the few that have actually used this feature. ;-)
Unfortunately proc_dointvec() doesn't support shorts, so what is
the correct fix? Changing:
kdev_t real_root_dev;
into
int real_root-dev;
is a perfectly working solution, but is it acceptable?
//Marcus
--
---+---
Marcus Sundberg| Phone: +46 707 452062
Embedded Systems Consultant | Email: [EMAIL PROTECTED]
Cendio Systems AB | http://www.cendio.com
-
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/
Re: [PATCH] removal of "static foo = 0"
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 programmer. This " = 0" means (to me, the programmer) > that the correctness of my program depends on this initialization. > Its absense means (to me) that it does not matter what initial > value the variable has. 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 much effort over many years to make that work. I'd rather see the compiler optimize for cache line use and make use of small address offsets to load variables. - 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/
Re: [PATCH] removal of "static foo = 0"
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 specs and I didn't find anything. So I wasn't sure > if I missed the information in the specs or not. I never investigated on it > because I always considered it bad coding regardless the fact it's guaranteed > to generate the right asm with the _current_ tools. > > Andrea > - The following shell-script shows that gcc-2.8.1 produces code with data allocations adjacent. However, they are reversed! cat -
Re: [PATCH] removal of "static foo = 0"
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 missed the information in the specs or not. I never investigated on it because I always considered it bad coding regardless the fact it's guaranteed to generate the right asm with the _current_ tools. Andrea - 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/
Re: [PATCH] removal of "static foo = 0"
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 rely on that behaviour somewhere.
> Just to make an example fs/dquot.c:
>
> int nr_dquots, nr_free_dquots;
>
> kernel/sysctl.c:
>
> {FS_NRDQUOT, "dquot-nr", _dquots, 2*sizeof(int),
>
> The above is ok also on mips in practice though.
>
This code is simply wrong! You can't assume that the declaration of
two variables, no matter how similar, makes them adjacent in
memory! You also can't assume any order. We have good 'C' compilers
that do order things as we assume, however it is only fortuitous, and
not defined any any rule(s).
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
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/
Re: [PATCH] removal of "static foo = 0"
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 calculates the location of an > explicitly initialized static variable based on the address of another > one. E.g. in > > static int a = 0, b = 0, c = 0, d = 0; > > ... > ... a+b+c+d ... > ... > > 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 also > true for other versions/architectures, or other code constructs. Jeff Law played with a similar optimization about 1-2 years ago, and eventually deleted all of the code because there were problems with the code. It would help some of our platforms (but not the x86) to access all variables in the same section via a common pointer. This is because on those systems, it often times takes 2-3 instructions to access global/static variables. Global variables you have more problems visiblity and such. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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/
Re: [PATCH] removal of "static foo = 0"
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 either, but we certainly rely on that behaviour somewhere.
> Just to make an example fs/dquot.c:
>
> int nr_dquots, nr_free_dquots;
>
> kernel/sysctl.c:
>
> {FS_NRDQUOT, "dquot-nr", _dquots, 2*sizeof(int),
>
> The above is ok also on mips in practice though.
That needs to be fixed ASAP to use an array (not a structure). It is simply
wrong to depend on two variables winding up in at adjacent offsets.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
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/
Re: [PATCH] removal of "static foo = 0"
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 example fs/dquot.c:
int nr_dquots, nr_free_dquots;
kernel/sysctl.c:
{FS_NRDQUOT, "dquot-nr", _dquots, 2*sizeof(int),
The above is ok also on mips in practice though.
In 2.2.x there was more of them.
Regardless if we're allowed to rely on the ordering the above is bad coding
practice because somebody could forget about the dependency on the ordering and
put something between nr_dquotes and nr_free_dquotes :), so such dependency
should be avoided anyways...
Andrea
-
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/
Re: [PATCH] removal of "static foo = 0"
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 generate the same code, > but I am not talking about the compiler. I am talking about > the programmer. This " = 0" means (to me, the programmer) > that the correctness of my program depends on this initialization. > Its absense means (to me) that it does not matter what initial > value the variable has. Seems to me few other people think that way, thats why it is so har for them to get. And thats why this style of coding isn't very helpful either. It may be a real help for you, but not for others who merely get confused or irritated at the small but easy to eliminate micro-bloat. There are certainly people so used to the implicit zeroing that they think of "static int a;" as a zero initialization as explicit as anything, because that's the way the language works. And they will take just as much care if the "a-using" code is modified to run twice. The "=0" part don't make it clearer for them if it was clear already. Helge Hafting - 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/
Re: [PATCH] removal of "static foo = 0"
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 variables in sequence, and where it could access them either by referencing each by absolute address, with relocation (so that objdump-patcher could change that), or by generating a pointer and using pointer-relative addressing or pointer increment (so we only get one relocation and never know what may go wrong with the other variables). - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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/
Re: [PATCH] removal of "static foo = 0"
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 also true for other versions/architectures, or other code constructs. There is no guarentee that contiguous data or bss section members will appear contiguous and in the same order, in the final object. In fact, a specific optimization done on MIPS and other platforms is to place all data members under a certain size in a special ".small.data" section. So for example: static int a; static struct foo b; static int b; Would not place 'b' at " + sizeof(a) + sizeof(b)" Also I believe linkers are allowed to arbitrarily reorder members in the data and bss sections. I could be wrong on this one though. Later, David S. Miller [EMAIL PROTECTED] - 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/
Re: [PATCH] removal of "static foo = 0"
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 the address of another one. E.g. in static int a = 0, b = 0, c = 0, d = 0; ... ... a+b+c+d ... ... 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 also true for other versions/architectures, or other code constructs. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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/
Re: [PATCH] removal of static foo = 0
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 the address of another one. E.g. in static int a = 0, b = 0, c = 0, d = 0; ... ... a+b+c+d ... ... 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 also true for other versions/architectures, or other code constructs. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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/
Re: [PATCH] removal of static foo = 0
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 generate the same code, but I am not talking about the compiler. I am talking about the programmer. This " = 0" means (to me, the programmer) that the correctness of my program depends on this initialization. Its absense means (to me) that it does not matter what initial value the variable has. Seems to me few other people think that way, thats why it is so har for them to get. And thats why this style of coding isn't very helpful either. It may be a real help for you, but not for others who merely get confused or irritated at the small but easy to eliminate micro-bloat. There are certainly people so used to the implicit zeroing that they think of "static int a;" as a zero initialization as explicit as anything, because that's the way the language works. And they will take just as much care if the "a-using" code is modified to run twice. The "=0" part don't make it clearer for them if it was clear already. Helge Hafting - 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/
Re: [PATCH] removal of static foo = 0
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 calculates the location of an explicitly initialized static variable based on the address of another one. E.g. in static int a = 0, b = 0, c = 0, d = 0; ... ... a+b+c+d ... ... 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 also true for other versions/architectures, or other code constructs. Jeff Law played with a similar optimization about 1-2 years ago, and eventually deleted all of the code because there were problems with the code. It would help some of our platforms (but not the x86) to access all variables in the same section via a common pointer. This is because on those systems, it often times takes 2-3 instructions to access global/static variables. Global variables you have more problems visiblity and such. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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/
Re: [PATCH] removal of static foo = 0
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 rely on that behaviour somewhere.
Just to make an example fs/dquot.c:
int nr_dquots, nr_free_dquots;
kernel/sysctl.c:
{FS_NRDQUOT, "dquot-nr", nr_dquots, 2*sizeof(int),
The above is ok also on mips in practice though.
This code is simply wrong! You can't assume that the declaration of
two variables, no matter how similar, makes them adjacent in
memory! You also can't assume any order. We have good 'C' compilers
that do order things as we assume, however it is only fortuitous, and
not defined any any rule(s).
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
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/
Re: [PATCH] removal of static foo = 0
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 programmer. This " = 0" means (to me, the programmer) that the correctness of my program depends on this initialization. Its absense means (to me) that it does not matter what initial value the variable has. 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 much effort over many years to make that work. I'd rather see the compiler optimize for cache line use and make use of small address offsets to load variables. - 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/
Re: [PATCH] removal of static foo = 0
[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 could be wrong on this one though.
I'm not sure either, but we certainly rely on that behaviour somewhere.
Just to make an example fs/dquot.c:
int nr_dquots, nr_free_dquots;
kernel/sysctl.c:
{FS_NRDQUOT, "dquot-nr", nr_dquots, 2*sizeof(int),
The above is ok also on mips in practice though.
That needs to be fixed ASAP to use an array (not a structure). It is simply
wrong to depend on two variables winding up in at adjacent offsets.
This reminded me of an old bug which apparently still hasn't been
fixed (not in 2.2 at least). In init/main.c we have:
extern int rd_image_start; /* starting block # of image */
#ifdef CONFIG_BLK_DEV_INITRD
kdev_t real_root_dev;
#endif
#endif
int root_mountflags = MS_RDONLY;
and then in kernel/sysctl.c:
#ifdef CONFIG_BLK_DEV_INITRD
{KERN_REALROOTDEV, "real-root-dev", real_root_dev, sizeof(int),
0644, NULL, proc_dointvec},
#endif
Because rd_image_start and root_mountflags are both int-aligned,
this happens to work on little endian platforms. On big endian
platforms however writing a value in the range 0-65535 to
/proc/sys/kernel/real-root-dev will place 0 in real_root_dev,
and the actual value in the two padding bytes...
(Yes, I'm one of the few that have actually used this feature. ;-)
Unfortunately proc_dointvec() doesn't support shorts, so what is
the correct fix? Changing:
kdev_t real_root_dev;
into
int real_root-dev;
is a perfectly working solution, but is it acceptable?
//Marcus
--
---+---
Marcus Sundberg| Phone: +46 707 452062
Embedded Systems Consultant | Email: [EMAIL PROTECTED]
Cendio Systems AB | http://www.cendio.com
-
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/
Re: [PATCH] removal of static foo = 0
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 much effort over many years to make that work. Oh dear, here's that misconception again. static int a; isn't a bug. It is not "uninitialised data". It is defined to be zero. Setting the BSS of any C program to contain non-zero data will break it. Fact. The only bug you'll find is the fact that you're breaking the C standard. There is only two places where you come across uninitialised data: 1. memory obtained from outside text, data, bss limit of the program (ie, malloced memory) 2. if you use auto variables which may be allocated on the stack All variables declared at top-level are initialised. No questions asked. And its not a bug to rely on such a fact. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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/
Re: [PATCH] removal of static foo = 0
[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__((section)). You probably will be using things like __attribute__((align)) as well. Relying on compiler behavior here is dangerous. I agree though that an option is called for, either -fassume-bss-zero or -fno-assume-bss-zero, not sure which should be the default. 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/
Re: [PATCH] removal of static foo = 0
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 also true for other versions/architectures, or other code constructs. There is no guarentee that contiguous data or bss section members will appear contiguous and in the same order, in the final object. In fact, a specific optimization done on MIPS and other platforms is to place all data members under a certain size in a special ".small.data" section. So for example: static int a; static struct foo b; static int b; Would not place 'b' at "a + sizeof(a) + sizeof(b)" Also I believe linkers are allowed to arbitrarily reorder members in the data and bss sections. I could be wrong on this one though. Later, David S. Miller [EMAIL PROTECTED] - 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/
Re: [PATCH] removal of static foo = 0
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" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0
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 example fs/dquot.c:
int nr_dquots, nr_free_dquots;
kernel/sysctl.c:
{FS_NRDQUOT, "dquot-nr", nr_dquots, 2*sizeof(int),
The above is ok also on mips in practice though.
In 2.2.x there was more of them.
Regardless if we're allowed to rely on the ordering the above is bad coding
practice because somebody could forget about the dependency on the ordering and
put something between nr_dquotes and nr_free_dquotes :), so such dependency
should be avoided anyways...
Andrea
-
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/
Re: [PATCH] removal of static foo = 0
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'm not suggesting anything like that and I'm more than happy the compiler is allowed to do sane optimizations with none downside :). Andrea - 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/
Re: [PATCH] removal of static foo = 0
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; Which is _stronger_? Those won't link together as they aren't declared static. Try it. They _will_ link together. This is a GCC extension (actually it is a pretty common UNIX extension, but the official standard says you can only have one definition of a global variable). Off the top of my head, here are some reasons variables could be put in different orders: 1) The compilation system has the concept of a small data pointer, which is a register that is assumed by the compiler to point to a small region of memory (it is never allocated by the compiler and setup in the initialization modules). The compiler decides to put some variables into the small data region and other variables outside of it. Typically the choice is based on size of the variable. Small data pointers are typically used when the machine has plenty of registers and it takes 2 or more instructions to build the address of a random variable in memory with load high/load low type instructions, and the small data pointer has the upper half already loaded, and uses special relocations to access the variable based off of the difference of a special symbol. 2) Even without a small data pointer, a compiler might decide to sort the variables emitted based on either size or number of accesses to take advantage of instructions with smaller offsets. 3) The above mentioned global, non-initialized variables (ie, the so-called 'common' variables). Where the linker puts the variables into the bss section in any order it chooses. For example, the VMS linker used to sort common variables alphabetically. 4) For static variables, the compilation system might decide to omit the variable until it sees a reference to the variable, and if the first variable is referenced in one function, and the second is referenced several functions later. 5) At some point in the future, on machines with many more registers than the normal 32, the linker might see all references to a variable, and decide to put it in a static register rather than memory. 6) A checkout compiler could randomly order things specifically to catch these type of errors (the problem with the normal checkout compilers that I'm aware of, is that the kernel uses structs to talk to real devices and interact with system calls with fixed layouts). -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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/
Re: [PATCH] removal of static foo = 0
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. Try it. They _will_ link together. - 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/
Re: [PATCH] removal of static foo = 0
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 specs and I didn't find anything. So I wasn't sure
if I missed the information in the specs or not. I never investigated on it
because I always considered it bad coding regardless the fact it's guaranteed
to generate the right asm with the _current_ tools.
Andrea
-
The following shell-script shows that gcc-2.8.1 produces code with
data allocations adjacent. However, they are reversed!
cat - EOF x.c
int a, b;
EOF
gcc -c -o x.o x.c
cat - EOF y.c
extern int a;
extern int b;
int main() {
printf("a=%p\n", a);
printf("b=%p\n", b);
return 0;
}
EOF
gcc -o y y.c x.o
./y
a=0x804a42c
b=0x804a428
The output shows variable 'a' as being in the higher address.
So, it's not good to assume anything about so-called adjacent
variables.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
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/
Re: [PATCH] removal of static foo = 0
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 variables in sequence, and where it could access them either by referencing each by absolute address, with relocation (so that objdump-patcher could change that), or by generating a pointer and using pointer-relative addressing or pointer increment (so we only get one relocation and never know what may go wrong with the other variables). - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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/
Re: [PATCH] removal of static foo = 0
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 either, but we certainly rely on that behaviour somewhere.
Just to make an example fs/dquot.c:
int nr_dquots, nr_free_dquots;
kernel/sysctl.c:
{FS_NRDQUOT, "dquot-nr", nr_dquots, 2*sizeof(int),
The above is ok also on mips in practice though.
That needs to be fixed ASAP to use an array (not a structure). It is simply
wrong to depend on two variables winding up in at adjacent offsets.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
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/
Re: [PATCH] removal of "static foo = 0"
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't the compiler just leave out explicit zeros from the
>> 'initial data' segment then? Seems like it ought to be tought to..
>
>Because sometimes it matters. For example, in kernel mode (and certainly for
>embedded programs that I'm more familiar with), the kernel does go through and
>zero out the so called BSS segment, so that normally uninitialized static
>variables will follow the rules as laid out under the C standards (both C89 and
>C99). I can imagine however, that the code that is executed before the BSS
>area is zeroed out needs to be extra careful in terms of statics that it
>references, and those must be hand initialized.
Since that code is already careful to hand initialize what
it needs and explicitly zeroes the BSS, that sounds like an argument
that it *is* safe to change gcc to move data that is intialized to
all zeroes into bss, either as a compiler option or even not
optionally.
I am not a gcc hacker, but it looks to me like one could
copy the code from output_constant and the functions that it
calls (in gcc-2.95.2/gcc/gcc/varasm.c) to walk the tree to figure
out if the data was all zeroes. I even started writing a routine
for assemble_variable to call to try to test just for the integer case
(basically just by cutting and pasting code). I include it here just
to illustrate. Note: this code doesn't even type check properly when
I try to compile it, so I know it's very wrong, but it's as good as
posting pseudo code to explain my thinking).
void
clear_zero_initialization(tree decl)
{
tree exp = DECL_INITIAL(decl);
enum tree_code code;
if (exp == NULL)
return;
code = TREE_CODE (TREE_TYPE (exp));
if (lang_expand_constant)
exp = (*lang_expand_constant) (exp);
while ((TREE_CODE (exp) == NOP_EXPR
&& (TREE_TYPE (exp) == TREE_TYPE (TREE_OPERAND (exp, 0))
|| AGGREGATE_TYPE_P (TREE_TYPE (exp
|| TREE_CODE (exp) == NON_LVALUE_EXPR)
exp = TREE_OPERAND (exp, 0);
if (code == INTEGER_TYPE && exp == const0_rtx)
DECL_INITIAL(decl) = NULL;
}
At the moment, I have started daydreaming about instead
writing an "elf squeezer" to do this and other space optimizations
by modifying objdump. However, I do think that such an improvement
to gcc would be at least a bit useful to the larger user base than
just those people who use binutils-based systems.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
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/
Re: [PATCH] removal of "static foo = 0"
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 explicit zeros from the > 'initial data' segment then? Seems like it ought to be tought to.. Because sometimes it matters. For example, in kernel mode (and certainly for embedded programs that I'm more familiar with), the kernel does go through and zero out the so called BSS segment, so that normally uninitialized static variables will follow the rules as laid out under the C standards (both C89 and C99). I can imagine however, that the code that is executed before the BSS area is zeroed out needs to be extra careful in terms of statics that it references, and those must be hand initialized. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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/
Re: [PATCH] removal of "static foo = 0"
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 become so big that it really needs universal debugging macros
> instead of comments. Comments are waste of brain, if the same
> can be explained by long variable names and debug macros.
>
> static Subsystem_module_LocalVariableForThisPurpose;
>
> int Subsytem_module_function_this_and_that(){
> DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose == 0 );
> DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node !=
>NULL )
> }
>
>
> Those macros would be acceptable if they are unified and taken to
> kernel configuration level, so it would be easy to switch them in/out
> not only as boolean option but systematically for different levels,
> subsystems and modules.
I leave "debugging" enabled in the drivers I submit. This allows me to
tell customers who are having "It won't detect my card" problems to
enable the debugging output. Most of the time this leads to a resolution
within minutes of me getting the debugging output log.
Sure it will slow the driver down a bit, because of all those bit-test
instructions in the driver. If it bothers you, you get to turn it
off. If you are capable of that, you are also capable enough to turn
it back on when neccesary.
The debug asserts that trigger during normal operation are what make
the Linux kernel stable. Problems get spotted at an early
stage. Problems get fixed. Microsoft disables all debugging before
shipping stuff. That means they don't get useful bugreports from the
field ("When I do this, the system sometimes locks" compared to
"my system crashes with: 'panic: sk buff underrun at 0xc0123456'").
This was discussed and a decision was taken that we're on the good
track around 5 years ago. I guess that there is some new blood to be
convinced nowadays...
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
-
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/
Re: [PATCH] removal of "static foo = 0"
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: > > /* > * Clear BSS first so that there are no surprises... > */ > xorl %eax,%eax > movl $ SYMBOL_NAME(__bss_start),%edi > movl $ SYMBOL_NAME(_end),%ecx > subl %edi,%ecx > cld > rep > stosb > > ... speaking of which (putting asbesto on and hiding from Andries ;) can't > we optimize this code to move words at a time and not bytes ;) There's better way: put bss clearing code at beggining of .C code and do it with memset. [x86-64 does it this way.] It is both more obvious [no assembly] and faster [memset is optimized]. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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/
Re: [PATCH] removal of "static foo = 0"
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 start at zero. I've written it this > way to remind of the fact' > > Sure it generates the same code > 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 programmers without making gcc make bad code. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/
Re: [PATCH] removal of "static foo = 0"
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 thought, reading K > might also be useful. IOW, no offense, but your C is bad beyond belief. Yep, very true. aironet4500_proc.c is ugly. And is because there is quickly handwirtten something that should have been generic for kernel for some long time, not for every driver-writer to reinvent a wheel. Note that there is something that virtually elliminates need for exact user<->kernel level interfaces and userlevel kerneldata manipulation programs and lots of other maintenance pains. And it does it in quite short sentences. Plus, half of that file is direct repeating of some non-exported kernel functions. But, if you think you can do better, then look into aironet4500_rid.c and handcode it (like real K people do), instead of using aironet4500_proc.c to operate on it. Also, pcmcia/aironet4500_cs.c has lots of ugly parts. Those which are related to stupid masohistic code repetitions due to pcmcia package interface being "cutting edge optimal stupid" The same true is that 2.4 kernel is, in commercial production sense, late for 6 months. And reason being that the codebase and testing becomes unmanageable. And it becomes unmanageable, because some people only read K and try to optimize last bit out of it with using and old book. I'd really propose again: 1. universal debug macros 2. universalt user-kernelspace configuration interface via proc/sys I'd really like C++, but it can be done with C and macros. Some years ago I even managed to write something like stl container withing C and with macros. That was really screwy thing. elmer. - 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/
Re: [PATCH] removal of "static foo = 0"
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, if the same
> can be explained by long variable names and debug macros.
>
> static Subsystem_module_LocalVariableForThisPurpose;
>
> int Subsytem_module_function_this_and_that(){
> DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose == 0 );
> DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node !=
>NULL )
> }
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 thought, reading K
might also be useful. IOW, no offense, but your C is bad beyond belief.
-
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/
Re: [PATCH] removal of "static foo = 0"
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 universal debugging macros
instead of comments. Comments are waste of brain, if the same
can be explained by long variable names and debug macros.
static Subsystem_module_LocalVariableForThisPurpose;
int Subsytem_module_function_this_and_that(){
DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose == 0 );
DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node !=
NULL )
}
Those macros would be acceptable if they are unified and taken to
kernel configuration level, so it would be easy to switch them in/out
not only as boolean option but systematically for different levels,
subsystems and modules.
elmer.
-
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/
Re: [PATCH] removal of "static foo = 0"
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 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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/
Re: [PATCH] removal of "static foo = 0"
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 default option, please.
> Because there are valid cases where a programmer things "this is in .data"
That's what __attribute__ ((section (".data"))) is for.
> and that means this should be in .data. Think of binary patching an object
> as one valid example (there may be others, I forgot).
can you think of any valid examples that apply to the kernel ?
-
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/
Re: [PATCH] removal of "static foo = 0"
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, I seem to remember that back in the dark ages, the BSS wasn't cleared. It said so somewhere in the Kernel Hackers Guide, I think. Regards, bert hubert -- PowerDNS Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - 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/
Re: [PATCH] removal of "static foo = 0"
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; unfortunately this doesn't seem to be the case, which sounds like something to take up with the gcc developers. - 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/
Re: [PATCH] removal of "static foo = 0"
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 gets better, and I get nervous. > >> > >> Can somebody stop this train load of bunk? > >> > >> Uninitialized global variables always have a initial value of > >> zero. Static or otherwise. Period. > > > >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 start at zero. I've written it this > >way to remind of the fact' > > > >Sure it generates the same code > > 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." Nope. It doesn't say that. Maybe if you wrote the code. But if Andries or I had written that line, it just says that when written the programmer thought about the initial value, and that the initial value matters on this variable. It is a concise form of documentation. As Andries explained, this can also be done with comments or with static int a /* = 0 */; However, I like the "=0" variant much better. If you're worried about the inefficiency of the compiler, take it up with the compiler guys. Or write an extra preprocessor step or something like that. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - 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/
Re: [PATCH] removal of "static foo = 0"
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." ~ 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: /* * Clear BSS first so that there are no surprises... */ xorl %eax,%eax movl $ SYMBOL_NAME(__bss_start),%edi movl $ SYMBOL_NAME(_end),%ecx subl %edi,%ecx cld rep stosb ... speaking of which (putting asbesto on and hiding from Andries ;) can't we optimize this code to move words at a time and not bytes ;) Regards, Tigran - 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/
Re: [PATCH] removal of "static foo = 0"
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 the > 'initial data' segment then? Seems like it ought to be tought to.. yes, taught to, _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. Think of binary patching an object as one valid example (there may be others, I forgot). Regards, Tigran - 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/
Re: [PATCH] removal of "static foo = 0"
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 try personnal insult to get your non-point across? There is no more discussion to be had; this has rapidly decended into yet another flaming match which I do not want to continue. Please decist, and we'll all keep our opinions to ourselves on this matter, ok? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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/
Re: [PATCH] removal of "static foo = 0"
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 a and b, where > a requires initialization and b does not require it? Distinguishing between variables initialized to zero and those not requiring initialization is a good idea, but honestly, how common are static variables declared at the top level which don't require initialization? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "RAM = Rarely Adequate Memory" - 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/
Re: [PATCH] removal of static foo = 0
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 a and b, where a requires initialization and b does not require it? Distinguishing between variables initialized to zero and those not requiring initialization is a good idea, but honestly, how common are static variables declared at the top level which don't require initialization? Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ "RAM = Rarely Adequate Memory" - 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/
Re: [PATCH] removal of static foo = 0
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 try personnal insult to get your non-point across? There is no more discussion to be had; this has rapidly decended into yet another flaming match which I do not want to continue. Please decist, and we'll all keep our opinions to ourselves on this matter, ok? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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/
Re: [PATCH] removal of static foo = 0
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 the 'initial data' segment then? Seems like it ought to be tought to.. yes, taught to, _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. Think of binary patching an object as one valid example (there may be others, I forgot). Regards, Tigran - 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/
Re: [PATCH] removal of static foo = 0
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." ~ 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: /* * Clear BSS first so that there are no surprises... */ xorl %eax,%eax movl $ SYMBOL_NAME(__bss_start),%edi movl $ SYMBOL_NAME(_end),%ecx subl %edi,%ecx cld rep stosb ... speaking of which (putting asbesto on and hiding from Andries ;) can't we optimize this code to move words at a time and not bytes ;) Regards, Tigran - 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/
Re: [PATCH] removal of static foo = 0
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 gets better, and I get nervous. Can somebody stop this train load of bunk? Uninitialized global variables always have a initial value of zero. Static or otherwise. Period. 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 start at zero. I've written it this way to remind of the fact' Sure it generates the same code 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." Nope. It doesn't say that. Maybe if you wrote the code. But if Andries or I had written that line, it just says that when written the programmer thought about the initial value, and that the initial value matters on this variable. It is a concise form of documentation. As Andries explained, this can also be done with comments or with static int a /* = 0 */; However, I like the "=0" variant much better. If you're worried about the inefficiency of the compiler, take it up with the compiler guys. Or write an extra preprocessor step or something like that. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - 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/
Re: [PATCH] removal of static foo = 0
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; unfortunately this doesn't seem to be the case, which sounds like something to take up with the gcc developers. - 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/
Re: [PATCH] removal of static foo = 0
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, I seem to remember that back in the dark ages, the BSS wasn't cleared. It said so somewhere in the Kernel Hackers Guide, I think. Regards, bert hubert -- PowerDNS Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - 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/
Re: [PATCH] removal of static foo = 0
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 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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/
Re: [PATCH] removal of static foo = 0
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 universal debugging macros
instead of comments. Comments are waste of brainfingerpower, if the same
can be explained by long variable names and debug macros.
static Subsystem_module_LocalVariableForThisPurpose;
int Subsytem_module_function_this_and_that(){
DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose == 0 );
DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes-node !=
NULL )
}
Those macros would be acceptable if they are unified and taken to
kernel configuration level, so it would be easy to switch them in/out
not only as boolean option but systematically for different levels,
subsystems and modules.
elmer.
-
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/
Re: [PATCH] removal of static foo = 0
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 brainfingerpower, if the same
can be explained by long variable names and debug macros.
static Subsystem_module_LocalVariableForThisPurpose;
int Subsytem_module_function_this_and_that(){
DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose == 0 );
DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes-node !=
NULL )
}
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 thought, reading KR
might also be useful. IOW, no offense, but your C is bad beyond belief.
-
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/
Re: [PATCH] removal of static foo = 0
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 thought, reading KR might also be useful. IOW, no offense, but your C is bad beyond belief. Yep, very true. aironet4500_proc.c is ugly. And is because there is quickly handwirtten something that should have been generic for kernel for some long time, not for every driver-writer to reinvent a wheel. Note that there is something that virtually elliminates need for exact user-kernel level interfaces and userlevel kerneldata manipulation programs and lots of other maintenance pains. And it does it in quite short sentences. Plus, half of that file is direct repeating of some non-exported kernel functions. But, if you think you can do better, then look into aironet4500_rid.c and handcode it (like real KR people do), instead of using aironet4500_proc.c to operate on it. Also, pcmcia/aironet4500_cs.c has lots of ugly parts. Those which are related to stupid masohistic code repetitions due to pcmcia package interface being "cutting edge optimal stupid" The same true is that 2.4 kernel is, in commercial production sense, late for 6 months. And reason being that the codebase and testing becomes unmanageable. And it becomes unmanageable, because some people only read KR and try to optimize last bit out of it with using and old book. I'd really propose again: 1. universal debug macros 2. universalt user-kernelspace configuration interface via proc/sys I'd really like C++, but it can be done with C and macros. Some years ago I even managed to write something like stl container withing C and with macros. That was really screwy thing. elmer. - 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/
