public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: rkaiser@sysgo.de
Cc: Frank Neuber <neuber@convergence.de>, linux-mtd@lists.infradead.org
Subject: Re: parse_cmdline_partitions equivalent for map_info
Date: Wed, 23 Oct 2002 16:35:47 +0200	[thread overview]
Message-ID: <20021023143547.GA2979@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <200210231355.g9NDt6s03055@dagobert.svc.sysgo.de>

Hello Robert,

we agree on most issues. I have only kept what might be worth a
discussion.

On Wed, 23 October 2002 16:01:35 +0200, Robert Kaiser wrote:
> >   to rewrite all the mapping drivers in <20 lines of code.
> 
> Agreed 98%

> > - Some drivers need to cut out a small range from the middle for the
> >   bootloader. They then concatenate the range before and after the
> >   bootloader into one virtual partition. Find a clean solution for
> >   this.
> 
> Hmm, I would have thought that mtdconcat.c does this nicely already? (Maybe 
> I'm biased since I'm the author of that module, but I'm open to discussion)

I would have to actually take a look, but that should do it. (1)

> > When physmap.c or any variant is generic enough to do all this, it
> > needs two or three interfaces:
> > - Command line, a lot of people should need that.
> 
> why not use what is there already (cmdline.c) ?

Again, see (1)
We have two seperate issues: Creating devices and partitioning those
devices. This is interchangeable in most cases, but not in all.
That was the whole point about my partitioning rewrite.

If I got you right, cmdline.c cares about partitioning a device. But I
worked on hardware that needed to create three devices on flash and
partition two of those. Would that still work easily?

> > - A c api for the "got a d-box, hit this options" type files.
> 
> Not sure what you mean by "c api", but generally, MTD is already a nightmare 
> to configure for a non-guru, unless there is a specific mapping driver for 
> your hardware that you can just click. So this ability to just tickbox your 
> platform should definitely stay (or even be extended) when a new concept gets 
> introduced.

I mean the infrastructure to rewrite 98% of the mapping drivers in <20
lines.

The user should browse through the configuration, see d-box or
whatever, say yes *once* and be happy. That is the best interface next
to autosensing, no doubt.

(1)
About a year ago, I forked David's tree and rewrote the partitioning.
The changes were quite intrusive, but the result looked good to me.
Since then, I wanted to merge the changes back into David's tree. It
never happened, blame goes to both of us.
Sad result is that I continued developing my tree, you all continued
developing David's tree and neither has looked at the other.
Currently, two or three independent groups use my tree, most use
David's tree and noone cares about the situation.
Again, blame everyone. David never looked at my code. I never put it
into nice sizeable pieces for him. And everyone else either dumped
David's tree or ignored mine.

So the result is that I am pretty unaware about current cvs head.
And by now, I don't even care anymore. David is a good developer, but
his problems and my problems don't give a very cooperative mixture.

Jörn

-- 
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra

  reply	other threads:[~2002-10-23 14:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-18 10:49 parse_cmdline_partitions equivalent for map_info Frank Neuber
2002-10-18 12:14 ` David Woodhouse
2002-10-19 16:44   ` Jörn Engel
2002-10-22 10:39     ` Frank Neuber
2002-10-22 17:29       ` Jörn Engel
2002-10-23 13:25         ` Robert Kaiser
2002-10-23 13:33           ` Jörn Engel
     [not found]       ` <20021022170803.GA9161@wohnheim.fh-wedel.de>
2002-10-23  9:49         ` Frank Neuber
2002-10-23 10:06           ` Jörn Engel
2002-10-23 10:27             ` Frank Neuber
2002-10-23 12:07               ` Jörn Engel
2002-10-23 14:01                 ` Robert Kaiser
2002-10-23 14:35                   ` Jörn Engel [this message]
2002-10-23 16:22                     ` Robert Kaiser
2002-10-27 18:00                       ` Jörn Engel
2002-10-28 10:56                         ` Robert Kaiser
2002-10-28 15:30                           ` Jörn Engel

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=20021023143547.GA2979@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=neuber@convergence.de \
    --cc=rkaiser@sysgo.de \
    /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