qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Blue Swirl" <blauwirbel@gmail.com>
To: dsilvers@simtec.co.uk, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] DM9000 network card driver
Date: Mon, 10 Nov 2008 18:47:02 +0200	[thread overview]
Message-ID: <f43fc5580811100847p87ff700k1d3727538143968b@mail.gmail.com> (raw)
In-Reply-To: <1226313089.10490.3.camel@petitemort>

On 11/10/08, Daniel Silverstone <dsilvers@simtec.co.uk> wrote:
> On Mon, 2008-10-27 at 10:49 +0000, Daniel Silverstone wrote:
>  > I think this fell through the cracks, so here it is again.
>  > The Davicom DM9000 10/100 Ethernet controller.
>
>  I don't see any replies to this -- it's possible that my list
>  subscription was playing up at the time, so I thought I'd re-poke about
>  it.
>
>  Basically I'm desperate to know if I'm even going the right way in my
>  patches -- am I getting them to a state where they could be merged, or
>  am I wasting my time? Is there an FAQ I need to read which will tell me
>  how to present these patches in a way which is easier for you all to
>  deal with them?
>
>  I'm just somewhat disheartened that I see patches turn up and get
>  discussed strongly, and then the updated patches end up being merged,
>  where after the initial discussion, this patch kinda got dropped on the
>  floor without an explicit "no" or anything; sitting for two weeks
>  untouched on-list.
>
>  I appreciate that you're all busy, so if the answer is simply "You're on
>  the list, just it'll be a while" then at least I can carry that back to
>  my boss who wants to know how it's going getting these patches to you.

Well, for example I could comment on the patches from general point of
view (as I seem to have more time in my hands than some), but then I
don't usually have any means to check if the emulator (or the device)
in question even works with patch applied, or whether the patch makes
sense from the machine architecture POV. For that, the maintainer
should OK the patch.

Your patch looks very clean. I wouldn't use devices.h for the
prototype, but instead some board file (for example arm-misc.h).

The device is not used by any board, so it's not possible even for the
maintainer to test the patch.

As there is a reset function already, it should not be too difficult
to register that for system_reset use.

Save/load functions would be nice, though IIRC ARM boards/devices
don't have any yet.

  reply	other threads:[~2008-11-10 16:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-27 10:49 [Qemu-devel] [PATCH] DM9000 network card driver Daniel Silverstone
2008-11-10 10:31 ` Daniel Silverstone
2008-11-10 16:47   ` Blue Swirl [this message]
2008-11-11 11:21     ` Daniel Silverstone
2008-11-11 18:01       ` Blue Swirl

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=f43fc5580811100847p87ff700k1d3727538143968b@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --cc=dsilvers@simtec.co.uk \
    --cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).