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 copy&paste 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 up profiles, put in kmod-ath9k and wpad-mini by default (fixes #9954) ------------------------------------------------------------------------ r28182 | nbd | 2011-09-05 23:38:23 -0600 (Mon, 05 Sep 2011) | 1 line ar71xx: do not count normal interrupts as spurious (fixes #10037) ------------------------------------------------------------------------ and thinking that the entire x86 family has less churn that the ar71xx in a comparable time. The difference here is that the ar71xx work is being done by people with commit privileges, hence they don't send out patches... they don't have to. They simply commit. I don't have that option. > 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. Since most of that effort occurs as off-channel (personal IMs) to the relevant component owners I'm not sure how I can demonstrate that to you. Also understand that much of the build machinery is not well documented, is in a state of flux, and as we saw recently with bug #9721: I had written the fix to use the notation: DEPENDS:=+(USE_EGLIBC||USE_GLIBC):libbsd only to be told afterward that this notation didn't work, never had, and that making it work was going to be too much effort so to find a workaround instead... Exposing existing bugs isn't a sign of lack of diligence on my part, let's be clear about that. > 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. I thought when I added the "geos" and "alix" platform definitions and asked to be made the owner for these targets, it was pretty clear: to improve the support of these platforms. That's not changed, and if I've done anything since to give the impression that I wasn't still committed to this goal, then that was an err. I also asked to own the "net5501" target if there was sufficient interest. > 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). Openwrt is of course based on Linux as the OS, and Linux today as at its inception, is heavily weighted toward x86 platforms. Indeed Linux runs on more x86 platforms than all other processors put together, according to a market survey I read recently. There is no reason why the x86 support for OpenWrt should be in any way inferior to the support on the MIPS/Broadcom/Atheros chipsets. But I think this is a false dichotomy: as long as there are enough developers with time and commit rights, there's no reason why both processor families can't have excellent support. And to be clear, the $70 Atom-based boards and $90 Geode-based boards I've been seeing *are* at that price commodity hardware. The x86 with glibc/eglibc ABI also has the benefit of having Skype and G.729 codecs available for licensing, which the MIPS can't claim. In that respect, the x86 is much more "commodity hardware" for those working in the VoIP space than the MIPS. > 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. Without your following the list more closely, I don't know how I could demonstrate that. > 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. I work with linux-atm, netdev, linux-geode, and various other groups. You don't see the work going on there: what you see is my taking work that was completed there and porting it to OpenWrt so that this community can benefit from the work as well. Yes, the hardware I work on isn't as common as the AR71xx or BRCM stuff. Some of that has to do with my "day job". It might be a smaller niche with fewer users but that doesn't mean it's without merit. Show me MIPS based SBC's with mini-PCI or mini-PCIe slots, for instance. Most of the OpenWrt targets that I'm aware of have a soldered-on BOM with no expandability. > 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). We talked about this off-line before and I had thought we reached a consensus: since the x86 boards (net5501, wrap, Geos, alix, etc) all start with a minimum of 128MB and 1GB of flash, it made sense to package them based on what would solve 99% of the use cases, rather than simply what would fit into flash. It makes sense to have "small", "medium", and "large" packaging for OpenWrt. In this case, the x86 boards would probably fit the "medium" or "large" rubric with the corresponding richness of functionality that such dimensioning affords one. As for "openssl" in particular: the Geode processor (with the net5501, alix, and Geos all use) has a fairly decent crypto-engine on-chip with the CPU. This requires building a customized version of Openssl for this hardware that supports cryptodev, and a specialized kernel with the underlying support. It's also the case that such boxes are frequently used to terminate OpenVPN and Ipsec-Tools VPN connections into, so that fit the 99% use case model. As for building using an image generator and appropriate scripts, I already do that: my own .defconfig file includes 148 packages (mostly Asterisk stuff) that isn't part of the pared down configurations. The default "alix" image, by contrast, only selects 6 non-kernel module packages. I don't think that's excessive. Even "geos" selects 13 non-kernel module packages, and 8 of them are there for user-space hardware support. > Regards, > > Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
