All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@petalogix.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Ingo Molnar <mingo@elte.hu>, lkml <linux-arch@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Microblaze noMMU/MMU merge
Date: Tue, 21 Apr 2009 11:46:06 +0200	[thread overview]
Message-ID: <49ED95DE.5070804@petalogix.com> (raw)
In-Reply-To: <20090421082523.GA19864@uranus.ravnborg.org>

Sam Ravnborg wrote:
> On Tue, Apr 21, 2009 at 09:45:47AM +0200, Michal Simek wrote:
>   
>> Hi All,
>>
>> I would like to say your opinion about putting together Microblaze MMU
>> arch to noMMU version.
>>
>> In C code will be #ifdef CONFIG_MMU ... #endif  or #ifndef.
>>
>> Here is proposal for headers. The similar style is used in m68k but I
>> would like to have the same code
>> for both archs in main file.
>>
>> #ifndef _ASM_MICROBLAZE_PAGE_H
>> #define _ASM_MICROBLAZE_PAGE_H
>>
>> code for noMMU and MMU which is the same for both.
>>
>> #ifdef __uClinux__
>> #include "page_no.h" -> noMMU specific
>> #else
>> #include "page_mm.h"-> MMU specific
>> #endif
>> #endif /* _ASM_MICROBLAZE_PAGE_H */
>>     
>
> Use dedicated header files for nommu / mmu only when it is really necessary.
>
> In headers that are _NOT_ exported you can use CONFIG_MMU to test
> if you are building for MMU or not - which is more readable.
>  
> The reason why you cannot use CONFIG_MMU in exported headers
> are that CONFIG_MMU is not valid in the userspace headers (not set/unset).
>
> In the optimal case you have no conditionals in the exported haders
> and then just use CONFIG_MMU all over.
>   
ok. I'll create first proposal and you can look if is ok or not.

Thanks.
Michal

> 	Sam
>
>   


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

  reply	other threads:[~2009-04-21  9:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-21  7:45 Microblaze noMMU/MMU merge Michal Simek
2009-04-21  7:57 ` Paul Mundt
2009-04-21  8:25 ` Sam Ravnborg
2009-04-21  9:46   ` Michal Simek [this message]
2009-04-21 11:06 ` Greg Ungerer

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=49ED95DE.5070804@petalogix.com \
    --to=michal.simek@petalogix.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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.