running out of space dd'ing JFFS2 image to /dev/mtdblock/0

running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Robert P. J. Day]

  just for curiosity's sake, after i build a JFFS2 image using
mkfs.jffs2, i want to mount out to verify its contents.  to do that, i
use a recipe i patched together a while back involving loading the
appropriate modules, creating /dev/mtdblock/0, dd'ing the image to
that device, then mounting it.

  however, this morning, in trying this with a larger-than-normal
JFFS2 image, i get:

  # dd bs=4096 if=soefsimage of=/dev/mtdblock/0
  # dd: writing `/dev/mtdblock/0': No space left on device
  1025+0 records in
  1024+0 records out

IOW, it dies after 4M.  is this a limit imposed by the ramdisk limit
in the kernel configuration?  is this a configurable parameter at
module load time?  thanks for any pointers.

rday

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Josh Boyer]

On Mon, 2005-01-31 at 10:14 -0500, Robert P. J. Day wrote:
>   just for curiosity's sake, after i build a JFFS2 image using
> mkfs.jffs2, i want to mount out to verify its contents.  to do that, i
> use a recipe i patched together a while back involving loading the
> appropriate modules, creating /dev/mtdblock/0, dd'ing the image to
> that device, then mounting it.
> 
>   however, this morning, in trying this with a larger-than-normal
> JFFS2 image, i get:
> 
>   # dd bs=4096 if=soefsimage of=/dev/mtdblock/0
>   # dd: writing `/dev/mtdblock/0': No space left on device
>   1025+0 records in
>   1024+0 records out
> 
> IOW, it dies after 4M.  is this a limit imposed by the ramdisk limit
> in the kernel configuration?  is this a configurable parameter at
> module load time?  thanks for any pointers.

If you are using mtdram.c, it should be a module parameter.  Try setting
total_size to something larger.

josh

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Robert P. J. Day]

On Mon, 31 Jan 2005, Josh Boyer wrote:

> On Mon, 2005-01-31 at 10:14 -0500, Robert P. J. Day wrote:
> >   just for curiosity's sake, after i build a JFFS2 image using
> > mkfs.jffs2, i want to mount out to verify its contents.  to do
> > that, i use a recipe i patched together a while back involving
> > loading the appropriate modules, creating /dev/mtdblock/0, dd'ing
> > the image to that device, then mounting it.
> >
> >   however, this morning, in trying this with a larger-than-normal
> > JFFS2 image, i get:
> >
> >   # dd bs=4096 if=soefsimage of=/dev/mtdblock/0
> >   # dd: writing `/dev/mtdblock/0': No space left on device
> >   1025+0 records in
> >   1024+0 records out
> >
> > IOW, it dies after 4M.  is this a limit imposed by the ramdisk
> > limit in the kernel configuration?  is this a configurable
> > parameter at module load time?  thanks for any pointers.
>
> If you are using mtdram.c, it should be a module parameter.  Try
> setting total_size to something larger.

  ah, excellent, but while we're on the subject of parameters, is
there any hope of getting some consistency in the way parameter values
are supplied across the world of JFFS2 and MTD?

  to wit, with "mkfs.jffs2":

-p, --pad[=SIZE] Pad output to SIZE bytes with 0xFF. If SIZE is
                        not specified, the output is padded to the
			end of the final erase block


  so, apparently, you supply an *exact* byte size here (it's not
mentioned if you can use KiB or MiB prefixes).

  with "--pagesize" and "--eraseblock", the help states that you *can*
use those prefixes.

  if you check what you can do with the mtdram module, you get:

$ modinfo mtdram
filename:
/lib/modules/2.6.10-1.741_FC3/kernel/drivers/mtd/devices/mtdram.ko
parm:           total_size:Total device size in KiB
parm:           erase_size:Device erase block size in KiB

  so the values here are ... what?  strictly in KiB?  so i'd supply
something like

  total_size=16384

to specify 16M?  it's just a bit painful to jump around between the
various utilities and have to keep remembering what the standard is.

  thoughts?

rday

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Artem B. Bityuckiy]

On Mon, 31 Jan 2005, Robert P. J. Day wrote:

