RTEMS-CVS is broken

Joel Sherrill joel.sherrill at oarcorp.com
Thu Jul 13 17:42:13 UTC 2006

Thomas Doerfler wrote:

>Hash: SHA1
>Joel, Ralf,
>Joel Sherrill schrieb:
>>RTEMS CPUKit can define the standard public interface to a device driver.
>>The top 1/2 of ata.h looks to be the generic driver interface similar to
>>*drv.h files in libcsupport.  The bottom looks implementation specific
>>to me.
>Moving a part of the ATA interface declarations into cpukit would not
>solve the problems I wanted to solve.
>Some of out customers are using the FAT filesystem inside RTEMS, with am
>IDE interface. And I really hated to tell them over and over again that
>they have to build their own custom device driver table for non-standard
>devices (why is an ATA device "non-standard" in RTEMS?) and to configure
>libblock (which is part of cpukit) through some handcoded configuration
>tables and still they would have to live with hardcoded helper task
>priorities in libblock and the ATA driver.
>So from a "user's" point of view, I think my modifications to confdefs.h
>etc. are quite fine. The ATA and IDE drivers are configured consistently
>with the other drivers, libblock can be configured in a similar way AND
>the helper tasks can be configured in their priority.
>Ralf, I agree that I have broken the code separation between cpukit and
>the BSP specific stuff, and this is not a good solution.
>My proposal for a better solution would be:
>1. to keep the configuration options for libblock in confdefs.h, because
>libblock is part of the cpukit
>2. to remove the stuff for IDE and ATA drivers from confdefs.h
>3. to introduce a mechanism to add "user selected" drivers to the device
>driver configuration table built in confdefs.h. I have something in mind
>/* in system.h */
>which would be appended to the device driver table in confdefs.h.
>What I am missing now would be a proper position to replace the following:
>#  endif
>  rtems_task_priority ata_driver_task_priority
>#  endif /* CONFIGURE_INIT */
>It allows the user to configure the priority of the ata helper task,
>with a default value defined. Would it be a good idea to have this in a
>separate "confdefs_ata.h"?
>Maybe it would even make sense o introduce a board/BSP specific
>configuration headre which in turn pulls in all relevant configuration
>headers form libbsp/shared, libchip and possibly cpukit, something like:
>+-- libchip/conf_ata.h
>+-- shared/conf_network_xxx.h
>+-- confdefs.h
>Any comments on this?

At first thought, this seems reasonable.    confdefs.h can stick to the 
basics in CPU Kit.

Offhand, I don't see how the sequence of includes would end up adding 
extra entries to
the generic driver table in confdes.h. but I can see how confboard.h 
could disable the generation of
the table in confdefs.h and then add its own "more aware" version.

Since we have bsp.h, I would be prone to call it confbsp.h or 
confdefs_bsp.h, but that is
just an off the cuff name.  I would just like something consistent with 
existing patterns.

>- --
>- --------------------------------------------
>Embedded Brains GmbH
>Thomas Doerfler        Obere Lagerstrasse 30
>D-82178 Puchheim       Germany
>email: Thomas.Doerfler at embedded-brains.de
>Phone: +49-89-18908079-2
>Fax:   +49-89-18908079-9
>Version: GnuPG v1.4.3 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

More information about the users mailing list