bsp.am

One more thing:
If we have these private-interface headers then
it would be nice if they could be prevented from
being installed during the final install so that they
are really invisible to applications.
Is there already a way for me to say in a Makefile.am
that a header should go into the 'preinstall' area
but not the final 'install' area? Any other solution?
T.
Till Straumann wrote:
> Joel Sherrill wrote:
>>> Thomas Doerfler (nt) wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>>>> Till,
>>>>>> Till Straumann schrieb:
>>>>>>>>>> So what do you suggest - two separate headers, one
>>>> for the public interface, a second one for BSP-internal
>>>> interfaces?
>>>>>>>>>>> I think this would be better than writing internals and externals into
>>> one header, making it visible but not available to the user.
>>>> Agreed. Should we come up with a naming convention?
> IIRC, old Xt toolkit used to have xxx.h and xxxP.h...
>> T.
>>>> Having two headers e.g. is implemented for termios: sys/termios.h for
>>> the interface, rtems/termiostypes.h for the internal types.
>>>>>>>>>>> I am in the process of trying to simplify the initialization
>> process from the BSP's perspective and currently in
>> the middle of removing the CPU Table and merging it
>> as appropriate into the main Configuration Table. As part
>> of this, I have looked at a fair number of bsp.h files in
>> the past week or so. I must say that I agree with the
>> internal .h file.
>> It looks like there is a lot of private information in them
>> that is not part of the public API of the BSP.
>>>>>>>>>>>> The technique of hiding internal interfaces by such a symbol
>>>> is already employed widely by the RTEMS kernel and
>>>> by the networking code.
>>>>>>>>>>> Yes, but things could be made better?
>>>>>>>> The networking code is BSD so that's that. We take
>> what we get.
>>>> The POSIX API is much better at hiding its internals than
>> the Classic API. The Classic API has the "inside the
>> kernel part" to keep users from seeing the inline files.
>> It would take a lot of work but I would love to see a
>> split between the public Classic API functionality and
>> the internals. But it would be a large undertaking with
>> little payback.
>>>> --joel
>>>>> wkr,
>>> Thomas.
>>>>>> - --
>>> - --------------------------------------------
>>> IMD Ingenieurbuero fuer Microcomputertechnik
>>> Thomas Doerfler Herbststrasse 8
>>> D-82178 Puchheim Germany
>>> email: Thomas.Doerfler at imd-systems.de>>> PGP public key available at:
>>>http://www.imd-systems.de/pgpkey_en.html>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.2.5 (MingW32)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org>>>>>> iD8DBQFHU6tjwHyg4bDtfjQRAmysAKCJkYfCClAdN29XTb1sMd7ve9iZmwCcCBE6
>>> iG1Kvd99QK6md+O22WKDTgM=
>>> =p1KX
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> rtems-users mailing list
>>>rtems-users at rtems.com>>>http://rtems.rtems.org/mailman/listinfo/rtems-users>>>>>>>>> _______________________________________________
> rtems-users mailing list
>rtems-users at rtems.com>http://rtems.rtems.org/mailman/listinfo/rtems-users>