From: Michal Simek <monstr@monstr.eu>
To: Arnd Bergmann <arnd@arndb.de>
Cc: John Williams <john.williams@petalogix.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: Memory limits - mm_segment_t - MAKE_MM_SEG
Date: Thu, 30 Apr 2009 16:28:36 +0200 [thread overview]
Message-ID: <49F9B594.6050000@monstr.eu> (raw)
In-Reply-To: <200904301550.35112.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 29 April 2009, Michal Simek wrote:
>> I look at some things which I need to clear for MMU Microblaze patches and
>> I would like to know your opinion about.
>>
>> First of all I found that almost all archs use MAKE_MM_SEG macro which
>> should be good to move to generic location (asm-generic/uaccess.h ? )
>> #define MAKE_MM_SEG(s) ((mm_segment_t) { (s) })
>
> I have a generic uaccess.h queued up, which I'm planning to submit for
> 2.6.30 that includes this.
Please CC me for this patch. Thanks.
>
>> The second thing is about place where is stored limit for processes -> mm_segment_t structure
>>
>> Where is the proper location for storing mm_segment_t? Some arch use
>> thread_info some of them thread_struct
>
> The method that is used here is different on some architectures.
> Most of them use the address limit, which is a property of the
> thread, and sensibly belongs into the thread_info. s390 and possibly
> others have separate address spaces for user access and use a CPU
> feature for this, which belongs into thread_struct.
Great. I'll use only thread_info structure.
>
>> Here is the small table for cpus which are in linux kernel and location and type for them.
>> The most of them uses thread_info structure for it and name is addr_limit.
>> The location of mm_segment_t is different too -> we should move it to any generic location too.
>> What do you think?
>
> Sounds fair to me. I think uaccess.h is the best place for this, or maybe
> a new mm_segment.h, but not segment.h which is used traditionally for
> real segments on x86.
OK. I'll move all things from segment.h to uaccess.h in my next branch.
Michal
>
> Arnd <><
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
prev parent reply other threads:[~2009-04-30 14:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-29 13:54 Memory limits - mm_segment_t - MAKE_MM_SEG Michal Simek
2009-04-29 14:03 ` Michal Simek
2009-04-30 13:50 ` Arnd Bergmann
2009-04-30 14:28 ` Michal Simek [this message]
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=49F9B594.6050000@monstr.eu \
--to=monstr@monstr.eu \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=john.williams@petalogix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.