> On Mon, 31 Jan 2005, Josh Boyer wrote:
> 
> > On Mon, 2005-01-31 at 10:14 -0500, Robert P. J. Day wrote:
> > >   just for curiosity's sake, after i build a JFFS2 image using
> > > mkfs.jffs2, i want to mount out to verify its contents.  to do
> > > that, i use a recipe i patched together a while back involving
> > > loading the appropriate modules, creating /dev/mtdblock/0, dd'ing
> > > the image to that device, then mounting it.
> > >
> > >   however, this morning, in trying this with a larger-than-normal
> > > JFFS2 image, i get:
> > >
> > >   # dd bs=4096 if=soefsimage of=/dev/mtdblock/0
> > >   # dd: writing `/dev/mtdblock/0': No space left on device
> > >   1025+0 records in
> > >   1024+0 records out
> > >
> > > IOW, it dies after 4M.  is this a limit imposed by the ramdisk
> > > limit in the kernel configuration?  is this a configurable
> > > parameter at module load time?  thanks for any pointers.
> >
> > If you are using mtdram.c, it should be a module parameter.  Try
> > setting total_size to something larger.
> 
>   ah, excellent, but while we're on the subject of parameters, is
> there any hope of getting some consistency in the way parameter values
> are supplied across the world of JFFS2 and MTD?
> 
>   to wit, with "mkfs.jffs2":
> 
> -p, --pad[=SIZE] Pad output to SIZE bytes with 0xFF. If SIZE is
>                         not specified, the output is padded to the
> 			end of the final erase block
> 
> 
>   so, apparently, you supply an *exact* byte size here (it's not
> mentioned if you can use KiB or MiB prefixes).
> 
>   with "--pagesize" and "--eraseblock", the help states that you *can*
> use those prefixes.
> 
>   if you check what you can do with the mtdram module, you get:
> 
> $ modinfo mtdram
> filename:
> /lib/modules/2.6.10-1.741_FC3/kernel/drivers/mtd/devices/mtdram.ko
> parm:           total_size:Total device size in KiB
> parm:           erase_size:Device erase block size in KiB
> 
>   so the values here are ... what?  strictly in KiB?  so i'd supply
> something like
> 
>   total_size=16384
> 
> to specify 16M?  it's just a bit painful to jump around between the
> various utilities and have to keep remembering what the standard is.
> 
>   thoughts?
My thought that if you sent patch that fixes this inconsistency it will 
be nice. :-)

> 
> rday
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Jörn Engel]

On Mon, 31 January 2005 10:43:25 -0500, Robert P. J. Day wrote:
> 
>   ah, excellent, but while we're on the subject of parameters, is
> there any hope of getting some consistency in the way parameter values
> are supplied across the world of JFFS2 and MTD?
> 
>   to wit, with "mkfs.jffs2":
> 
> -p, --pad[=SIZE] Pad output to SIZE bytes with 0xFF. If SIZE is
>                         not specified, the output is padded to the
> 			end of the final erase block
> 
> 
>   so, apparently, you supply an *exact* byte size here (it's not
> mentioned if you can use KiB or MiB prefixes).
> 
>   with "--pagesize" and "--eraseblock", the help states that you *can*
> use those prefixes.
> 
>   if you check what you can do with the mtdram module, you get:
> 
> $ modinfo mtdram
> filename:
> /lib/modules/2.6.10-1.741_FC3/kernel/drivers/mtd/devices/mtdram.ko
> parm:           total_size:Total device size in KiB
> parm:           erase_size:Device erase block size in KiB
> 
>   so the values here are ... what?  strictly in KiB?  so i'd supply
> something like
> 
>   total_size=16384
> 
> to specify 16M?  it's just a bit painful to jump around between the
> various utilities and have to keep remembering what the standard is.
> 
>   thoughts?

Feel free to send patches. :)

mkfs.jffs2 is something I personally don't care about.  Few do, thus
the current state.

mtdram looks pretty broken, interface-wise.  So if you want to fix it,
you might want to follow my path with slram/phram or blkmtd/block2mtd.
Rename the file, fix the interface, fix the other crap you find,
submit for inclusion.  If it's better, people will start using it.

Jörn

-- 
To announce that there must be no criticism of the President, or that we
are to stand by the President, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
-- Theodore Roosevelt, Kansas City Star, 1918

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Robert P. J. Day]

On Mon, 31 Jan 2005, Artem B. Bityuckiy wrote:

> On Mon, 31 Jan 2005, Robert P. J. Day wrote:

