From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25565 invoked by alias); 8 May 2009 15:56:35 -0000 Received: (qmail 25556 invoked by uid 22791); 8 May 2009 15:56:34 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mtaout03-winn.ispmail.ntl.com (HELO mtaout03-winn.ispmail.ntl.com) (81.103.221.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 May 2009 15:56:28 +0000 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090508155624.BZPL18643.mtaout03-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Fri, 8 May 2009 16:56:24 +0100 Received: from cog.dallaway.org.uk ([86.9.207.237]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090508155624.ZFCF2093.aamtaout03-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Fri, 8 May 2009 16:56:24 +0100 Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id n48FuLpn003962; Fri, 8 May 2009 16:56:22 +0100 Message-ID: <4A045625.9080706@dallaway.org.uk> Date: Fri, 08 May 2009 15:56:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 To: Simon Kallweit CC: eCos development list , John Eigelaar Subject: Re: lwIP upgrade to CVS HEAD References: <49F83C8B.9000108@intefo.ch> <4A001575.1060107@dallaway.org.uk> <4A0022F9.5020207@intefo.ch> In-Reply-To: <4A0022F9.5020207@intefo.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-05/txt/msg00002.txt.bz2 Hi Simon John Dallaway wrote: > I will review the CDL. The CDL is looking good so far. There's some scope for improving the dependency info. For example, CYGIMP_LWIP_MEMP_MEM_MALLOC could specify: requires { CYGINT_ISO_MEMALLOC != 0 } default_value { CYGINT_ISO_MEMALLOC != 0 } Many of the protocol components and options are also likely to "require" either CYGPKG_LWIP_TCP or CYGPKG_LWIP_UDP. There may also be some scope for active_if constraints to clarify the relevance of certain options. For example, could CYGPKG_LWIP_NETCONF be made "active_if !CYGPKG_LWIP_DHCP"? This may not be possible if the static networking address definitions are still required for correct compilation when DHCP is enabled. Finally, I would make the display strings of the numerous protocol support components and options just a little more verbose. For example: "DHCP" -> "DHCP support" "ICMP" -> "ICMP support" and so on. There are currently 27 items directly under the lwIP package node in the tree. Perhaps there is some scope for further grouping of these nodes to give the tree more depth and less breadth. For example, a "Protocol support" component of "flavor none" containing the various protocol components? >> The sequential API is required for the socket API and desirable in its >> own right as it provides a good compromise between ease of use and >> memory footprint. John Eigelaar has indicated that he would be willing >> to help with this and already has a copyright assignment in place. > > Any help is appreciated. I will gladly help testing and do work on this > too, when there is need. But I would like to have John Eigelaar commit > his changes and go from there instead of going from scratch. > >> We will need more functionality in place before we can replace the >> existing lwIP port in the eCos repository trunk. We could use your own >> tree or we could cut a branch in the eCos repository. I would prefer to >> branch the eCos repository as this would enhance visibility within the >> eCos community, gives a better sense of shared ownership, and allows the >> eCos maintainers to monitor progress more easily. Be assured that I am >> keen to support this lwIP port update and will ensure that patches are >> committed to the branch quickly. > > I think that's a good idea. OK. Send me a tarball of the updated package when you're ready to start collaborating and I'll check it in on a new branch. John Dallaway