This is the mail archive of the ecos-bugs@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 17605] New: eCos multi-target repository default config issue


http://bugs.ecos.sourceware.org/show_bug.cgi?id=17605

           Summary: eCos multi-target repository default config issue
           Product: eCos
           Version: 1.1pre
          Platform: All
        OS/Version: HostOS: Win NT/2k/XP
            Status: ASSIGNED
          Severity: normal
          Priority: low
         Component: Other
        AssignedTo: bartv at ecoscentric dot com
        ReportedBy: support at ecoscentric dot com


When a release repository is created for
multiple targets using pkgrelease, target-specific
packages such as CYGPKG_DEVICES_SERIAL_RS232_TX39
and CYGPKG_DEVICES_SERIAL_RS232_MN10300 are
all enabled by default. The default config
does not therefore follow all the CDL rules.

Fix:
Disable all target-specific packages
by default?

Originator:
John Dallaway

Organization:
Cygnus Solutions

Audit-Trail:
Responsible-Changed-From-To: dsm->bartv 
Responsible-Changed-By: dsm 
Responsible-Changed-When: Wed Sep 30 10:03:27 PDT 1998 
Responsible-Changed-Why:  
Oh no, help us Bart, what do we do? 


From: "John Dallaway" <jld at cygnus dot co dot uk>
To: <bugs at cygnus dot com>
Cc: "David Moore" <dsm at cygnus dot co dot uk>, "Bart Veer" <bartv at cygnus dot co dot uk>
Subject: Re: ecc/17605: eCos multi-target repository default config issue
Date: Thu, 15 Oct 1998 23:50:58 +0100

 I have commented out the offending CDL requires rules to workaround this
 problem for eCos 1.1. Note that serial device drivers for all platforms
 will therefore get built by default and we must rely on preprocessor
 directives in the source code to ensure that drivers which are
 inappropriate for the selected HAL build to nothing.
 
 John Dallaway

State-Changed-From-To: open-analyzed
State-Changed-By: bartv
State-Changed-When: Sat Oct 17 12:55:06 1998
State-Changed-Why:
The basic problems in this PR cannot be resolved with the
functionality provided by libnotcdl.a and the current configuration
tool. The only long-term solution will require the implementation of
significant parts of the full CDL language, and there are also
dependencies on the ecchardy tool.

Certain types of packages, especially device drivers, should only
be in the configuration if the target hardware provides the necessary
support. In the case of the mn10300 and tx39 serial device drivers the
I/O hardware is part of the processor itself, so including the device
driver packages in the configuration only makes sense if the hardware
involves the appropriate processor. In the case of more generic device
drivers, e.g. for a 16550 serial chip, the device driver should only
be included if the target board has such a chip.

The dependencies between the hardware and the device driver cannot be
expressed using simple "requires" properties between options. It would
be incorrect for e.g. the mn10300 HAL package to require the mn10300
serial device driver, since this would prevent the user from disabling
the driver if the application does not need. Having the device driver
require the HAL package is slightly better but is still incorrect: it
is just about ok for on-chip devices, i.e. you cannot have the mn10300
serial driver unless you have an mn10300 processor (probably); it is
inappropriate for off-chip devices; theoretically you could have the
16550 driver require "board a" | "board b" | "board c", but that
solution is totally unscalable. And of course there is no support at
present for OR logic in requires properties.

A better approach involves CDL interfaces. The 16550 device driver
could require the interface CYGHWR_SERIAL_RS232_16550, and this
interface could then be "implemented" by the appropriate architectural
or platform HAL packages. This provides a more scalable solution.
There is still a problem of default values: a device driver should be
enabled by default if the platform has a suitable chip, otherwise it
should be disabled by default. This involves CDL such as:

  cdl_package CYGPKG_SERIAL_RS232_16550 {
      ...
      default_value CYGHWR_SERIAL_RS232_16550
      requires      CYGHWR_SERIAL_RS232_16550
      ...
  }

Now everything just works. However this involves two facilities not
provided by the current configuration system: interfaces; and
default_values that are expressions involving other entities in the
configuration system. It would be possible to work around the lack of
interfaces in the short time, but it is still necessary to change the
way default values are handled and this cannot be done for the
next release.

A variation of the above would use the active_if property:

  cdl_package CYGPKG_SERIAL_RS232_16550 {
      ...
      default_value 1
      active_if     CYGHWR_SERIAL_RS232_16550
      ...
  }

This variation would involve a different and possibly preferable
representation in the GUI tool, but the overall effect is the same.
This approach requires the implementation of the "active_if" property,
and preferably of interfaces as well. Again this cannot be achieved
for the next release.


