strauman at slac.stanford.edu
Mon Dec 3 17:22:24 UTC 2007
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?
Till Straumann wrote:
> Joel Sherrill wrote:
>> Thomas Doerfler (nt) wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> Till Straumann schrieb:
>>>> So what do you suggest - two separate headers, one
>>>> for the public interface, a second one for BSP-internal
>>> 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...
>>> 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.
>>> - --
>>> - --------------------------------------------
>>> IMD Ingenieurbuero fuer Microcomputertechnik
>>> Thomas Doerfler Herbststrasse 8
>>> D-82178 Puchheim Germany
>>> email: Thomas.Doerfler at imd-systems.de
>>> PGP public key available at:
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.2.5 (MingW32)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>> -----END PGP SIGNATURE-----
>>> rtems-users mailing list
>>> rtems-users at rtems.com
> rtems-users mailing list
> rtems-users at rtems.com
More information about the users