bsp.am

[Till Straumann]

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
>