This is the mail archive of the ecos-discuss@sourceware.org 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: Type of alarm-function


> > I propose the following "fix"
> >
> >
> > >  typedef cyg_addrword_t* cyg_handle_t;
> > >
> >
> > define cyg_handle_t as pointer to cyg_addrword_t. That way
> > cyg_handle_t would always be a real pointer and that is how it is
> > used. cyg_handle_t should only be used for pointers to kernel objects
> > (i.e. threads, mutexes, ...) , right?
> >
> > We (Thomas to be more precise) checked this change by running the
> > kernel test cases and did not encounter any problems.
> >
>
>  Actually, no.  cyg_handle_t is meant to be an opaque "kernel
>  handle" which _could_ be a pointer, but also could just as
>  well be an index into an appropriate table, etc.  I think
>  it's best left as is.

Another possibility would be to change the implementation of the
kernel callbacks. This change however would not be compatible to the
current C++ API of the kernel. The C++ API, however, is not officially
supported, as far as I know, is it?. This would induce an additional
cast in the callback but the C API can remain untouched. Changing the
cyg_handle_t should also not affect the C API.

Ciao, Fabian

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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