public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@snapgear.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH]: linux-2.5.42uc1 (MMU-less support)
Date: Thu, 17 Oct 2002 00:41:45 +1000	[thread overview]
Message-ID: <3DAD7AA9.1060207@snapgear.com> (raw)
In-Reply-To: 20021015181609.A31647@infradead.org


Hi Christoph,

Christoph Hellwig wrote:

> There are a bunch of CVS .#* files left from this one.


Cleaned out now.


> v850_defs.h wants updating to the generic generate-asm-offsets.h
> mechanism (check the toplevel Makefile)


Miles cleaned this up.


> Please stop the ugly symlink hell with the linker scripts -
> we have vmlinux.lds.S for that.


Hmph. Hardly seems any better...


> Could you please explain the rootfs hacks in v850?
> I don't think we want those in mainline but rather generic
> initrd/initramfs.
> 
> Also please remove arch/v850/sim/* - that stuff doesn't
> belong into the kernel tree.


Done.



>>2. cleaned up mm/page_alloc.c
> 
> Why do you put set_page_refs into a header?


It looked might it might be usefull elsewhere.
(but currently isn't used for anything else).


> Separating it out
> looks good to me, but IMHO it should stay in page_alloc.c.
> BTW, are you sure that you don't need to set the refs in the
> other caller of prep_new_page?  To me it looks like you should
> and then you could merge it into prep_new_page.


No, you don't want that.


> Also, what is CONFIG_CONTIGUOUS_PAGE_ALLOC doing?  It seems not
> fully implemented but adds lots of uglieness :)


It was a second allocator that more cleverly allocated large
memory chunks - not using the power of 2 allocator. I have
not carried this into the 2.5 patches. Very nice to have,
since you suffer much more from memory fragmentation without
VM. But not strictly neccessary, and to minimize and simplify
the current patch sets I left it out.

Cleanup out all references to it now.


> CONFIG_NO_MMU_LARGE_ALLOCS might want a saner name, btw
> (CONFIG_LARGE_ALLOCS?).


Yes, no doubt the NO_MMU name is universally disliked :-)
Changed to COFNIG_LARGE_ALLOCS now.


> 
> General commets:
> - Config.in files have three-space, not two-space indentation



Fixed.


> - I don't think you want to keep around the old binfmt_flat


This isn't old. It is the primary format used on uClinux. ELF
and a.out are not practical, since you would need to do the final
link/locate on them at exec load time (you won't know what address
in memory they will get loaded to until them). You don have the
VM luxary of just locating it at a fixed address at compile time.

FLAT format is a light weight, mostly architecture independant
way to carry around relocs, and to keep the program binaries
small.


>   format when merghin into mainline
> - MAX_SHARED_LIBS is never used

Another "feature" I have not carried into 2.5. Removed.


Thanks
Greg





-- 
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg@snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com


  reply	other threads:[~2002-10-16 14:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-15 15:25 [PATCH]: linux-2.5.42uc1 (MMU-less support) Greg Ungerer
2002-10-15 17:16 ` Christoph Hellwig
2002-10-16 14:41   ` Greg Ungerer [this message]
2002-10-16 14:48     ` Christoph Hellwig
2002-10-16 15:36       ` Greg Ungerer
2002-11-26  7:46   ` [PATCH] Make some EXPORT_SYMBOLs dependent on CONFIG_MMU Miles Bader
2002-11-26  7:49   ` [PATCH] v850 additions to include/linux/elf.h Miles Bader
2002-11-26 15:41     ` Alan Cox
2002-11-27  1:19       ` Miles Bader
2002-11-27 13:01         ` Alan Cox
2002-11-28  1:20           ` Miles Bader
2002-10-16  5:42 ` [PATCH]: linux-2.5.42uc1 (MMU-less support) Miles Bader
2002-10-16 12:49   ` Greg Ungerer
  -- strict thread matches above, loose matches on Subject: below --
2002-10-16 15:49 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=3DAD7AA9.1060207@snapgear.com \
    --to=gerg@snapgear.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox