linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Murray Jensen <Murray.Jensen@cmst.csiro.au>
To: Val Henson <val@nmt.edu>
Cc: benh@kernel.crashing.org, linuxppc-dev@lists.linuxppc.org
Subject: Re: EV-64260-BP & GT64260 bi_recs
Date: Sun, 24 Mar 2002 00:07:27 +1100	[thread overview]
Message-ID: <9477.1016888847@msa.cmst.csiro.au> (raw)
In-Reply-To: Your message of "Fri, 22 Mar 2002 21:01:03 -0700" <20020322210103.C3363@boardwalk>


On Fri, 22 Mar 2002 21:01:03 -0700, Val Henson <val@nmt.edu> writes:
>while (rec->tag != BI_LAST) {
>  /* fiddle with each individual record */
>  rec = (struct bi_record *)((ulong)rec + rec->size);
>}

Won't this code still work with benh's proposal? The "fiddle" part above
may delve into the structure, but at the top level the record is still
treated exactly like above.

>The simplicity of this system is valuable - I don't want to give it up
>unless we get lots and lots of added functionality in return.

I agree with this. In fact, we shouldn't give up simplicity for any reason.

>Dan
>Malek's comments suggest that bi_recs should only be used for only a
>small, simple class of information.  In this context, I don't see what
>structures buy us.

That's because he sees no value in having a lot of data passed in from the
boot loader. On the other hand, I believe that if the kernel can learn
something from the boot loader, it should - rather than duplicate the code
that is already in the boot loader, or hard-wire configuration information -
and if this ends up being a lot of data and/or with a complicated structure
(this isn't automatically the case btw), then so be it. This can be achieved
with "simple" bi_recs, if they are defined in the right way.

>I have to admit, bi_rec structures are a really cool idea, but I
>prefer simplicity over coolness. :)

