From: Bart Veer <bartv@ecoscentric.com>
To: John Dallaway <john@dallaway.org.uk>
Cc: ecos-devel@ecos.sourceware.org, simon.kallweit@intefo.ch, john@kses.net
Subject: Re: CDL interfaces for eCos networking
Date: Tue, 12 May 2009 17:00:00 -0000 [thread overview]
Message-ID: <pnpree9rz4.fsf@delenn.bartv.net> (raw)
In-Reply-To: <4A099A39.1060606@dallaway.org.uk> (message from John Dallaway on Tue, 12 May 2009 16:48:09 +0100)
>>>>> "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.
next prev parent reply other threads:[~2009-05-12 17:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 15:48 John Dallaway
2009-05-12 17:00 ` Bart Veer [this message]
2009-05-14 12:19 ` John Dallaway
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pnpree9rz4.fsf@delenn.bartv.net \
--to=bartv@ecoscentric.com \
--cc=ecos-devel@ecos.sourceware.org \
--cc=john@dallaway.org.uk \
--cc=john@kses.net \
--cc=simon.kallweit@intefo.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).