From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19623 invoked by alias); 27 Oct 2009 07:57:59 -0000 Received: (qmail 19615 invoked by uid 22791); 27 Oct 2009 07:57:58 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_40 X-Spam-Check-By: sourceware.org Received: from proxy2.bredband.net (HELO proxy2.bredband.net) (195.54.101.72) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Oct 2009 07:57:53 +0000 Received: from iph1.telenor.se (195.54.127.132) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC005D1965 for ecos-devel@ecos.sourceware.org; Tue, 27 Oct 2009 08:57:50 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYkAOdE5kpV4dhzPGdsb2JhbAAImyoBAQEBN7wdhD8E Received: from c-73d8e155.355-1-64736c10.cust.bredbandsbolaget.se (HELO [192.168.0.185]) ([85.225.216.115]) by iph1.telenor.se with ESMTP; 27 Oct 2009 08:57:50 +0100 Message-ID: <4AE6A7FD.4000903@siva.com.mk> Date: Tue, 27 Oct 2009 07:57:00 -0000 From: Ilija Kocho User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: Re: Ethernet over SPI driver for ENC424J600 References: <4AE546ED.3000303@siva.com.mk> <4AE56642.20201@dallaway.org.uk> <4AE58C05.9000305@ecoscentric.com> <20091026212810.GA12538@sg-laptop> <4AE61FE7.3050404@dallaway.org.uk> In-Reply-To: <4AE61FE7.3050404@dallaway.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-10/txt/msg00062.txt.bz2 John Dallaway wrote: > Hi Sergei > > Sergei Gavrikov wrote: > > >> Hello guys, may be I miss something but I thought that any Ethernet >> eCos driver is enough abstract thing to manage ETH L2 and that does >> not depend (well, depends a bit) on any next layer, e.g., a TCP/IP >> implementation (RedBoot TCP/IP, *BSD, lwIP* stacks) even if the driver >> uses another channel (SPI) to get a memory access to MAC buffers. I >> talk about generic io/eth/* stuff and..., well some kind of a future >> devs/eth/mc/spi/* eth_drv_.* routines, for example. >> > > In theory, of course, you are correct. The network abstractions should > ensure compatibility between any ethernet device driver and any TCP/IP > stack. But in practice, testing can reveal all manner of issues which > no-one was expecting. > This is our first eCos driver of this kind and we take the abstraction and stack independence for granted. It may save us some effort and help bring the driver sooner if somebody more experienced points out potential potholes. Regards Ilija Kocho