All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] extend physmap.c to support run-time adding partitions
Date: Thu, 23 Oct 2003 13:04:06 -0700	[thread overview]
Message-ID: <20031023130406.D1345@mvista.com> (raw)
In-Reply-To: <20031023181541.GE16160@wohnheim.fh-wedel.de>; from joern@wohnheim.fh-wedel.de on Thu, Oct 23, 2003 at 08:15:41PM +0200

On Thu, Oct 23, 2003 at 08:15:41PM +0200, Jörn Engel wrote:
> On Thu, 23 October 2003 10:43:20 -0700, Jun Sun wrote:
> > > 
> > > o All those translate to improvements in the source code.  How about the
> > > binary?  Compile with and without patch and post the kernel image
> > > size.  And remember that noone will use two map files at the same time
> > > in the real world.
> > > 
> > > o Copy and paste is simple.  So simple in fact, that everyone does it,
> > > as you have observed.  Why make it more complicated, unless you have
> > > clear advantages.
> > 
> > ... as if my previous listings are not advantages. :)
> 
> They are, no doubt.  But there are disadvantages as well.
> 
> > > Yes, I like the basic idea, tried to do it myself.  But what's the use
> > > if all your users care about binary size and that increases?
> > 
> > I find it hard to belive this patch would increase kernel size.
> > Can someone using existing propriatary mapping driver apply this 
> > patch, switch to use physmap.c, and let us know the size increase?
> > 
> > How much increase would you start to really care in a typical .5M to 2M
> > kernel?  1K or 10K or 100K?  I think the increase should be minimum if any.
> 
> I don't know and I don't care.  You want the patch in, you show the
> numbers or convince David otherwise.
>

I will do some numbers, but I don't really buy your logic.  I said
"This patch is great" and you are one who said it increases the size.
It seems to me you need to prove your claim. :)

Jun

  reply	other threads:[~2003-10-23 20:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-23  1:25 [PATCH] extend physmap.c to support run-time adding partitions Jun Sun
     [not found] ` <20031023153307.GA11669@wohnheim.fh-wedel.de>
2003-10-23 17:03   ` Jun Sun
2003-10-23 17:31     ` Jörn Engel
2003-10-23 17:43       ` Jun Sun
2003-10-23 18:15         ` Jörn Engel
2003-10-23 20:04           ` Jun Sun [this message]
2003-10-23 23:57             ` Jun Sun
2003-10-28  8:22               ` Holger Schurig
2003-10-29  2:33                 ` Jun Sun
2003-10-27 18:17 ` Jun Sun
2003-10-28 10:50   ` David Woodhouse
2003-10-29  2:28     ` Jun Sun
2003-10-29 11:13       ` David Woodhouse
2003-10-29 18:45         ` Jun Sun
2003-10-29 19:32           ` Jörn Engel
2003-10-29 23:15             ` Jun Sun
2003-10-29 22:57           ` Cam Mayor
2003-10-29 23:13             ` Jun Sun

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=20031023130406.D1345@mvista.com \
    --to=jsun@mvista.com \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=linux-mtd@lists.infradead.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.