From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KzZut-0005ot-LU for qemu-devel@nongnu.org; Mon, 10 Nov 2008 11:47:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KzZur-0005nl-Vg for qemu-devel@nongnu.org; Mon, 10 Nov 2008 11:47:07 -0500 Received: from [199.232.76.173] (port=35517 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KzZur-0005nT-LB for qemu-devel@nongnu.org; Mon, 10 Nov 2008 11:47:05 -0500 Received: from wf-out-1314.google.com ([209.85.200.174]:30426) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KzZuq-0003HH-Vu for qemu-devel@nongnu.org; Mon, 10 Nov 2008 11:47:05 -0500 Received: by wf-out-1314.google.com with SMTP id 27so2707895wfd.4 for ; Mon, 10 Nov 2008 08:47:02 -0800 (PST) Message-ID: Date: Mon, 10 Nov 2008 18:47:02 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] DM9000 network card driver In-Reply-To: <1226313089.10490.3.camel@petitemort> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1225104596.24465.3.camel@petitemort> <1226313089.10490.3.camel@petitemort> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dsilvers@simtec.co.uk, qemu-devel@nongnu.org On 11/10/08, Daniel Silverstone 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.