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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox