public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
* CDL interfaces for eCos networking
@ 2009-05-12 15:48 John Dallaway
  2009-05-12 17:00 ` Bart Veer
  0 siblings, 1 reply; 3+ messages in thread
From: John Dallaway @ 2009-05-12 15:48 UTC (permalink / raw)
  To: eCos development list; +Cc: Simon Kallweit, John Eigelaar

I've noticed that the common networking infrastructure package
(CYGPKG_NET) declares the same CDL interfaces as the lwIP package
(CYGPKG_NET_LWIP):

  cdl_interface CYGPKG_NET_STACK
  cdl_interface CYGPKG_NET_STACK_INET
  cdl_interface CYGPKG_NET_STACK_INET6

Presumably these interface declarations were placed in CYGPKG_NET at a
time when it was assumed that _all_ networking stack implementations
would use that package.

Now we have the lwIP stack which does not use CYGPKG_NET. If a developer
attempts to load both CYGPKG_NET and CYGPKG_NET_LWIP into a single eCos
configuration, libCDL reports errors due to duplicate cdl_interface
declarations. Of course it's unlikely to be sensible to load both these
packages, but that's not the point - the naming clash should be fixed.

Are these cdl_interfaces intended to indicate the availability of _any_
networking stack or specifically one that provides a BSD sockets API?
At present, the only packages that "require" these interfaces are HTTPD
and Microwindows. I expect that both these packages require BSD sockets.
In that case, I propose that we eliminate the CDL interface declarations
from the lwIP stack. Any future packages which depend on one of the
lwIP-specific stack APIs can simply "require CYGPKG_NET_LWIP".

Comments?

John Dallaway

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CDL interfaces for eCos networking
  2009-05-12 15:48 CDL interfaces for eCos networking John Dallaway
@ 2009-05-12 17:00 ` Bart Veer
  2009-05-14 12:19   ` John Dallaway
  0 siblings, 1 reply; 3+ messages in thread
From: Bart Veer @ 2009-05-12 17:00 UTC (permalink / raw)
  To: John Dallaway; +Cc: ecos-devel, simon.kallweit, john

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CDL interfaces for eCos networking
  2009-05-12 17:00 ` Bart Veer
@ 2009-05-14 12:19   ` John Dallaway
  0 siblings, 0 replies; 3+ messages in thread
From: John Dallaway @ 2009-05-14 12:19 UTC (permalink / raw)
  To: Bart Veer; +Cc: ecos-devel, simon.kallweit, john

Hi Bart

Bart Veer wrote:

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

Duplicate definitions across multiple _hardware_ packages is not usually
an issue since hardware packages are generally loaded/unloaded in a
single transaction when the target is changed. Duplicate definitions
across multiple non-hardware packages is much more of a problem.

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

Yes. Isn't that why we have CDL interfaces?

For the benefit of readers who may be less familiar with CDL scripting,
CDL interfaces allow the developer to express the fact that multiple
eCos packages or components can provide equivalent (possibly mutually
exclusive) blocks of functionality. The developer can choose the most
appropriate implementation(s) and CDL constraints can be used to
stipulate that only one implementation should be active if necessary.

In the specific case of the C library, there are several CDL interfaces
defined in the ISO infrastructure package which express the fact that
other packages (such as the POSIX compatibility package) might provide
alternative implementations or declarations for specific blocks of
functionality. By using different names for the CDL items in the
alternative packages it is possible to load both packages within a
single eCos configuration and harness the power of the inference engine
to report and resolve the conflicts in a user-friendly manner.
Declaration of these CDL interfaces in a separate package (ISO
infrastructure) rather than in one of the packages providing the
implementations of those interfaces is critical.

Unfortunately, CYGPKG_NET and CYGPKG_NET_LWIP both declare the same CDL
interfaces so they cannot both be loaded in an eCos configuration and
the inference engine has no opportunity to report or resolve the issue.

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

The host side tools report all the information that is passed into the
CDL diagnostic handler. For example:

> [jld@cog tmp]$ ecosconfig new pc net
> U CYGBLD_ISO_STRUCTTIMEVAL_HEADER, new inferred value <cyg/posix/sys/time.h>
> U CYGBLD_ISO_FNMATCH_HEADER, new inferred value <cyg/fileio/fnmatch.h>
> [jld@cog tmp]$ ecosconfig add lwip
> /opt/ecos/ecos-3.0/packages/net/lwip_tcpip/v3_0/cdl/lwip_net.cdl, package CYGPKG_NET_LWIP: error
>     Interface `CYGPKG_NET_STACK' cannot be loaded.
>     The name is already in use.
> /opt/ecos/ecos-3.0/packages/net/lwip_tcpip/v3_0/cdl/lwip_net.cdl, package CYGPKG_NET_LWIP: error
>     Interface `CYGPKG_NET_STACK_INET' cannot be loaded.
>     The name is already in use.
> /opt/ecos/ecos-3.0/packages/net/lwip_tcpip/v3_0/cdl/lwip_net.cdl, package CYGPKG_NET_LWIP: error
>     Interface `CYGPKG_NET_STACK_INET6' cannot be loaded.
>     The name is already in use.
> Package CYGPKG_NET_LWIP, 3 errors occurred while reading in the CDL data.
> [jld@cog tmp]$ 

There is no information concerning the already-loaded package with which
these names clash. We could enhance libCDL to provide more information
but this would still be no match for the expressive power and usability
of CDL interfaces. Making all CDL item names unique (at least across the
non-hardware packages) allows us to harness the power of CDL scripting
and the inference engine to express, report and resolve all manner of
interdependencies and usage restrictions. Relying on script parsing
errors to enforce mutual exclusion seems like a very poor substitute.

In the specific case of the lwIP package, I suspect that the package
does not provide the functionality intended by the original author of
these CDL interfaces anyway. Removing the interface declarations from
the package and using some other constraint to express the fact that
lwIP should not be used with the FreeBSD/OpenBSD stacks therefore makes
sense. But this is really a separate issue.

John Dallaway

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-05-14 12:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-12 15:48 CDL interfaces for eCos networking John Dallaway
2009-05-12 17:00 ` Bart Veer
2009-05-14 12:19   ` John Dallaway

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