public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Igor Grinberg <grinberg@compulab.co.il>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data
Date: Tue, 05 Feb 2013 13:38:55 +0200	[thread overview]
Message-ID: <5110EF4F.3080308@compulab.co.il> (raw)
In-Reply-To: <20130205095703.9D02220053B@gemini.denx.de>

On 02/05/13 11:57, Wolfgang Denk wrote:
> Dear Igor Grinberg,
> 
> In message <5110BDB2.8040800@compulab.co.il> you wrote:
>>
>>> Yes, struct bmp_header is a packed array with non-natural order of
>>> entries; see also section "Bitmap file header" at [1]; we may consider
>>> this a really stupid thing to do, but we have to live with this fact.
>>
>> It was not that stupid in times of DOS and Win 3.1
>> when int was 16 bits long (and DRAM was 64K or even less)...
> 
> It was as stupid then, too.  At that time, a large number of systems
> with similar alignment requirements existed, and experience with these
> existed, too.
> 
> Do you remember the "The Ten Commandments for C Programmers"?  If not,
> look them up and check how old these are.  Note especially the ``All
> the world's a VAX'' part - this is exactly what we see here in
> operation.

Yep. Agreed on this.
Although, I don't know, if anyone of us would tell the same 20+ years ago...
It is now we can...

> 
> The design of the BMP header is just BRAINDEAD.

That is for sure.

> 
>>> Indeed, this should be documented.  And eventually the bmp command
>>> should print a warning message if it sees other alignment.
>>
>> Agreed on this also, but again what about the board brick case?
> 
> There is a ton of ways to brick a board.  Why should we add protection
> for one special case while we agree to leave the 50 other ways
> onfixed?

Because, I think this one is a bit different because of the bmp header
and also is of very high demand.

> 
>> Should we add the check for alignment and if it does not properly aligned
>> deny further bmp header processing along with printing a warning?
> 
> Why should we?  Who tells that this is not perfectly legal on the
> running system?

It might be perfectly legal, but we also consider a tons of work
explaining why and how this should be done (needless to mention the
amount of bricked boards).
Instead of simplifying the case, and I think this is a special case,
at least because of the high demand and user (who is not a programmer)
selectable address, you want us to teach the whole world about the bmp
header alignment issues?

> 
> 
> Let me repeat it: U-Boot is a boot loader.  It is not intended for
> meddling by avarage Johnny Loser, but for system programmers who know
> what they are doing. And anyone doing such things is well adviced to
> _test_ his settings on the command line before storing these for
> automatic use.  As I mentioned before, omitting such tests is a sin
> that carries with it its own punishment.

What are you trying to say?
Is it that the environment variables change and in particular
the splash screen installation _must_ be done by a programmer?
Hmm.. that does not sound good...


-- 
Regards,
Igor.

  reply	other threads:[~2013-02-05 11:38 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04 11:39 [U-Boot] [PATCH 0/5] Create an API for safely accessing BMP header fields Nikita Kiryanov
2013-02-04 11:39 ` [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data Nikita Kiryanov
2013-02-04 19:26   ` Wolfgang Denk
2013-02-04 21:26     ` Albert ARIBAUD
2013-02-04 23:11       ` Wolfgang Denk
2013-02-05  8:07         ` Igor Grinberg
2013-02-05  9:57           ` Wolfgang Denk
2013-02-05 11:38             ` Igor Grinberg [this message]
2013-02-05 13:20               ` Wolfgang Denk
2013-02-05 14:49                 ` Igor Grinberg
2013-02-05 19:27                   ` Wolfgang Denk
2013-02-05  6:52     ` Nikita Kiryanov
2013-02-05  9:47       ` Wolfgang Denk
2013-02-04 11:39 ` [U-Boot] [PATCH 2/5] lcd: use bmp_layout API Nikita Kiryanov
2013-02-04 11:39 ` [U-Boot] [PATCH 3/5] cmd_bmp: " Nikita Kiryanov
2013-02-04 11:39 ` [U-Boot] [PATCH 4/5] video/cfb_console: " Nikita Kiryanov
2013-02-04 11:39 ` [U-Boot] [PATCH 5/5] video/bus_vcxk: " Nikita Kiryanov
2013-02-04 11:57 ` [U-Boot] [PATCH 0/5] Create an API for safely accessing BMP header fields Albert ARIBAUD
2013-02-04 12:37   ` Nikita Kiryanov
2013-02-04 14:19     ` Albert ARIBAUD
2013-02-04 15:07       ` Nikita Kiryanov
2013-02-04 15:25         ` Albert ARIBAUD
2013-02-04 20:48           ` Wolfgang Denk
2013-02-05  7:20           ` Nikita Kiryanov
2013-02-04 20:39       ` Wolfgang Denk
2013-02-05 14:58       ` Tom Rini
2013-02-05 19:37         ` Albert ARIBAUD
2013-02-04 20:35     ` Wolfgang Denk
2013-02-04 21:02       ` Jeroen Hofstee
2013-02-05  7:39         ` Igor Grinberg
2013-02-05  6:53 ` Igor Grinberg
2013-02-05  7:22   ` Nikita Kiryanov

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=5110EF4F.3080308@compulab.co.il \
    --to=grinberg@compulab.co.il \
    --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