All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: "Sam Ravnborg" <sam@ravnborg.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] __cpuinitconst and __devinitconst
Date: Mon, 14 Jan 2008 09:25:54 +0000	[thread overview]
Message-ID: <478B38B2.76E4.0078.0@novell.com> (raw)
In-Reply-To: <20080114091728.GA6674@uranus.ravnborg.org>

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

That's the main reason I preferred __{cpu,mem,dev}initconst, as it
makes it more obvious that the declared thing is 'const'.

Jan


  reply	other threads:[~2008-01-14  9:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-11  8:55 [PATCH 0/4] __cpuinitconst and __devinitconst Jan Beulich
2008-01-11 19:44 ` Sam Ravnborg
2008-01-12 20:56   ` Sam Ravnborg
2008-01-13  7:30     ` Sam Ravnborg
2008-01-13 21:42       ` Sam Ravnborg
2008-01-14  8:33         ` Jan Beulich
2008-01-14  9:17           ` Sam Ravnborg
2008-01-14  9:25             ` Jan Beulich [this message]
2008-01-14  9:43               ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=478B38B2.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.