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.hu...@embedded-brains.de
PGP     : Public key available on request.

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

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to