Per-BSP confdefs (or resource allocation)

[Sebastian Huber]

On 24/10/15 02:12, Chris Johns wrote:
> On 22/10/2015 6:16 pm, Sebastian Huber wrote:
>> On 22/10/15 09:00, Chris Johns wrote:
>>> In the mean time could linker sets be used in drivers or BSPs to declare
>>> a table of "resources" they need and these are added to the confdefs.h
>>> defined values during initialisation?
>> Yes, this would probably work. You should however compare the complexity of
>>
>> 1) linker sets
>>      + dynamic workspace size changes
>>      + static pre-processor based workspace size estimate (just look at
>> the pre-processed output of confdefs.h)
>>      + workspace (heap)
>>      + objects
>>      + side-effects, e.g. subsystem which doesn't account for its resources
>>      + initialization order
>>      + run-time initialization errors
>>
>> vs.
>>
>> 2) provide some storage (16 bytes for a mutex on a 32-bit target)
>>      + initialize the object (= initialize storage to zero, no possible
>> errors, may reside in .bss)
>>
> There is no argument from me about the API being simpler and faster as
> the libbsd work has shown but I am concerned about linking this specific
> issue being discussed to a long term solution that is not even fully
> agreed to. If this API does get implemented we will always want to have
> both APIs and I am not sure we will want to migrate all BSPs so does
> this mean we need another solution.

I don't work actively to move the libbsd APIs to RTEMS. I am very busy 
with the new network stack for T4240 support until end of the year.

One additional issue is that on SMP a mutex type synchronization is not 
enough due to performance reasons. You have rmlock, rwlock and sx on 
FreeBSD as well:

https://www.freebsd.org/cgi/man.cgi?query=locking&sektion=9&apropos=0&manpath=FreeBSD+10.2-RELEASE

So in the next couple of months we have to think about this too.

>
> Do we leave this issue alone until your proposed API is available or do
> we look for a solution with the current API we can implement now and
> bridge that gap?
>
> Chris

A quick hack is the unlimited objects option as Joel suggested. For the 
linker sets I have to write documentation. I work only from time to time 
on this.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.