> >   ah, excellent, but while we're on the subject of parameters, is
> > there any hope of getting some consistency in the way parameter values
> > are supplied across the world of JFFS2 and MTD?
> >
> >   to wit, with "mkfs.jffs2":
> >
> > -p, --pad[=SIZE] Pad output to SIZE bytes with 0xFF. If SIZE is
> >                         not specified, the output is padded to the
> > 			end of the final erase block
> >
> >
> >   so, apparently, you supply an *exact* byte size here (it's not
> > mentioned if you can use KiB or MiB prefixes).
> >
> >   with "--pagesize" and "--eraseblock", the help states that you *can*
> > use those prefixes.
> >
> >   if you check what you can do with the mtdram module, you get:
> >
> > $ modinfo mtdram
> > filename:
> > /lib/modules/2.6.10-1.741_FC3/kernel/drivers/mtd/devices/mtdram.ko
> > parm:           total_size:Total device size in KiB
> > parm:           erase_size:Device erase block size in KiB
> >
> >   so the values here are ... what?  strictly in KiB?  so i'd supply
> > something like
> >
> >   total_size=16384
> >
> > to specify 16M?  it's just a bit painful to jump around between the
> > various utilities and have to keep remembering what the standard is.
> >
> >   thoughts?

> My thought that if you sent patch that fixes this inconsistency it
> will be nice. :-)

first, it's necessary to define a simple standard, so what about
something like the following?  any size values in *any* of the
JFFS2-related programs shall be in one of the following formats:

  ###		(interpreted as bytes)
  ###KiB	(obvious)
  ###MiB	(obvious)

at the moment, this is not being followed.  for instance, mkfs.jffs2
has the --pad=SIZE option, where a simple number is treated as KiB.
anyway, you get idea -- it's pretty confusing.

so, do we at least have some agreement on a standard?  which would
hold across *all* programs and modules?  i'm not even going to
*consider* looking at patches to do this unless i'm convinced everyone
agrees, since changes like this will clearly force people to change
the way they do some things.  and i know how fond some people are of
*that* idea. :-)

rday

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Artem B. Bityuckiy]

On Mon, 31 Jan 2005, Robert P. J. Day wrote:

> On Mon, 31 Jan 2005, Artem B. Bityuckiy wrote:
> 
> > On Mon, 31 Jan 2005, Robert P. J. Day wrote:
> 
> > >   ah, excellent, but while we're on the subject of parameters, is
> > > there any hope of getting some consistency in the way parameter values
> > > are supplied across the world of JFFS2 and MTD?
> > >
> > >   to wit, with "mkfs.jffs2":
> > >
> > > -p, --pad[=SIZE] Pad output to SIZE bytes with 0xFF. If SIZE is
> > >                         not specified, the output is padded to the
> > > 			end of the final erase block
> > >
> > >
> > >   so, apparently, you supply an *exact* byte size here (it's not
> > > mentioned if you can use KiB or MiB prefixes).
> > >
> > >   with "--pagesize" and "--eraseblock", the help states that you *can*
> > > use those prefixes.
> > >
> > >   if you check what you can do with the mtdram module, you get:
> > >
> > > $ modinfo mtdram
> > > filename:
> > > /lib/modules/2.6.10-1.741_FC3/kernel/drivers/mtd/devices/mtdram.ko
> > > parm:           total_size:Total device size in KiB
> > > parm:           erase_size:Device erase block size in KiB
> > >
> > >   so the values here are ... what?  strictly in KiB?  so i'd supply
> > > something like
> > >
> > >   total_size=16384
> > >
> > > to specify 16M?  it's just a bit painful to jump around between the
> > > various utilities and have to keep remembering what the standard is.
> > >
> > >   thoughts?
> 
> > My thought that if you sent patch that fixes this inconsistency it
> > will be nice. :-)
> 
> first, it's necessary to define a simple standard, so what about
> something like the following?  any size values in *any* of the
> JFFS2-related programs shall be in one of the following formats:
> 
>   ###		(interpreted as bytes)
>   ###KiB	(obvious)
>   ###MiB	(obvious)
> 
> at the moment, this is not being followed.  for instance, mkfs.jffs2
> has the --pad=SIZE option, where a simple number is treated as KiB.
> anyway, you get idea -- it's pretty confusing.
> 
> so, do we at least have some agreement on a standard?  which would
> hold across *all* programs and modules?  i'm not even going to
> *consider* looking at patches to do this unless i'm convinced everyone
> agrees, since changes like this will clearly force people to change
> the way they do some things.  and i know how fond some people are of
> *that* idea. :-)
> 
> rday
> 
> 
IMO, JFFS2 utilities should support KiB/MiB on etiher all options or for 
no option. Agree that this is minor inconsistency when one option supports 
KiB but anothed does not.

