lkml.org 
[lkml]   [2008]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] __cpuinitconst and __devinitconst
>>> Sam Ravnborg <sam@ravnborg.org> 13.01.08 22:42 >>>
>> And I found another small buglet too. I hope to post a complete
>> solution later today.
>
>The modpost bits turned out to take longer than expected so
>they are not done yet. The problem was the modpost structure
>were not prepared for adding such additional chacks.
>So I reworked those bits and the patch has been sent out for review.
>
>What follows here is the changes for init.h + all linker scripts
>to show the idea.
>
>Next step is to beat modpost in shape and to post this on linux-arch.
>
>Note - in -mm there are changes to init.h so the logic
>to decide type of __meminit notation is much simpler.

Yes, I certainly like this concept. What I would have wanted in that patch,
though, is that the read-only data would right away be included in
RODATA() rather than being put in DATA_DATA. Also, to shorten the
names a little, how about .{cpu,mem,dev}init.rodata?

The one thing that I'm not sure is really consistent yet wrt. the
constification is that now you need to write e.g.

static const char __cpuinitcdata example[];

and (accidentally) omitting the 'const' (as it's really an apparently
redundant thing now) as in

static char __cpuinitcdata example[];

will cause section type conflicts (at the compiler or linker level). I
therefore think that the 'const' should really be part of the
__{cpu,mem,dev}cdata definitions (requiring the attribute to be
placed properly, namely placement at the end of a declaration as
is possible with __{cpu,mem,dev}initdata is then not an option here).

Jan



\
 
 \ /
  Last update: 2008-01-14 09:35    [W:0.052 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site