This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: CDL interfaces for eCos networking
- From: Bart Veer <bartv at ecoscentric dot com>
- To: John Dallaway <john at dallaway dot org dot uk>
- Cc: ecos-devel at ecos dot sourceware dot org, simon dot kallweit at intefo dot ch, john at kses dot net
- Date: Tue, 12 May 2009 18:00:15 +0100
- Subject: Re: CDL interfaces for eCos networking
- References: <4A099A39.1060606@dallaway.org.uk>
>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes:
John> I've noticed that the common networking infrastructure
John> package (CYGPKG_NET) declares the same CDL interfaces as the
John> lwIP package (CYGPKG_NET_LWIP):
John> cdl_interface CYGPKG_NET_STACK
John> cdl_interface CYGPKG_NET_STACK_INET
John> cdl_interface CYGPKG_NET_STACK_INET6
John> Presumably these interface declarations were placed in
John> CYGPKG_NET at a time when it was assumed that _all_
John> networking stack implementations would use that package.
John> Now we have the lwIP stack which does not use CYGPKG_NET. If
John> a developer attempts to load both CYGPKG_NET and
John> CYGPKG_NET_LWIP into a single eCos configuration, libCDL
John> reports errors due to duplicate cdl_interface declarations.
John> Of course it's unlikely to be sensible to load both these
John> packages, but that's not the point - the naming clash should
John> be fixed.
I don't agree. The same issue arises if e.g. you try to load a second
architectural HAL package into an existing configuration, as part of a
misguided attempt at changing the target, because both HALs will
define options like CYGBLD_LINKER_SCRIPT. There may well be other
scenarios, now or in the future, where we can have mutually exclusive
packages. For example there could be one package implementing a
portable C version of a library, and another package implementing the
same library routines but for one specific architecture with lots of
assembler.
The real issue is how well the tools, both ecosconfig and the
configtool, cope with the situation. Are the error messages
sufficiently clear that a typical user can figure out what is going
on, and why the requested operation is impossible? If not, the
host-side should be fixed - although the problem does not occur often
so I don't see it as a high priority.
Bart
--
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.