Re: [PATCH 0/4] __cpuinitconst and __devinitconst

On Mon, Jan 14, 2008 at 08:33:35AM +0000, Jan Beulich wrote:
Sam Ravnborg <sam@xxxxxxxxxxxx> 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.
Will fix that in next patch. My focus was on the concept when I did the
patch but it is dead easy to fix for ll archs at once.

Also, to shorten the
names a little, how about .{cpu,mem,dev}init.rodata?
Good suggestion - will use these.

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).

I need to play a little with this before I make up my mind.
I do not like the concpet of hiding the const too much - it will
be non-obvious why the compiler complains if the only thing that
distingush const from non-const is a small capital 'c' within
__cpucinitdata (versus __cpuinitdata).

It can always be an incremental patch as my concpet does not prevent
it and we have only a few const __initdata variables.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 001/002] scripts/mod/modpost.c: New option -E to load extra symbols
    ... When building kernel modules that depend on other modules not in the main ... This situation occurs when modpost processes the new module's symbols. ... This patch works together with the second patch. ... kernel_read = optarg; ...
    (Linux-Kernel)
  • [PATCH 001/002] scripts/mod/modpost.c: New option -E to load extra symbols
    ... This patch adds a new command line option -E to modpost, ... When building kernel modules that depend on other modules not in the main ... The patch adds a new command line option -E to modpost which expects a symbol ...
    (Linux-Kernel)
  • kbuild:
    ... confident that keeping the checks in modpost is good. ... In a follow-up mail I will post the result of a run with this patch. ... Section mismatch is identified as references to .init* ...
    (Linux-Kernel)
  • Re: Migrate pages from a ccNUMA node to another - patch
    ... Documentation/CodingStyle. ... while you're developing a patch, it's best to try and refrain from ... dump_vma(const struct vm_area_struct * const vma) ... Can you separate this out under its own config option? ...
    (Linux-Kernel)
  • Re: [PATCH] De-constify sched.h
    ... constify sched.h" or apply the following patch instead. ... I learned about this revert only ... the const markers indeed had no real purpose in terms of code generation ...
    (Linux-Kernel)