From: Artem Bityutskiy <dedekind1@gmail.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: flash_erase vs flash_eraseall
Date: Thu, 23 Sep 2010 14:24:57 +0300 [thread overview]
Message-ID: <1285241097.29268.80.camel@localhost> (raw)
In-Reply-To: <AANLkTi=efR8LkMr_FVxV7V6TzZ2yd1-=2ph5vsaNz41U@mail.gmail.com>
On Wed, 2010-09-22 at 00:35 -0400, Mike Frysinger wrote:
> while looking to extend the erase ioctl abi to take a flags argument,
> i needed updated utils to test my work. reviewing the flash_erase and
> flash_eraseall code bases makes me wonder why there are even two tools
> in the first place. "eraseall" sounds like it should simply be an
> option to the "erase" util. so why does it warrant its own code base
> for a mere option ?
I have no idea, this is historical.
>
> also in looking at these utils, flash_erase does not support the
> extended 64bit api as it is doing ioctls directly nor does it use
> getopt. flash_eraseall however is using the common libmtd api (so it
> gets the extend api support for free), and it is cleanly using getopt
> cleanly. which leads to a simple conclusion from my side ...
>
> let's punt the current flash_erase code, rename flash_eraseall to
> flash_erase, and then extend its options to support the minor
> functionality of flash_erase. doesnt look like it'll be hard at all
> to do this. but before i undertake the task, i want to make sure the
> idea isnt simply going to be rejected due to some concern about
> retaining backwards compatibility.
>
> running `flash_erase /dev/mtd#` (no arguments) will make it erase the
> first block. this seems kind of useless to me.
>
> so i'd make the arguments:
> flash_erase [options] <mtd> <start> [count]
> Options:
> -N, --erasebad
> -j, --jffs2
> -u, --unlock
> -q, --quiet
> --silent
>
> for the "all" functionality, we can have a value of "-1" or "0" for
> the count mean "all", or make people type "all".
> -mike
I'm perfectly fine with getting rid of one of these, this would be a
very good clean-up. May be additionally we could create a
flashe_eraseall shell script which will just run flash_erase <mtd> 0 -1
<other flags>.
But also, it need a careful look to make sure all flash_eraseall
functionality is also in flash_erase.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-09-23 11:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-22 4:35 flash_erase vs flash_eraseall Mike Frysinger
2010-09-23 1:57 ` Jon Povey
2010-09-23 2:06 ` Mike Frysinger
2010-09-23 2:12 ` Jon Povey
2010-09-23 2:41 ` Mike Frysinger
2010-09-23 11:24 ` Artem Bityutskiy [this message]
2010-09-23 19:21 ` Mike Frysinger
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=1285241097.29268.80.camel@localhost \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=vapier.adi@gmail.com \
/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.