Messages in this thread | | | Date | Tue, 21 Mar 2000 14:00:25 +0000 | From | Andrew Morton <> | Subject | Re: [patch] 2.3.99-pre3-3: dev_alloc_name |
| |
Alan Cox wrote: > > > > This is not correct, Linus please don't apply. > > I think it is, Jeff. Try this patch: > > Ok you are demonstrating a compiler feature we really don't need. You do need > to make a new string. You also therefore need to fix every case we free a > network device, remembering the names may pretty arbitarily be a constant. > > Is there a way to tell egcs to give unique strings for a given array.
Here's the story:
struct thing { char *s; int i; };
struct thing t1 = { "foo", 4 }; struct thing t2 = { "foo", 4 };
Compiled normally this will put a single instance of "foo" into the read-only data section .rodata.
Compiled with '-fwritable-strings' the compiler will put _two_ copies of "foo" into the writable data section .data.
However I'm not sure this is a good idea - it will prevent quite a bit of (usually desirable) string sharing. One embedded systems the .data section would have to be copied out to RAM at boot, so -fwritable-strings will use more RAM.
Plus... Shouldn't the kernel be marking the .rodata pages as read-only? We should really be faulting on a write to .rodata (and .text!).
The code Tim has found won't work if, for example, the kernel is put in ROM. I think strdup()ing it is the right thing to do.
> If not > then we probably need to preprocess the file (Im not doing this by hand that > is for sure) to generate lots of little 8 byte arrays and link each structure > element to its own private array entry.
But they really should be moved out of .rodata if we're going to write to them.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |