Re: [OpenWrt-Devel] [Alix2] [Geode] [Geos] Note to Philip Prindeville

2011-09-07 Thread Philip Prindeville
On 9/6/11 12:04 AM, Daniel Dickinson wrote:
 Hi Phillip,
 
 Could you please stop sending millions of small patches on the
 assumption that small == trivial.  A trivial patch is a patch that is
 complete in and of itself and doesn't need more patches before or after
 to finish solving whatever problem it is related to, and is one-time
 thing that only rarely is possible.

Maybe we don't have the same understanding of either the words small or 
trivial.

For instance:

http://patchwork.midlink.org/patch/1394/

which I consider to be both.  Am I mistaken?


 You're working on platform support for Geode platforms such as Geos and
 Alix2, so could you please try to get platform support fully integrated
 and working in a patch or patch series, and then submit the completed
 (or to the best of your genuine knowledge complete) patch or patch
 series, rather than bombarding the list with patches and getting
 impatient because your patches aren't applied quickly.

I'm looking at:

svn log -r27878:HEAD target/linux/ar71xx

r27878 | nbd | 2011-08-02 09:12:08 -0600 (Tue, 02 Aug 2011) | 2 lines

ar71xx: add some hacks to work around the misalignment in IP packets received 
on AR71xx and AR91xx ethernet MACs
decreases CPU load with the default firewall for routing 95 mbit/s from 78% to 
55%

r27894 | nbd | 2011-08-04 11:36:23 -0600 (Thu, 04 Aug 2011) | 1 line

ar71xx: fix MAC/MDIO reset mask handling

r27895 | nbd | 2011-08-04 11:36:27 -0600 (Thu, 04 Aug 2011) | 8 lines

ag71xx: fix memory corruption issues on ar7240 on ethernet start/stop

When the DMA engine state gets corrupted due to a hardware issues, it
often won't stop rx until a full reset is issued. In that case the hardware
must keep a valid descriptor, otherwise it will write to random places in
system RAM, triggering random crashes. To fix this, keep a dummy descriptor
without a buffer that keeps the DMA engine in a sane state until the reset
is done

r27896 | nbd | 2011-08-04 11:36:31 -0600 (Thu, 04 Aug 2011) | 6 lines

ar71xx: fix ethernet FIFO state corruption on ar7240

When starting/stopping DMA sometimes the FIFO state gets corrupted,
leading to wildly fluctuating latencies or packet data corruption.
Fix this by issuing a fast MAC reset as soon as the link is detected
as up. Fixes #9689, #9405

r27899 | juhosg | 2011-08-04 13:41:16 -0600 (Thu, 04 Aug 2011) | 1 line

ar71xx: cleanup image generation Makefile

r27900 | juhosg | 2011-08-04 13:41:17 -0600 (Thu, 04 Aug 2011) | 1 line

ar71xx: use the same test for AP121 and Zcomax sysupgrade images

r27901 | juhosg | 2011-08-04 13:41:18 -0600 (Thu, 04 Aug 2011) | 1 line

ar71xx: enable sysupgrade on the AP96 and DB120 boards

r27907 | juhosg | 2011-08-05 04:31:52 -0600 (Fri, 05 Aug 2011) | 1 line

ar71xx: fix image generation

r27950 | nbd | 2011-08-10 16:24:56 -0600 (Wed, 10 Aug 2011) | 1 line

