PR649, was Re: PR469 IDE problem, was: Re: Any New 4.6.4 Issues

[Karel Gardas]

Thomas and Chris,

On Tue, 20 Sep 2005, Thomas Doerfler (nt) wrote:

>> If that means while configuring RTEMS proper, that is the wrong place to do
>> it.
>> Joel has stated multiple times that the eventual goal is to provide RTEMS
>> binaries that can be linked to applications, and it makes no sense at all to
>> have multiple binaries that differ only in which ATA devices are expected to
>> be present.
>> The configuration should either be when the application is built, or at run
>> time based on initialization parameters passed to the ATA driver.
>
> Hm, so let me remind you, what is handled with this configuration: With
> these configuration items you will specify, which IDE controller(s) are
> present and used in the hardware you are using. Surely you can have very
> similar PCs which differ only in the way the IDE channels are
> equipped/used. But if you look at two PCs which differ in the harddisk
> configuration, you may also find that they have different network
> interface cards etc, in which case you will have to use (slightly)
> different BSPs again.

Last month, I've changed pc386 timer support from using #ifdefs and 
compile time selection of timer source to using automatic detection of the 
source at run-time. Perhaps the same is doable also for IDE driver with 
just the difference that application code will supply appropriate 
configure parameters for IDE. i.e. something like linux support for its 
command-line argument: ideX=noprobe.
This way, whole configuration will be moved from BSP compile time to 
application compile time, at least preserving the same BSP for the 
different hardware.

Also I think that having an option for automatic NIC configuration will be 
nice to have feature -- at least for PCI-based NICs. It will just need to 
force PCI-based drivers to be linked in and then used based on the found 
NIC when network is initialized -- like all the other Unix-like free OSes 
seem to do.

Cheers,
Karel
--
Karel Gardas                  kgardas at objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com