About modules, don't know. IMO, just bytes is enough. Ony state this 
explicitly in module info.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Thomas Gleixner]

On Mon, 2005-01-31 at 11:14 -0500, Robert P. J. Day wrote:
> > > -p, --pad[=SIZE] Pad output to SIZE bytes with 0xFF. If SIZE is
> > >                         not specified, the output is padded to the
> > > 			end of the final erase block
>
> at the moment, this is not being followed.  for instance, mkfs.jffs2
> has the --pad=SIZE option, where a simple number is treated as KiB.
> anyway, you get idea -- it's pretty confusing.

???

It's just missing the k and M suffixes. So its easy to fix.

tglx

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[David Woodhouse]

On Mon, 2005-01-31 at 17:22 +0100, Thomas Gleixner wrote:
> 
> ???
> 
> It's just missing the k and M suffixes. So its easy to fix.

Don't add k and M. Those are power-of-ten and almost never what the
users wants. Add Ki and Mi only.

-- 
dwmw2

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Jörn Engel]

On Mon, 31 January 2005 11:14:49 -0500, Robert P. J. Day wrote:
> 
> first, it's necessary to define a simple standard, so what about
> something like the following?  any size values in *any* of the
> JFFS2-related programs shall be in one of the following formats:
> 
>   ###		(interpreted as bytes)
>   ###KiB	(obvious)
>   ###MiB	(obvious)
> 
> at the moment, this is not being followed.  for instance, mkfs.jffs2
> has the --pad=SIZE option, where a simple number is treated as KiB.
> anyway, you get idea -- it's pretty confusing.
> 
> so, do we at least have some agreement on a standard?  which would
> hold across *all* programs and modules?  i'm not even going to
> *consider* looking at patches to do this unless i'm convinced everyone
> agrees, since changes like this will clearly force people to change
> the way they do some things.  and i know how fond some people are of
> *that* idea. :-)

I agree on a standard, if that helps you:

0x[0-9]...	hex
0[1-9]...	octal
[1-9]...	decimal

If followed by "ki", "Mi", or "Gi", they are multiplied by 1024, etc.

Example code, taken from phram:

static int ustrtoul(const char *cp, char **endp, unsigned int base)
{
	unsigned long result = simple_strtoul(cp, endp, base);

	switch (**endp) {
	case 'G':
		result *= 1024;
	case 'M':
		result *= 1024;
	case 'k':
		result *= 1024;
	/* By dwmw2 editorial decree, "ki", "Mi" or "Gi" are to be used. */
		if ((*endp)[1] == 'i')
			(*endp) += 2;
	}
	return result;
}

static int parse_num32(uint32_t *num32, const char *token)
{
	char *endp;
	unsigned long n;

	n = ustrtoul(token, &endp, 0);
	if (*endp)
		return -EINVAL;

	*num32 = n;
	return 0;
}

This allows different people with different taste to specify numbers
in various simple formats.  If you think you can improve on this,
please send me a patch.

Jörn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Robert P. J. Day]

On Mon, 31 Jan 2005, David Woodhouse wrote:

> On Mon, 2005-01-31 at 17:22 +0100, Thomas Gleixner wrote:
> >
> > ???
> >
> > It's just missing the k and M suffixes. So its easy to fix.
>
> Don't add k and M. Those are power-of-ten and almost never what the
> users wants. Add Ki and Mi only.

i agree completely, but i thought some of the recognized suffixes were
"KiB", "MiB" and so on.  anyway, i was pretty sure that even a
suggestion this innocuous was going to generate some discussion.

i'll leave it up to the gurus here to decide how they want to
standardize this.

rday

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Artem B. Bityuckiy]

On Mon, 31 Jan 2005, Robert P. J. Day wrote:

> On Mon, 31 Jan 2005, David Woodhouse wrote:
> 
> > On Mon, 2005-01-31 at 17:22 +0100, Thomas Gleixner wrote:
> > >
> > > ???
> > >
> > > It's just missing the k and M suffixes. So its easy to fix.
> >
> > Don't add k and M. Those are power-of-ten and almost never what the
> > users wants. Add Ki and Mi only.
> 
> i agree completely, but i thought some of the recognized suffixes were
> "KiB", "MiB" and so on.  anyway, i was pretty sure that even a
> suggestion this innocuous was going to generate some discussion.
Nobody told about not to use KiB/MiB. It wos told about not to us K and M, 
like 10K, 100M. Use 10KiB, 100MiB instead.