The beauty of the proposal is that it *is* simple. bi_recs within bi_recs.
The top level treats the record as one (typeless) chunk of data. I have
actually requested *more* types (e.g. arrays), and also the saving of
certain (most?) bi_recs so that loadable modules can consult them later
(rather than requiring code in the kernel startup to parse the records).
Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-03-23 13:07 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-20  0:43 EV-64260-BP & GT64260 bi_recs Michael Sokolov
2002-03-19 23:00 ` Mark A. Greer
2002-03-20  7:55   ` Wolfgang Denk
2002-03-20 13:19 ` benh
2002-03-20 15:30   ` Michael Sokolov
2002-03-20 16:19     ` Tom Rini
2002-03-20 16:58       ` benh
2002-03-23  4:01         ` Val Henson
2002-03-23 13:07           ` Murray Jensen [this message]
2002-03-24 12:22             ` Benjamin Herrenschmidt
2002-03-24 12:20           ` Benjamin Herrenschmidt
2002-03-24 19:09             ` Val Henson
2002-03-24 16:46               ` Benjamin Herrenschmidt
2002-03-25  8:51                 ` Geert Uytterhoeven
2002-03-24 18:16                   ` Benjamin Herrenschmidt
2002-03-26  2:16                 ` Val Henson
2002-03-26 10:05                   ` Benjamin Herrenschmidt
2002-03-24 19:38               ` Geert Uytterhoeven
2002-03-24 16:55                 ` Benjamin Herrenschmidt
2002-03-24 17:18                   ` Benjamin Herrenschmidt
2002-03-25  0:44               ` Murray Jensen
2002-03-25 22:05                 ` Val Henson
2002-03-26  3:21             ` Val Henson
2002-03-26  4:14               ` Murray Jensen
2002-03-26 10:14               ` benh
2002-03-26 12:05                 ` Gabriel Paubert
2002-03-26 12:18                   ` benh
2002-03-26 23:24             ` Mark A. Greer
2002-03-26 21:40               ` benh
2002-03-27 15:13                 ` Mark A. Greer
  -- strict thread matches above, loose matches on Subject: below --
2002-03-27 20:09 Michael Sokolov
2002-03-27 18:53 Michael Sokolov
2002-03-27 19:37 ` benh
2002-03-27 18:34 Michael Sokolov
2002-03-27 18:32 Michael Sokolov
2002-03-27 18:46 ` benh
2002-03-27 18:03 Michael Sokolov
2002-03-27 16:16 ` Mark A. Greer
2002-03-27 16:24   ` Mark A. Greer
2002-03-27 18:40   ` benh
2002-03-27 18:02     ` Mark A. Greer
2002-03-27 18:06       ` Mark A. Greer
2002-03-27 17:32 Michael Sokolov
2002-03-27 15:46 ` Mark A. Greer
2002-03-27 17:48 ` benh
2002-03-27 15:59   ` Mark A. Greer
2002-03-27  2:37 Michael Sokolov
2002-03-26 21:52 ` benh
2002-03-27 14:15   ` Matt Porter
2002-03-27 15:10     ` Mark A. Greer
2002-03-27 15:15       ` Mark A. Greer
2002-03-27 17:47         ` benh
2002-03-28  9:14       ` Geert Uytterhoeven
2002-03-27  1:35 Michael Sokolov
2002-03-26 23:48 ` Mark A. Greer
2002-03-24 16:02 Michael Sokolov
2002-03-21  2:13 Michael Sokolov
2002-03-21  6:39 ` Dan Malek
2002-03-31  8:32   ` Paul Mackerras
2002-04-01 18:39     ` Dan Malek
2002-04-02  5:32       ` Paul Mackerras
2002-04-02 16:33         ` Tom Rini
2002-04-02 17:29         ` Dan Malek
2002-04-02 14:42           ` Armin
2002-04-02 20:12           ` Tom Rini
2002-04-02 21:02             ` Dan Malek
2002-04-03  0:21               ` Tom Rini
     [not found] <dan@embeddededge.com>
     [not found] ` <3C98DA15.50302@embeddededge.com>
2002-03-21  1:11   ` Murray Jensen
2002-03-21  6:50     ` Dan Malek
2002-03-21 11:05       ` Murray Jensen
2002-03-21  1:10 Michael Sokolov
2002-03-21  0:57 Michael Sokolov
2002-03-21  6:58 ` Dan Malek
2002-03-21  0:47 Michael Sokolov
     [not found] <3C98B189.78A92DFE@mvista.com>
2002-03-20 18:12 ` Wolfgang Denk
     [not found]   ` <3C98DB49.2C3A2F79@mvista.com>
2002-03-23  3:49     ` Val Henson
2002-03-20 17:11 Michael Sokolov
2002-03-20 18:06 ` Wolfgang Denk
2002-03-20 17:04 Michael Sokolov
2002-03-20 17:25 ` Tom Rini
2002-03-21 20:36 ` Troy Benjegerdes
2002-03-21 19:17   ` Mark A. Greer
2002-03-21 21:36     ` Jim Potter
     [not found] <20020320164025.31626@mailhost.mipsys.com>
2002-03-20 16:59 ` Wolfgang Denk
     [not found] <20020320155551.GD3762@opus.bloom.county>
2002-03-20 16:18 ` Wolfgang Denk
     [not found] <20020320150119.GB3762@opus.bloom.county>
2002-03-20 15:43 ` Wolfgang Denk
2002-03-20  1:02 Michael Sokolov
     [not found] <20020320000500.GV3762@opus.bloom.county>
2002-03-20  0:28 ` Wolfgang Denk
     [not found] <20020319235815.GU3762@opus.bloom.county>
2002-03-20  0:24 ` Wolfgang Denk
     [not found] <20020319224420.GO3762@opus.bloom.county>
2002-03-19 23:00 ` Wolfgang Denk
2002-03-20  0:03 ` Gabriel Paubert
     [not found] <20020319231628.GQ3762@opus.bloom.county>
2002-03-19 23:46 ` Wolfgang Denk
     [not found] <3C97A9C1.EBA150B6@mvista.com>
2002-03-19 23:36 ` Wolfgang Denk

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=9477.1016888847@msa.cmst.csiro.au \
    --to=murray.jensen@cmst.csiro.au \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=val@nmt.edu \
    /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;
as well as URLs for NNTP newsgroup(s).