From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] Flatten and solidify block_dev_desc layout
Date: Mon, 24 Oct 2011 12:49:53 +0200 [thread overview]
Message-ID: <m2fwiioe9a.fsf@ohwell.denx.de> (raw)
In-Reply-To: <CANJuy2JSg5c=z=teoNug3C=xn=gic+Nxd1HPkgRzpOopASmd5Q@mail.gmail.com> (Che-liang Chiou's message of "Mon, 24 Oct 2011 11:36:56 +0800")
Hi Che-liang,
> I guess I have to put this patchset on hold. I will get you back if we
> could proceed with this patchset.
Please don't top-post. The mails really are more difficult to read in
context.
> Regards,
> Che-Liang
>
> On Sat, Oct 22, 2011 at 3:09 AM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Che-Liang Chiou,
>>
>> In message <1319178708-10881-2-git-send-email-clchiou@chromium.org> you wrote:
>>> The block_dev_desc struct has #ifdef on lba48 and variable-size on lba
>>> and so its layout varies from config to config. ?At least part_efi.c has
>>> partially complained about this.
>>>
>>> This patch makes lba48 be always defined and lba be fixed to largest
>>> size that an LBA would need so that the block_dev_desc layout would be
>>> an invariant with respect to configurations.
>>>
>>> Doing so would waste a few extra bytes per struct block_dev_desc, which
>>> I believe is not critical.
>>
>> How much exactly is "a few bytes"?
As far as I can see, the difference is 4 bytes _and_ it is a runtime
data structure, so it should not make any difference for the code size.
Che-liang can surely correct me if I'm wrong.
Moreover it seems we need to do something comparable sooner or later.
If we want to support large block devices and the partition code uses
block devices, that code needs to be prepared to work with that. So in
general I'm in favor of doing something like this.
On the other hand, the patch changes the datatype of a field which gets
used in lots of places - Che-liang, did you run a MAKEALL with this
patch and check that no more warnings/errors are introduced?
Cheers
Detlev
--
The latest code looks a bit similar to the old [linux] big-reader-locks hack
(which got dropped for good many eons ago and with which i deny any involvement
with, such as having authored it. [oh, did i say that out loud? crap.]), imple-
mented cleanly and properly. -- Ingo Molnar <20090428124033.GA1655@elte.hu>
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
next prev parent reply other threads:[~2011-10-24 10:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-21 6:31 [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes Che-Liang Chiou
2011-10-21 6:31 ` [U-Boot] [PATCH 1/2] Flatten and solidify block_dev_desc layout Che-Liang Chiou
2011-10-21 19:09 ` Wolfgang Denk
2011-10-24 3:36 ` Che-liang Chiou
2011-10-24 10:49 ` Detlev Zundel [this message]
2011-10-21 6:31 ` [U-Boot] [PATCH 2/2] api: storage: Share attributes with block_dev_desc Che-Liang Chiou
2012-01-08 7:26 ` Mike Frysinger
2011-10-21 7:03 ` [U-Boot] [PATCH 1/2] Flatten and solidify block_dev_desc layout Che-Liang Chiou
2011-10-21 16:06 ` [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes Detlev Zundel
2011-10-24 3:36 ` Che-liang Chiou
2011-10-24 9:32 ` Detlev Zundel
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=m2fwiioe9a.fsf@ohwell.denx.de \
--to=dzu@denx.de \
--cc=u-boot@lists.denx.de \
/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