> 
> i'll leave it up to the gurus here to decide how they want to
> standardize this.
> 
> rday
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Jörn Engel]

On Mon, 31 January 2005 17:11:38 +0000, Artem B. Bityuckiy wrote:
> On Mon, 31 Jan 2005, Robert P. J. Day wrote:
> 
> > i agree completely, but i thought some of the recognized suffixes were
> > "KiB", "MiB" and so on.  anyway, i was pretty sure that even a
> > suggestion this innocuous was going to generate some discussion.
> Nobody told about not to use KiB/MiB. It wos told about not to us K and M, 
> like 10K, 100M. Use 10KiB, 100MiB instead.

What information does the "B" in "10KiB" contain?  And why is it "Ki"
instead of the correct "ki"?

Robert: please don't just sit there and wait for someone else to do
your work.  Send a patch.  If it's wrong, people will comment.  Right
now, this discussion is completely academic.

Jörn

-- 
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Artem B. Bityuckiy]

On Mon, 31 Jan 2005, [iso-8859-1] Jörn Engel wrote:

> On Mon, 31 January 2005 17:11:38 +0000, Artem B. Bityuckiy wrote:
> > On Mon, 31 Jan 2005, Robert P. J. Day wrote:
> > 
> > > i agree completely, but i thought some of the recognized suffixes were
> > > "KiB", "MiB" and so on.  anyway, i was pretty sure that even a
> > > suggestion this innocuous was going to generate some discussion.
> > Nobody told about not to use KiB/MiB. It wos told about not to us K and M, 
> > like 10K, 100M. Use 10KiB, 100MiB instead.
> 
> What information does the "B" in "10KiB" contain?  And why is it "Ki"
> instead of the correct "ki"?
Hehe.

This is just widely used unit. And it is usually written like that. And 
now most utilities work with such. But if one wants and thinks it is 
reasonable, why not to use kib :-)
 
> Robert: please don't just sit there and wait for someone else to do
> your work.  Send a patch.  If it's wrong, people will comment.  Right
> now, this discussion is completely academic.
> 
> Jörn
> 
> -- 
> Measure. Don't tune for speed until you've measured, and even then
> don't unless one part of the code overwhelms the rest.
> -- Rob Pike
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Josh Boyer]

On Mon, 2005-01-31 at 17:25 +0000, Artem B. Bityuckiy wrote:
> On Mon, 31 Jan 2005, [iso-8859-1] Jörn Engel wrote:
> 
> > On Mon, 31 January 2005 17:11:38 +0000, Artem B. Bityuckiy wrote:
> > > On Mon, 31 Jan 2005, Robert P. J. Day wrote:
> > > 
> > > > i agree completely, but i thought some of the recognized suffixes were
> > > > "KiB", "MiB" and so on.  anyway, i was pretty sure that even a
> > > > suggestion this innocuous was going to generate some discussion.
> > > Nobody told about not to use KiB/MiB. It wos told about not to us K and M, 
> > > like 10K, 100M. Use 10KiB, 100MiB instead.
> > 
> > What information does the "B" in "10KiB" contain?  And why is it "Ki"
> > instead of the correct "ki"?
> Hehe.
> 
> This is just widely used unit. And it is usually written like that. And 
> now most utilities work with such. But if one wants and thinks it is 
> reasonable, why not to use kib :-)

Because they aren't just commonly used units.  See:

http://physics.nist.gov/cuu/Units/binary.html

josh

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Jörn Engel]

On Mon, 31 January 2005 17:25:05 +0000, Artem B. Bityuckiy wrote:
> On Mon, 31 Jan 2005, [iso-8859-1] Jörn Engel wrote:
> > 
> > What information does the "B" in "10KiB" contain?  And why is it "Ki"
> > instead of the correct "ki"?
> Hehe.
> 
> This is just widely used unit. And it is usually written like that. And 
> now most utilities work with such. But if one wants and thinks it is 
> reasonable, why not to use kib :-)

Well, if people really prefer it, allowing either "ki" or "kiB" would
be fine.  Not that much extra code.  "kib" as well, sure.  phram and
block2mtd will remain unchanged until people explicitly request it,
though. :)

Jörn

