All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: Tejun Heo <tj@kernel.org>
Cc: jeff@garzik.org, linux-ide@vger.kernel.org,
	jens.axboe@oracle.com, linux-kernel@vger.kernel.org,
	linux-scsi@vger.kernel.org,
	James.Bottomley@hansenpartnership.com, Mauelshagen@redhat.com,
	dm-devel@redhat.com, dan.j.williams@gmail.com
Subject: Re: [PATCH 1/3] block: add alt_size
Date: Sat, 9 May 2009 18:26:56 +0200	[thread overview]
Message-ID: <ac3eb2510905090926r4ac0bc52kb8639101f0c78d86@mail.gmail.com> (raw)
In-Reply-To: <4A058D5C.6030206@kernel.org>

On Sat, May 9, 2009 at 16:04, Tejun Heo <tj@kernel.org> wrote:
> Kay Sievers wrote:
>> What does "alt_" stand for? I think that should be more descriptive in
>> an exported interface.
>
> Alternative.
>
>> And can we please keep the "size_*" in front of the name, so that they
>> group together?
>
> Maybe, but size_alt?  Any better ideas?

"size_limit"
"size_restricted"
"size_clipped"
"size_constrain"

anything that ideally would express that this is smaller than the
actual "size", and that is is a "configured" value and not some
hardware property.

>> Also, values with magic block counts, while there is no way to get the
>> blocksize with the same interface, are pretty weird. I think the
>> current "size" attribute is just a bug.
>
> Logical block size is fixed at 512 bytes.  Offset and size are always
> represented in multiples of 512 bytes and only get converted to
> hardware block size in the lld.

Oh, good. Didn't know that this will always be 512, even for devices
with a native size larger than this.

>> Not sure, how that should be solved, by adding a "blocksize" attribute
>> that is always in the same context as the current "size*" values, or
>> by just using bytes for new attributes here.
>>
>> Almost all tools I've seen using these attributes, have hardcoded *
>> 512 in there, which may cause trouble pretty soon. And this is mostly
>> a failure of the interface and not of the users, I think.
>
> No, it will never break.  It will always be 512.

Cool. No problem then. :)

> For userlevel exporting, it might have been better to use just bytes
> there as preformance isn't really an issue, but, well, it's already
> determined, so..

Right, but if it can not change, it's fine, I guess.

Thanks,
Kay

  reply	other threads:[~2009-05-09 16:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-09  0:13 [GIT PATCH] block,scsi,libata: implement alt_size, take#2 Tejun Heo
2009-05-09  0:13 ` Tejun Heo
2009-05-09  0:13 ` [PATCH 1/3] block: add alt_size Tejun Heo
2009-05-09  0:13   ` Tejun Heo
2009-05-09 13:45   ` Kay Sievers
2009-05-09 13:45     ` Kay Sievers
2009-05-09 14:04     ` Tejun Heo
2009-05-09 14:04       ` Tejun Heo
2009-05-09 16:26       ` Kay Sievers [this message]
2009-05-11 13:45       ` [dm-devel] " Konrad Rzeszutek
2009-05-12  0:53         ` Tejun Heo
2009-05-12  0:53           ` [dm-devel] " Tejun Heo
2009-05-09  0:13 ` [PATCH 2/3] scsi: add scsi_device->alt_capacity Tejun Heo
2009-05-09  0:13   ` Tejun Heo
2009-05-09  4:23   ` James Bottomley
2009-05-09 16:09     ` Tejun Heo
2009-05-09 16:09       ` Tejun Heo
2009-05-09 16:23       ` James Bottomley
2009-05-10  1:26         ` Tejun Heo
2009-05-15 19:44         ` ATA ULD (was Re: [PATCH 2/3] scsi: add scsi_device->alt_capacity) Jeff Garzik
2009-05-09  0:13 ` [PATCH 3/3] libata: export HPA size as alt_size Tejun Heo
2009-05-09  0:13   ` Tejun Heo
  -- strict thread matches above, loose matches on Subject: below --
2009-02-01  2:55 [PATCHSET] block,scsi,libata: implement alt_size Tejun Heo
2009-02-01  2:55 ` [PATCH 1/3] block: add alt_size Tejun Heo
2009-02-01  2:55   ` Tejun Heo

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=ac3eb2510905090926r4ac0bc52kb8639101f0c78d86@mail.gmail.com \
    --to=kay.sievers@vrfy.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=Mauelshagen@redhat.com \
    --cc=dan.j.williams@gmail.com \
    --cc=dm-devel@redhat.com \
    --cc=jeff@garzik.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tj@kernel.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 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.