public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
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.

  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).