In practice the nature of device drivers is such that things will be
more complicated than this. In particular a given board may have
multiple 16550's on it, and conceivably the user will want to use
differently configured device drivers for the different devices. It is
also possible that a device will be in use by e.g. cygmon and we
cannot just install a device driver for it. Now we are straying into
ecchardy territory, and there are plenty of issues that need to be
resolved.

There is also a general scalability issue relating to how packages
should become part of the configuration. Currently every package in
the system appears in the configuration tool's main tree view. As we
start getting more and more packages, including third party and
contributed ones, this will not be a sensible solution: there would be
so many ununused packages in the tree that users would have difficulty
finding the options they actually want to manipulate. Package
selection and option manipulation will have to be separated in some
fashion to be determined.


Given that none of the correct solutions can be implemented for the
next release, what is possible? There are a number of temporary
hacks, all ugly.

1) we can remove the "requires" statements from the device driver
   packages. This means that the configuration tool will not
   complain about dependency problems. It also means that all
   device driver packages will get compiled for all platforms,
   even if the device driver is totally inappropriate for that
   platform. This can be made to work if the device driver source
   code checks for a suitable HAL package in a #ifdef, and compiles
   to an empty file if the driver should not have been built. It
   appears that the current sources already do this.

   Problems with this approach include:

   a) all device drivers get compiled for all platforms. This is
      inefficient, and may lead to user complaints.

   b) people using pkgconf.tcl in command line mode will get
      slightly different build trees than people using the
      configuration tool. The targets and packages file contain
      a bit more information than can be expressed in the
      current notcdl syntax, allowing pkgconf to do the right thing.

   c) it will only work for the existing mn10300 and tx39 serial
      device drivers. The scheme breaks down as soon as we have a
      driver that can be used on more than one board. A temporary
      work-around would involve #if defined(board_a) || defined(board_b),
      but again that is not scalable.

2) we could change the parent of the device drivers, so that e.g. the
   parent of CYGPKG_DEVICES_SERIAL_RS232_TX39 is CYGPKG_HAL_TX39.
   If the tx39 HAL package is not enabled than everything below it
   should be inactive, including the serial driver. This would have
   the advantage that inappropriate device drivers would no longer
   end up in the build tree. Problems with this approach include:

   a) the device drivers would no longer be in the device driver
      section of the tree, which would be confusing.

   b) again this does not work for more general device drivers, e.g.
      a 16550 driver that could be used on multiple boards.

   c) this particular organization has not been tried before, and
      there is a possibility that some code in the configuration
      tool would break.

3) pkgconf could be changed so that it silently ignores attempts to
   enable device driver packages that are inappropriate for the target
   hardware. This has the big disadvantage that the configuration tool
   would effectively be lying to the user about which packages are in
   the configuration. However it would solve the problem of the 16550
   device driver.

4) we could add some mechanism by which packages could be disabled
   by default. One option is a default_value property that only
   gets used for packages. Another option is to have a suitable
   #define or #undef for the package in the configuration header
   file, but that reintroduces the clash with <pkgconf/system.h>
   The big problem with this approach is that users would be
   forced to enable the device drivers manually, i.e. they have to do
   more work to get a minimally usable system.

5) we could add more interaction between the configuration tool and
   pkgconf so that the configuration tool has the same level of
   understanding of the relationships between targets and hardware
   packages. This would require a very significant amount of work,
   especially to handle the case where the user changes the target
   architecture or platform. It might be necessary to completely redo
   the way the configuration tool handles the selection of the
   target architecture and platform.

6) we could try adding some additional bits of the CDL language to the
   current configuration system, e.g. the active_if property, in an
   ad-hoc fashion.


In the short term I recommend option (1). This gets us past the
current release but leaves a gaping big hole in the area of generic
device drivers. After this release we have to decide whether we should
implement one of (3) to (6) as a further stop-gap measure, or whether
we should concentrate on a proper long-term solution.

Unformatted:
>From jld  Thu Oct 15 23:51:55 1998
Return-Path: <jld at cygnus dot co dot uk>
From: "John Dallaway" <jld at cygnus dot co dot uk>
To: <bugs at cygnus dot com>
Cc: "David Moore" <dsm at cygnus dot co dot uk>, "Bart Veer" <bartv at cygnus dot co dot uk>
Subject: Re: ecc/17605: eCos multi-target repository default config issue
Date: Thu, 15 Oct 1998 23:50:58 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal

I have commented out the offending CDL requires rules to workaround this
problem for eCos 1.1. Note that serial device drivers for all platforms
will therefore get built by default and we must rely on preprocessor
directives in the source code to ensure that drivers which are
inappropriate for the selected HAL build to nothing.

John Dallaway

Mon Oct 19 03:28:52 PDT 1998
As John has checked applied Bart's suggested solution 1.  I have
changed the priority to low



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]