* 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