-- 
I can say that I spend most of my time fixing bugs even if I have lots
of new features to implement in mind, but I give bugs more priority.
-- Andrea Arcangeli, 2000

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Jörn Engel]

On Mon, 31 January 2005 11:29:11 -0600, Josh Boyer wrote:
> 
> Because they aren't just commonly used units.  See:
> 
> http://physics.nist.gov/cuu/Units/binary.html

Oh crud!  They also picked the capital K.  All right, standard is
close enough to common sense, who cares.

Below code accepts 'Ki' (standard) and 'ki' (analog to decimal k).  It
also chews the final 'B' if people want to pass it.  Changes are
untested.

And for the curious, the 'u' in ustrtoul stands for "unit".

static int ustrtoul(const char *cp, char **endp, unsigned int base)
{
        unsigned long result = simple_strtoul(cp, endp, base);

        switch (**endp) {
        case 'G':
                result *= 1024;
        case 'M':
                result *= 1024;
        case 'K':
        case 'k':
                result *= 1024;
        /* By dwmw2 editorial decree, "ki", "Mi" or "Gi" are to be used. */
                if ((*endp)[1] == 'i')
                        (*endp) += 2;
                if (**endp == 'B')
                        (*endp) += 1;
        }
        return result;
}


Jörn

-- 
I don't understand it. Nobody does.
-- Richard P. Feynman

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Robert P. J. Day]

On Mon, 31 Jan 2005, Artem B. Bityuckiy wrote:

> Nobody told about not to use KiB/MiB. It wos told about not to us K
> and M, like 10K, 100M. Use 10KiB, 100MiB instead.

ok, i'll start poking around and come up with a patch or two.  don't
hold your breath, it's a busy week.  the rules:

  acceptable suffixes: 	{K,k,M,m,G,g}i[Bb]    	(final "b" is optional)
  not acceptable	{K,k,M,m,G,g}		(not a single letter)

and any bare number means *exactly* that number of bytes.  agreed?
let's leave hex and octal prefixes for round two.

rday

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Jörn Engel]

On Mon, 31 January 2005 12:43:47 -0500, Robert P. J. Day wrote:
> On Mon, 31 Jan 2005, Artem B. Bityuckiy wrote:
> 
> > Nobody told about not to use KiB/MiB. It wos told about not to us K
> > and M, like 10K, 100M. Use 10KiB, 100MiB instead.
> 
> ok, i'll start poking around and come up with a patch or two.  don't
> hold your breath, it's a busy week.  the rules:
> 
>   acceptable suffixes: 	{K,k,M,m,G,g}i[Bb]    	(final "b" is optional)
                                       ^   ^
'm' and 'g' don't make sense.  'm' means Milli, instead of Mega, which
is a slight difference. :)
>   not acceptable	{K,k,M,m,G,g}		(not a single letter)
> 
> and any bare number means *exactly* that number of bytes.  agreed?
> let's leave hex and octal prefixes for round two.

If you're lazy and simply call ustrtoul (posted 3min ago), there is no
need for round two.

Jörn

-- 
Good warriors cause others to come to them and do not go to others.
-- Sun Tzu

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 999 bytes --]

On Mon, 31 Jan 2005, Jörn Engel wrote:

> On Mon, 31 January 2005 12:43:47 -0500, Robert P. J. Day wrote:
> > On Mon, 31 Jan 2005, Artem B. Bityuckiy wrote:
> >
> > > Nobody told about not to use KiB/MiB. It wos told about not to us K
> > > and M, like 10K, 100M. Use 10KiB, 100MiB instead.
> >
> > ok, i'll start poking around and come up with a patch or two.  don't
> > hold your breath, it's a busy week.  the rules:
> >
> >   acceptable suffixes: 	{K,k,M,m,G,g}i[Bb]    	(final "b" is optional)
>                                        ^   ^
> 'm' and 'g' don't make sense.  'm' means Milli, instead of Mega, which
> is a slight difference. :)

you're right, i was typing faster than i was thinking.

> >   not acceptable	{K,k,M,m,G,g}		(not a single letter)
> >
> > and any bare number means *exactly* that number of bytes.  agreed?
> > let's leave hex and octal prefixes for round two.
>
> If you're lazy and simply call ustrtoul (posted 3min ago), there is no
> need for round two.

ok.

rday

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[David Woodhouse]

On Mon, 2005-01-31 at 12:43 -0500, Robert P. J. Day wrote:
> 
> ok, i'll start poking around and come up with a patch or two.  don't
> hold your breath, it's a busy week.  the rules:
> 
>   acceptable suffixes:  {K,k,M,m,G,g}i[Bb]      (final "b" is
> optional)

By convention, 'b' is bits, 'B' is bytes. Let's support only 'KiB' and
'MiB'; nothing else is really necessary, surely?

-- 
dwmw2

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Robert P. J. Day]

On Mon, 31 Jan 2005, David Woodhouse wrote:

> On Mon, 2005-01-31 at 12:43 -0500, Robert P. J. Day wrote:
> >
> > ok, i'll start poking around and come up with a patch or two.  don't
> > hold your breath, it's a busy week.  the rules:
> >
> >   acceptable suffixes:  {K,k,M,m,G,g}i[Bb]      (final "b" is
> > optional)
>
> By convention, 'b' is bits, 'B' is bytes. Let's support only 'KiB' and
> 'MiB'; nothing else is really necessary, surely?

i'm all for that.

rday

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Robert P. J. Day]

On Mon, 31 Jan 2005, Thomas Gleixner wrote:

> On Mon, 2005-01-31 at 11:14 -0500, Robert P. J. Day wrote:
> > > > -p, --pad[=SIZE] Pad output to SIZE bytes with 0xFF. If SIZE is
> > > >                         not specified, the output is padded to the
> > > > 			end of the final erase block
> >
> > at the moment, this is not being followed.  for instance, mkfs.jffs2
> > has the --pad=SIZE option, where a simple number is treated as KiB.
> > anyway, you get idea -- it's pretty confusing.
>
> ???
>
> It's just missing the k and M suffixes. So its easy to fix.

  while this isn't related to MTD, i thought i'd toss it out since i
just tripped over it in looking at the source for mkfs.jffs2.c.  that
utility uses the getopt_long() routine to parse arguments, and the
long_options array that defines the possible args starts with:

static struct option long_options[] = {
    {"pad", 2, NULL, 'p'},
    {"root", 1, NULL, 'r'},
    ....

that first entry ostensibly means that the "pad" parameter has an
optional argument.

  however, i was not aware that, defined that way, you *must* specify
that option as, say, "-p262144" and not "-p 262144".  i had never
noticed that before, and it strikes me as horribly non-intuitive.

  anyway, just an observation.  now i'll shut up and get back to
patching.

rday

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[David Woodhouse]

On Mon, 2005-01-31 at 17:39 +0100, Jörn Engel wrote:
> This allows different people with different taste to specify numbers
> in various simple formats.  If you think you can improve on this,
> please send me a patch.

It is wrong to interpret 'k' 'M' and 'G' as anything other than 10^3,
10^6 or 10^9 respectively. If you have to do it to support a legacy
interface like slram, that's vaguely acceptable. No more, though.

-- 
dwmw2

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Josh Boyer]

On Tue, 2005-02-01 at 00:19 +0000, David Woodhouse wrote:
> On Mon, 2005-01-31 at 17:39 +0100, Jörn Engel wrote:
> > This allows different people with different taste to specify numbers
> > in various simple formats.  If you think you can improve on this,
> > please send me a patch.
> 
> It is wrong to interpret 'k' 'M' and 'G' as anything other than 10^3,
> 10^6 or 10^9 respectively. If you have to do it to support a legacy
> interface like slram, that's vaguely acceptable. No more, though.
> 

Why is slram still around?  Isn't phram supposed to replace it?  I think
once a better replacement driver has been written, the old one should be
marked deprecated and eventually removed.

josh

Re: running out of space dd'ing JFFS2 image to /dev/mtdblock/0

[Jörn Engel]

On Tue, 1 February 2005 00:19:31 +0000, David Woodhouse wrote:
> On Mon, 2005-01-31 at 17:39 +0100, Jörn Engel wrote:
> > This allows different people with different taste to specify numbers
> > in various simple formats.  If you think you can improve on this,
> > please send me a patch.
> 
> It is wrong to interpret 'k' 'M' and 'G' as anything other than 10^3,
> 10^6 or 10^9 respectively. If you have to do it to support a legacy
> interface like slram, that's vaguely acceptable. No more, though.

Misunderstanding.  Nowhere do I accept 'k' without 'i' and nowhere do
I use 10^[369].  Everything is good. :)

Jörn

-- 
Victory in war is not repetitious.
-- Sun Tzu