From: gerg <gerg@snapgear.com>
To: Matthew Wilcox <willy@debian.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: linux-2.5.30uc0 MMU-less patches
Date: Sat, 03 Aug 2002 01:51:35 +1000 [thread overview]
Message-ID: <3D4AAA87.8050508@snapgear.com> (raw)
In-Reply-To: 20020802145034.B24631@parcelfarce.linux.theplanet.co.uk
Hi Matthew,
Matthew Wilcox wrote:
> Some constructive criticism...
Thanks :-)
> - the Makefile changes seem terribly inappropriate.
They are messy. Some are certainly required, for exmaple
to support the mmnommu directory. Some simplify cross compilation
(like the ARCH and CROSS_COMPILE changes). Some are just pedantic,
creating a binary named linux since this not a vmlinux system.
I'll look at simplify that.
> - you probably didn't mean to include page_alloc2.hack in the diff
Removed.
> - Do you really need your own copy of fbcon.c? Can it be merged with the
> one in drivers/video?
Looking at it I think it could.
> - arch/m68knommu/console/68328fb.c should probably move to drivers/video
> too.
> - ditto most of the other files in the console directory ...
Yep, looks like the whole thing should be merged/moved into
drivers/video.
> - Why are the changes to rd.c required?
The include of linux/mm.h is too get some missing includes
(this is probably due to slightly different includes in something
in include/asm-m68knommu, but I haven't tracked it down yet).
The other change is too work around a compiler bug. Unfortunately
this just appeared in 2.5.30. Gcc is generating incorrect addressing
modes for the ColdFire arhcitecture. This is a short term fix until
the compiler is fixed right.
> - I'm not sure it's appropriate to include the changes to nfs2xdr.c --
> is this a toolchain bug you're working around?
Yes, same as above. I wouldn't expect anyone would want these
changes other than those specifically using ColdFire targets.
> - drivers/char/mcfserial.c needs to be converted to the new serial core
> and moved to drivers/serial.
> - ditto arch/m68knommu/platform/68360/quicc/uart.c
Yep, I am looking at that now. That will take me a little
effort and time to put together.
> I'll look at the change you want to make to locks.c - I'm not terribly
> fond of that interaction either.
Thanks for the tips.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: gerg@snapgear.com
Snapgear Pty Ltd PHONE: +61 7 3279 1822
825 Stanley St, FAX: +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia WEB: www.snapgear.com
next prev parent reply other threads:[~2002-08-02 15:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-02 13:50 linux-2.5.30uc0 MMU-less patches Matthew Wilcox
2002-08-02 15:51 ` gerg [this message]
2002-08-02 16:00 ` Russell King
2002-08-02 16:14 ` gerg
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=3D4AAA87.8050508@snapgear.com \
--to=gerg@snapgear.com \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@debian.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.