lkml.org 
[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.078 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site