All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@petalogix.com>
To: monstr@monstr.eu
Cc: Arnd Bergmann <arnd@arndb.de>,
	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: Wed, 29 Apr 2009 16:03:16 +0200	[thread overview]
Message-ID: <49F85E24.5050801@petalogix.com> (raw)
In-Reply-To: <49F85C27.9000308@monstr.eu>

Michal Simek wrote:
> Hi all,
>
> 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) })
>
>
> 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
>
> For microblaze case are used both -> that's definitely not correct.
>
> 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?
>
>         location                     name           location      struct mm_segment_t
> s390:   processor.h/thread_struct    mm_segment     processor.h   __u32 ar4
> alpha:  thread_info.h/thread_info    addr_limit     processor.h  unsigned long seg
> x86:    thread_info.h/thread_info    addr_limit     processor.h  unsigned long seg
> ia64:   thread_info.h/thread_info    addr_limit     processor.h  unsigned long seg
> mips:   thread_info.h/thread_info    addr_limit     processor.h  unsigned long seg
> um:     thread_info.h/thread_info    addr_limit     uaccess.h    unsigned long seg
> frv:    thread_info.h/thread_info    addr_limit     segment.h    unsigned long seg
> cris:   thread_info.h/thread_info    addr_limit     segment.h    unsigned long seg
> sh:     thread_info.h/thread_info    addr_limit     segment.h    unsigned long seg
> h8300:  not_used     not_used                       segment.h    unsigned long seg
> nm10300:thread_info.h/thread_info    addr_limit     processor.h  unsigned long seg
> arm:    thread_info.h/thread_info    addr_limit     thread_info.h  typedef unsigned long mm_segment_t;
> parisc: thread_info.h/thread_info    addr_limit     processor.h  int seq
> m32r:   thread_info.h/thread_info    addr_limit     processor.h  unsigned long seg
> xtensa: thread_info.h/thread_info    addr_limit     segment.h    unsigned long seg
> avr32:  not_used     not_used                       uaccess.h    unsigned int is_user_space;
> sparc:  processor_32.h/thread_struct  current_ds    processor_32.h  int seg
> m68k:   not_used     not_used                       segment.h    unsigned long seg
> blackfin:thread_info.h/thread_info    addr_limit    thread_info.h  typedef unsigned long mm_segment_t;
> powerpc: processor.h/thread_struct  current_ds     processor.h  unsigned long seg
>
>
> There is really mess in it and I would like to have good solution for Microblaze and I think
> that will be good to have any generic solution and remove code duplication.
>
> Thanks for your comments,
> Michal
>
>   
+ move some macros to generic location too.
#define get_ds()      (KERNEL_DS)

+ get_fs(), set_fs(), segment_eq() after sync changes above

Michal





-- 
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-29 14:03 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 [this message]
2009-04-30 13:50 ` Arnd Bergmann
2009-04-30 14:28   ` Michal Simek

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=49F85E24.5050801@petalogix.com \
    --to=michal.simek@petalogix.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=john.williams@petalogix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=monstr@monstr.eu \
    /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.