This is the mail archive of the ecos-patches@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]

Re: Object File Loader


Andrew:

> Would this be better if it was an interface. I expect the architecture
> files will end up in the individial HALs, and it then implements the
> interface. You can then also remove the define_proc since the HAL
> would provide a <cyg/hal/relocate.h>

I too expected the architecture files to end up in the the HAL, but further
e-conversations with Nick and Bart convinced me that a self-enclosed
package is perhaps a cleaner solution. I am saying "perhaps" because
there are pros/cons for both solution. I am not sure you would gain much
by moving it into the HAL.

> Should these have cyg_ldr_ prefixes to avoid name space problems?

Yes, they do have cyg_ldr_. I added cyg_ldr after writing the documentation,
and forgot to update it.

> How about putting a variation of this into the main src directory. 
> Have CDL control each group of symbols:

This was the original idea. In a posting on ecos-discuss of a couple of
months ago, we talked about a way to use CDL to selectively include
these functions.

We can put them on CDL as long as we _also_ give the user an
opportunity to place his/her own. During development and use of this
package I realized that I call a surprisingly small number of eCos
functions (about 20 to 30) and in this case I find it better to just 
add them manually just like I show in the test case. Of course my 
usage patterns are my own, and for other people it would just be 
easier to add the entire "kapi.h" via a CDL setting.

Let's reach a consensus and I will go back to the drawing board...

Tony


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