ar71xx: fix a copypaste bug that broke wzr-hp-g300nh and wzr-hp-ag300h images 
(#9918)

r27951 | jogo | 2011-08-10 17:02:56 -0600 (Wed, 10 Aug 2011) | 1 line

ar71xx: make ehci patch apply again

r27959 | nbd | 2011-08-11 07:52:40 -0600 (Thu, 11 Aug 2011) | 1 line

ar71xx: adjust the mtd layout of tew-632brp and dir-615c to match the image 
layout (fixes #9922)

r27973 | nbd | 2011-08-13 15:49:46 -0600 (Sat, 13 Aug 2011) | 1 line

ar71xx: on ar724x only reset the link status in the restart handler, the fast 
reset takes care of DMA stuck issues

r27975 | nbd | 2011-08-13 16:30:14 -0600 (Sat, 13 Aug 2011) | 1 line

ar71xx: add some code to detect DMA stuck conditions on ar7240

r28022 | hauke | 2011-08-16 16:04:10 -0600 (Tue, 16 Aug 2011) | 2 lines

kernel: update kernel to version 2.6.39.4


r28124 | nbd | 2011-08-29 15:23:46 -0600 (Mon, 29 Aug 2011) | 1 line

ar71xx: fix ethernet PLL setting on ar7242

r28173 | nbd | 2011-09-05 12:37:48 -0600 (Mon, 05 Sep 2011) | 1 line

ar71xx: clean 

[OpenWrt-Devel] [Alix2] [Geode] [Geos] Note to Philip Prindeville

2011-09-06 Thread Daniel Dickinson
Hi Phillip,

Could you please stop sending millions of small patches on the
assumption that small == trivial.  A trivial patch is a patch that is
complete in and of itself and doesn't need more patches before or after
to finish solving whatever problem it is related to, and is one-time
thing that only rarely is possible.

You're working on platform support for Geode platforms such as Geos and
Alix2, so could you please try to get platform support fully integrated
and working in a patch or patch series, and then submit the completed
(or to the best of your genuine knowledge complete) patch or patch
series, rather than bombarding the list with patches and getting
impatient because your patches aren't applied quickly.

I realize that mistakes do occur, but I'd like to see some sign you're
actually making an effort to minimize unnecessary work for us, the
devs, rather than just hacking on trunk with us as intermediaries.

It would also make clearer what you are trying to achieve so we can
best see how to integrate that with the OpenWrt philosophy and existing
platforms and userbase.

While I personally am interested in seeing a solution to the problem of
meeting multiple embedded needs, it can't come at the expense of the
core platforms and userbase.  (The core of openwrt is wireless routers
and access points based on commodity hardware).

It would help if you told us your destination and ideas you had for a
shared space with consumer hardware, and if you demonstrated that you
weren't just doing many small, incomplete, and untested hacks.

For platform support, I personally would like to see what you think is a
(fairly) complete solution, and then work with us on the things that
need to changed.  That's how I got started with extroot.  I didn't
submit it as a series of tiny edits, but as a complete solutions.
There were some more subtle bugs, and I've refactored since then, but
on the whole it worked, and filled a much-requested feature in a way
that fit into OpenWrt.

Also, if you want me to go over some things I've learned about how to
setup the builds system and image generator and environments so that I
can build images based on openwrt, but with different use cases than the
default openwrt (and hence different packages, configs, etc), without
having to change openwrt trunk/backfire to git my goals, I should write
it up on the wiki anyway.

Understanding how to build images (easily) that include
features/configuration that aren't appropriate as OpenWrt defaults
(e.g. trunk/backfire) could help ease some tension you have with the
openwrt defaults I think.  (for example including large packages like
openssl in the default configuration isn't necessary; you can achieve
that goal with image generator and an appropriate script, without a lot
of effort).

Regards,

Daniel
-- 
erno hm. I've lost a machine.. literally _lost_. it responds to ping, 
it works completely, I just can't figure out where in my apartment it
is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C  http://gnupg.org



signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [Alix2] [Geode] [Geos] Note to Philip Prindeville

2011-09-06 Thread Benjamin Henrion
On Tue, Sep 6, 2011 at 9:04 AM, Daniel Dickinson
dan...@cshore.neomailbox.net wrote:
 Hi Phillip,

 Could you please stop sending millions of small patches on the
 assumption that small == trivial.  A trivial patch is a patch that is
 complete in and of itself and doesn't need more patches before or after
 to finish solving whatever problem it is related to, and is one-time
 thing that only rarely is possible.

 You're working on platform support for Geode platforms such as Geos and
 Alix2, so could you please try to get platform support fully integrated
 and working in a patch or patch series, and then submit the completed
 (or to the best of your genuine knowledge complete) patch or patch
 series, rather than bombarding the list with patches and getting
 impatient because your patches aren't applied quickly.

Just use github.

--
Benjamin Henrion bhenrion at ffii.org
FFII Brussels - +32-484-566109 - +32-2-4148403
In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel