public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: akpm@linux-foundation.org
Cc: torvalds@linux-foundation.org, linux@rasmusvillemoes.dk,
	linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: [patch 069/104] lib/string_helpers.c:string_get_size(): remove redundant prefixes
Date: Thu, 12 Feb 2015 15:25:08 -0800	[thread overview]
Message-ID: <1423783508.6286.25.camel@HansenPartnership.com> (raw)
In-Reply-To: <54dd30d9.8sIvA5PVH18vSWTI%akpm@linux-foundation.org>

On Thu, 2015-02-12 at 15:01 -0800, akpm@linux-foundation.org wrote:
> From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Subject: lib/string_helpers.c:string_get_size(): remove redundant prefixes
> 
> While 3c9f3681d0b4 "[SCSI] lib: add generic helper to print sizes rounded
> to the correct SI range" says that Z and Y are included in preparation for
> 128 bit computers, they just waste .text currently.  If and when we get
> u128, string_get_size needs updating anyway (and ISO needs to come up with
> four more prefixes).

This is rubbish.  It's nothing to do with 128 bits.  This is to do with
disk sizes linux gets attached to.  The current largest device clusters
are Petabytes ... I think we may have some exabyte ones somewhere in the
Academic community, so it's by no means inconcievable we'll have
Zettabyte ones within a few years.  The SCSI standard, with 4k blocks
supports up to 2^76, which is well into Zettabytes.  We obviously run
off the mmap possibilities a lot sooner, because of the byte offsets,
but that's fixable.  Someone will probably start first by passing blocks
into that interface not bytes, so we'd like it not to be based on
assumptions that think 2^64 is the largest possible value.

> Also there's no need to include and test for the NULL sentinel; once we
> reach "E" size is at most 18.  [The test is also wrong; it should be
> units_str[units][i+1]; if we've reached NULL we're already doomed.]

So fix the bug, don't set us up to run off the end of the array.  And
please consult the community which keeps track of this rather than
trying to get it into Linux without review.

James



       reply	other threads:[~2015-02-12 23:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <54dd30d9.8sIvA5PVH18vSWTI%akpm@linux-foundation.org>
2015-02-12 23:25 ` James Bottomley [this message]
2015-02-12 23:40   ` [patch 069/104] lib/string_helpers.c:string_get_size(): remove redundant prefixes Andrew Morton
2015-02-12 23:45     ` James Bottomley
2015-02-12 23:55       ` Andrew Morton
2015-02-14  0:05         ` James Bottomley
2015-02-14  1:02           ` Andrew Morton
2015-02-14  4:03             ` James Bottomley

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=1423783508.6286.25.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox