Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org, toolchain-devel@blackfin.uclinux.org
Subject: Re: [PATCH v2] sim: cfi: new flash device simulation
Date: Fri, 25 Mar 2011 00:13:00 -0000	[thread overview]
Message-ID: <AANLkTikCcVsrhhnCXNybYBpD8WGjF48CAxY4+dix+aB5@mail.gmail.com> (raw)
In-Reply-To: <20110324151403.GM2520@adacore.com>

On Thu, Mar 24, 2011 at 11:14 AM, Joel Brobecker wrote:
> There are just a few minor comments:
>  - opening curly brace in struct union declarations should be on
>    the next line

some habits die hard ;).  especially when i looked at sim/common/ and
they all use the style i did.

>  - We're not fond of commented out code.  You could replace it by
>    a comment if useful.

only place i see this is top of cfi_io_read_buffer() where a minor
check is #ifdef-ed out.

i guess i could change it to something like:
  /* XXX: Should we require read's to have cfi->width == nr_bytes ?  */

obviously i prefer the existing #if 0 approach since it has been tested ;)

>  - I realize that this is a large-ish job, but it would be nice to
>    have all types and routines documented.  Generally, it's even
>    preferable to document the fields in the struct/union types,
>    but a small description of the type will be a good start for now.

the fields should match 1:1 to the CFI spec, but i can sprinkle some
comments about and see what happens.  i spent the most time on the
comment that people who want to *use* the code need.  after all,
people should only need to care about the device tree format and not
know any of the internals.

>  - I think that this deserves a NEWS entry

in gdb/NEWS i guess

>  - And I think that we should add some documentation in the GDB
>    Manual.  The simulator section is almost non-existent in the
>    current manual, but if we could start defining a general structure,
>    even if they are empty, and document this new feature in that
>    structure, at least we won't make things worse.

yeah, i think you mentioned this before
-mike


  reply	other threads:[~2011-03-24 20:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-31  6:33 [PATCH] " Mike Frysinger
2011-02-07  6:11 ` Mike Frysinger
2011-03-15 20:11   ` Mike Frysinger
2011-03-24 11:24 ` [PATCH v2] " Mike Frysinger
2011-03-24 15:50   ` Joel Brobecker
2011-03-25  0:13     ` Mike Frysinger [this message]
2011-03-25  9:49 ` [PATCH v3] " Mike Frysinger
2011-03-25 15:55   ` Joel Brobecker
     [not found] ` <1301012212-2372-1-git-send-email-vapier__17299.0819243298$1301012210$gmane$org@gentoo.org>
2011-03-25 15:54   ` =?UTF-8?q?=5BPATCH=20v3=5D=20sim=3A=20cfi=3A=20new=20flash=20device=20simulation?= Frank Ch. Eigler
2011-03-26  7:00 ` [PATCH v4] sim: cfi: new flash device simulation Mike Frysinger
2011-03-29 15:41   ` Joel Brobecker
2011-03-29 20:22     ` Mike Frysinger

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=AANLkTikCcVsrhhnCXNybYBpD8WGjF48CAxY4+dix+aB5@mail.gmail.com \
    --to=vapier@gentoo.org \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=toolchain-devel@blackfin.uclinux.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