All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@snapgear.com>
To: Robin Getz <rgetz@blackfin.uclinux.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Date: Wed, 02 May 2007 21:32:10 +1000	[thread overview]
Message-ID: <463876BA.9020005@snapgear.com> (raw)
In-Reply-To: <200705020458.06595.rgetz@blackfin.uclinux.org>


Hi Robin,

Robin Getz wrote:
> On Wed 2 May 2007 01:23, Greg Ungerer pondered:
>> Hi All,
>>
>> An update of the uClinux (MMU-less) code against 2.6.21.
>> A lot of cleanups, and a few bug fixes.
>>
>> Ahead is more changes to finalize platform device support
>> for the new style ColdFire serial driver, and switching to
>> the generic irq code.
>>
>> http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz
> 
> Greg:
> 
> Is is possible to split out the m68k stuff from the generic nommu stuff?

I could do that. Usually the actual mm changes have been
a pretty small set of this. Often only 1 or 2 patches.


> (or 
> maybe I am missing the point of this patch? - it is for review/inclusion into 
> the -mm tree, or just for end users wanting to use 2.6.21?)

This is specifically for review and inclusion in main line.


> The patch is labeled uClinux (MMU-less), which I read as generic, but the 
> majority has to do with only m68knommu.

Well, if any non-mmu architecture people sent me patches that
made sense for me to push upstream I would include them here.
But that doesn't happen very often. They generally do it
themselves.

Historically the first -uc patches had m68knommu, h8300 and v850
as well as the non-mmu changes in it.


>  arch/m68knommu/Kconfig                   |   12
>  arch/m68knommu/Makefile                  |    4
>  arch/m68knommu/kernel/process.c          |    2
>  arch/m68knommu/kernel/setup.c            |  116 +---
>  arch/m68knommu/kernel/time.c             |    9
>  arch/m68knommu/mm/memory.c               |  100 ---
>  arch/m68knommu/platform/5206/config.c    |    8
>  arch/m68knommu/platform/5206e/config.c   |    7
>  arch/m68knommu/platform/520x/config.c    |  122 ++++
>  arch/m68knommu/platform/523x/config.c    |    8
>  arch/m68knommu/platform/5249/config.c    |   51 +
>  arch/m68knommu/platform/5272/config.c    |    7
>  arch/m68knommu/platform/527x/config.c    |    7
>  arch/m68knommu/platform/528x/config.c    |    7
>  arch/m68knommu/platform/5307/config.c    |    5
>  arch/m68knommu/platform/5307/entry.S     |   20
>  arch/m68knommu/platform/5307/ints.c      |   23
>  arch/m68knommu/platform/5307/timers.c    |   10
>  arch/m68knommu/platform/532x/config.c    |   46 +
>  arch/m68knommu/platform/5407/config.c    |    7
>  arch/m68knommu/platform/68328/config.c   |    3
>  arch/m68knommu/platform/68360/config.c   |    2
>  arch/m68knommu/platform/68EZ328/config.c |    2
>  arch/m68knommu/platform/68VZ328/config.c |    7
>  include/asm-m68knommu/dma.h              |    2
>  include/asm-m68knommu/hw_irq.h           |    4
>  include/asm-m68knommu/m528xsim.h         |    3
>  include/asm-m68knommu/m532xsim.h         |   85 ++-
>  include/asm-m68knommu/machdep.h          |   50 -
>  include/asm-m68knommu/mcfuart.h          |   11
>  include/asm-m68knommu/pgtable.h          |    7
>  include/asm-m68knommu/timex.h            |   24
>  include/asm-m68knommu/uaccess.h          |   11
>  drivers/net/fec.c                        |   71 +-
>  drivers/serial/68328serial.c             |   59 --
>  drivers/serial/mcf.c                     |  826 +++++++++++++++++++++++++++++
> 
> The only generic stuff is:
> 
>  Makefile                                 |    2
>  drivers/pci/pci.c                        |    2
>  fs/binfmt_flat.c                         |    2
>  fs/namei.c                               |    2
>  mm/nommu.c                               |   15
>  mm/page_alloc.c                          |    8
> 
> I looked at those, and had a question:
> 
> (copy and paste screws up the formatting, sorry):
> 
>> diff -Naur linux-2.6.21/fs/namei.c linux-2.6.21-uc0/fs/namei.c
>> --- linux-2.6.21/fs/namei.c     2007-05-01 17:12:53.000000000 +1000
>> +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.000000000 +1000
>> @@ -120,12 +120,14 @@
>>         int retval;
>>         unsigned long len = PATH_MAX;
>>
>> +#ifdef CONFIG_MMU
>>         if (!segment_eq(get_fs(), KERNEL_DS)) {
>>                 if ((unsigned long) filename >= TASK_SIZE)
>>                         return -EFAULT;
>>                 if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
>>                         len = TASK_SIZE - (unsigned long) filename;
>>         }
>> +#endif
>>
>>         retval = strncpy_from_user(page, filename, len);
>>         if (retval > 0) {
> 
> I was trying to understand why we don't want to do the same checking on noMMU?

The problem is on systems that have RAM mapped at high physical
addresses. TASK_SIZE may well be a numerically smaller number
than the address range that RAM sits in. So this test fails when
it shouldn't.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a Secure Computing Company      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

  reply	other threads:[~2007-05-02 11:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-02  5:23 [PATCH]: linux-2.6.21-uc0 (MMU-less updates) Greg Ungerer
2007-05-02  8:58 ` Robin Getz
2007-05-02 11:32   ` Greg Ungerer [this message]
2007-05-03 10:55     ` Robin Getz
2007-05-03 11:03       ` Greg Ungerer
2007-05-03 11:35         ` Robin Getz
2007-05-03 13:30           ` Greg Ungerer
2007-05-04 16:12             ` Robin Getz
2007-05-06 11:44               ` Russell King
2007-05-07 11:59                 ` Greg Ungerer
2007-05-07  1:24             ` Paul Mundt
2007-05-02  9:06 ` Christoph Hellwig
2007-05-02 10:37   ` 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=463876BA.9020005@snapgear.com \
    --to=gerg@snapgear.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgetz@blackfin.uclinux.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.