Re: Prototype implementation for self-contained objects
- Gedare Bloom schrieb:
> On Thu, Jul 23, 2015 at 8:54 AM, Sebastian Huber
> wrote:
> > https://lists.rtems.org/pipermail/devel/2015-July/011989.html
> >
> > Its fully functional and well tested. It is based on the FreeBSD support:
> >
> > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/rtems-bsd-muteximpl.h
> > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-muteximpl.c
> >
> > It is used to implement the Newlib internal locks and the libgomp (GCC
> > OpenMP
> > support) operating system services.
> >
> > There is one issue I am not that happy about. There are two thread queue
> > definitions:
> >
> > 1. in Newlib
> >
> > struct _Thread_queue_Queue {
> > struct _Thread_queue_Heads *_heads;
> > struct _Ticket_lock_Control _Lock;
> > };
> >
> > 2. in
> >
> > typedef struct {
> > Thread_queue_Heads *heads;
> >
> > /**
> >* @brief Lock to protect this thread queue.
> >*
> >* It may be used to protect additional state of the object embedding this
> >* thread queue.
> >*
> >* @see _Thread_queue_Acquire(), _Thread_queue_Acquire_critical() and
> >* _Thread_queue_Release().
> >*/
> > #if defined(RTEMS_SMP)
> > SMP_ticket_lock_Control Lock;
> > #endif
> > } Thread_queue_Queue;
> >
> The only cost to remove the conditional is an extra 8 bytes per
> Thread_queue? My intuition here is that non-SMP targets create few
> enough of these queues that the overhead is not so bad. However,
> analysis of the number of queues made in a base system would be good.
You have one Thread_queue_Queue per object which allows a thread to block. If
we use an MCS lock instead of the ticket lock, then the overhead is only 4
bytes.
>
> > In RTEMS the lock is optional. In Newlib the storage must be always present
> > for the lock to be independent of the actual RTEMS build configuration. I
> > ensure with static assertions that the layout of these two structures is
> > compatible (see top of cpukit/score/src/mutex.c). For the Newlib
> > definition it
> > would be sufficient to provide a structure with arbitrary content. Only the
> > alignment and size must fit (see glibc header files for objects shared by
> > user/kernel space). For debugging purposes it is quite handy to have an
> > identical layout. I use a cast to get the score definition, e.g.
> >
> > static Thread_queue_Queue *_Futex_Get_thread_queue(
> > struct _Futex_Control *futex
> > )
> > {
> > return (Thread_queue_Queue *) &futex->_Queue;
> > }
> >
> > This may, however, lead to strict aliasing problems. I am not sure how to
> > solve this technically best.
> Probably you can make futex._Queue a union of Thread_queue_Queue and
> _Thread_queue_Queue.
The Thread_queue_Queue is not visible in Newlib. One option would be something
like this
typedef union {
struct _Thread_queue_Queue Newlib_queue;
Thread_queue_Score_queue Score_queue;
} Thread_queue_Queue;
I think one way to avoid the strict aliasing problems is to define a seconds
set of the structures defined by Newlib in the score and simply
cast to the score structure on function entry and never use the Newlib type.
--
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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 3/8] score: Add potpourri lock statistics
- Gedare Bloom schrieb: > All of the external lock objects will re-use the same lock statistics > struct? Is there any reason to separate the stats more? At least in > terms of the locks provided in RTEMS, you could create an array of the > Potpourri_stats and assign the known usages into the array, with a > catch-all at offset zero for the unknown usages. I don't know if this > makes sense or not, but in terms of understanding the lock stats this > might be a good thing for profiling purposes rather than aggregrating > all stats into the same struct? You have one set of stats per thread for all the external thread queues. A global stats object is not that good due to the resulting cache traffic and you would need a lock itself to protect these stats. You have to take nested locks into account as well. I wouldn't change the existing SMP lock stats profiling in RTEMS, since this is very valuable to figure out the hot spots in the system and optimize efficiently. -- 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 5/8] score: Add self-contained mutex implementation
- Gedare Bloom schrieb: > What, if any, guidance do we need to give to users about these new > implementations? We should mention that they are used for the Newlib internal locks. I would make the available to the users via the C11 thread library: http://en.cppreference.com/w/c/thread Here is a reference implementation which we may use and adjust: https://github.com/freebsd/freebsd/tree/master/lib/libstdthreads Enabling the Newlib internal locks will put some pressure on us to provide better support for nested locks with priority inheritance. -- 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[rpi bsp] configure fb section in mmu table and improvement for mailbox
Hi Pavel Pisa, I've added the auto-configuration for fb section in mmu table. I reserve a section at the end of mmu table, make the table non-const to avoid errors, allocate fb before mmu initialization and fill in the table with the right parameters. As far as I've tested, I've found that the zero-length array did not behave like I expected. So I decided to go back to my first choice at the begining. What doesn't change is that we offer a structure of entries and a function for every operation/interface of videocore and hide the detail of tag structures. I think it's much closer to what we expected. you may checkout my github and my dropbox. https://github.com/yangqiao/rtems/tree/framebuffer https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0 The commits log is messy, I'll rebase it afterward until we think it's acceptable. Looking forward to your comments. Best wishes. YANG Qiao___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB] port graphic libraries into rsb
Hi Pavel Pisa,
I've fixed the leak. Please checkout my github.
https://github.com/yangqiao/rtems-source-builder/tree/graphics
Best wishes
On Jul 21, 2015, at 09:51 PM, Pavel Pisa wrote:
Hello Qiao Yang
On Tuesday 21 of July 2015 14:21:07 QIAO YANG wrote:
Hi Pavel Pisa,
On Jul 19, 2015, at 10:35 PM, Pavel Pisa wrote:
> Hello Chris and Qiao Yang,
>
> On Monday 20 of July 2015 01:12:33 Chris Johns wrote:
>> On 20/07/2015 6:55 am, QIAO YANG wrote:
>> > I've ported the graphic libraries into rsb so that we can build them
>> > much easier. All Build passed, tested on arm with raspberrypi and i386
>> > with pc386.
>>
>> Fantastic and thank you.
>
> I use system wide prefix for my RTEMS install. When I specified that
>
> --prefix=/opt/rtems4.11
>
> When I specified that to sb-set-builder then it silently skips install
> steps. This leads not only to problem that I have not received resulting
> binaries (even not found them in temporary RSB trees) but even build of
> later packages dependant on previous ones failed.
>
> I resolved that by use of RSB option
>
> --pkg-tar-files
>
> tar files has been generated and I could extract content to the right
> directory and continue build with followup with sucesfull Microwindows
> package build. I have been able to use that (after tar extraction)
> to build and run my graphic application in QEMU then.
So the library works if I've got it right. No problem with the build
process.
The libraries are configured properly. Only thing to solve for you
is to find way how to limit all/as most as possible files installed
in improper directories. It is not fatal but can make troubles
and is misleading. Look for packages options --disable-test, samples
and some related options to direct install of support files to BSP
specific directories. Documentation can go to RTEMS prefix and shared
area. But includes, libraries, binaries and configs should not.
The other issues are for discussion with Chris Johns
and he woks on these. So rebase of your work onto
his newer RSB versions should help.
I have some more things for Microwindows. It seems that
Microwindows mainline (https://github.com/ghaerr/microwindows)
moves forward (commits by georgp24).
You are using alex-sever-h fork. I do not expect that he returns
to the project. We should consolidate code. I have his changes
in my fork. Some of these are not appropriate for mainline
some needs cheanup. But we should move closer to mainline.
As I find time, I try to prepare branch with changes suitable
for mainline. I would like to change Microwindows RTEMS config
and makefiles such way that NOKBD and NOMOUSE can be selected
for RTEMS by config. Same for some screen variants.
So the patches removing keyboard and mouse in Makefiles would
not be required. All things should be controlled by config.
> Because libraries build is specific than I expect that all build
> results should be installed in BSP directory, i.e.
> /opt/rtems4.11/i386-rtems4.11/pc686/{lib,bin,lib/include} in my case.
> It seems that JPEG library is configured right. But there are significant
> leakages from freetype, libpng, t1lib and libtiff to
> "/opt/rtems4.11/bin" and "/opt/rtems4.11/share" directories.
> t1lib even installs to /share/t1lib directly.
Do you mean that the libraries are not installed in the bsp dir?
Yes and no, libraries required to build RTEMS applications are installed
in the right place but there is significant level of noise - tools,
scripts etc installed in inappropriate places.
Add --pkg-tar-files RSB option and then you can easily see what
is content of each installed package - I hope, that it is 1:1 to what
is really installed/copied to the filesystem.
In fact,
I've got all libraries installed in the right place. Firstly, I doubt if
the bsp pc686 exists in arch i386. I can only find pc386 in mainline. Make
sure that the bsp name is correct. Secondly, verify the path you passed is
what the builder expects as chris explained. I haven't found out why the
JPEG works while others can't, but I do use the paths to determin where to
install.
RTEMS supports boards variants. This means that there are more boards
supported than only these seen as individual subdirectory of each
CPU architecture (these subdirectories are more or less equivalent to
machine or platform on Linux). The varinats usually differ in the compiler
flags and some defines which control source builds.
See
rtems/c/src/lib/libbsp/i386/pc386/make/custom
There are varinats
edison.cfg pc386.cfg pc486.cfg pc586.cfg pc586-sse.cfg
pc686.cfg pcp4.cfg
where pc686.cfg includes common pc386.cfg base but selects
pentium generation corresponding optimization
CPU_CFLAGS = -mtune=pentiumpro
and variant name for RTEMS
RTEMS_CPU_MODEL=pentiumpro
I followed alan's blog to setup my environment.
alias i386-kernel-configuer='cd $HOME/development/rtems-386/rtems-git/; \
./bootstrap; \
mkdir $HOME/development/rtems-386/build-rtems-386/; \
cd $HOME/development/rtems-386/build
