Re: Wrap Interrupt Handlers for Recording?
- Am 5. Sep 2019 um 7:25 schrieb Chris Johns chr...@rtems.org: > On 5/9/19 2:25 pm, Sebastian Huber wrote: >> - Am 4. Sep 2019 um 23:41 schrieb Chris Johns chr...@rtems.org: >> >>> On 5/9/19 2:09 am, Sebastian Huber wrote: Hello, I would like to wrap calls to interrupt handlers which use the generic interrupt framework () to get RTEMS_RECORD_INTERRUPT_ENTRY and RTEMS_RECORD_INTERRUPT_EXIT events. This cannot be done by the linker since the loop to call the handlers is inlined due to performance reasons. I would like to add some sort of a callback mechanism which is invoked in rtems_interrupt_handler_install() and rtems_interrupt_handler_remove() operations (similar to the user extensions). There are some options to do this. 1. A new linker set with functions. 2. A new user extension, maybe a generic: void (*event)(rtems_extension_event event, void *arg); 3. An API to install/remove a specific callback for this purpose. >>> >>> 4. Update or add a new API call to return the currently installed >>>handler. This way interrupts can be chained. >> >> This API already exists: >> >> https://docs.rtems.org/doxygen/branches/master/group__rtems__interrupt__extension.html#ga31d23275b676018c06e13c7bedc87983 >> >> The problem with this approach is that it doesn't wrap new handlers and if >> you >> remove a wrapped handler, then a memory leak or worse may happen. > > Yes care needs to be taken with this approach. > >> >>> I am in favour of 1. I also would like to hide it from the user for now. >>> >>> Does 1. allow runtime installing and then tracing of an interrupt? I know 3. >>> would. >> >> Yes, 1., 2., and 3. do the same, the difference is how you install the >> wrapper >> functionality and maybe how many you can install. > > It is difficult because you may want to trace one of a number of interrupt > sources or you may want to trigger tracing of another event due to system > issues. For this complex scenario the proposed approach is not the right tool. To trace individual interrupts, you can wrap the specific interrupt handler and do your complex stuff. > >> >> 5. Use a weak function. >> > > Would this mean the overhead of the weak function happens all the time? I mean weak functions which are called during interrupt handler install/remove. The interrupt dispatching should remain as is with absolutely no overhead if recording is disabled. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] record: Add support for interrupt handlers
On 5/9/19 2:42 pm, Sebastian Huber wrote:
> - Am 5. Sep 2019 um 0:28 schrieb Chris Johns chr...@rtems.org:
>
>> On 4/9/19 9:46 pm, Sebastian Huber wrote:
>>> On 04/09/2019 08:06, Chris Johns wrote:
> +void LTTNGClient::WriteIRQHandlerExit(PerCPUContext* pcpu, const
> ClientItem&
> item) {
> + pcpu->content_size += kEventIRQHandlerExitBits;
> + pcpu->packet_size += kEventIRQHandlerExitBits;
> +
> + EventIRQHandlerExit& ih = pcpu->irq_handler_exit;
> + ih.header.ns = item.ns;
> + ih.irq = static_cast(item.data);
> + fwrite(, sizeof(ih), 1, pcpu->event_stream);
https://en.cppreference.com/w/cpp/io :)
>>>
>>> I had a look a this, it seems the error reporting capabilities of
>>> are
>>> quite bad (nothing like strerror(errno)).
>>
>> Interesting point to make given the return code from `fwrite` is not
>> checked. :)
>
> Yes, but at least the return status of fopen() is checked.
There is `bad()` and you can trigger exceptions. There are usable options and my
link was only a question and not a requirement.
>
>> Also it should be `std::fwrite`.
>
> Ok, it seems was included via . I will fix this.
>
I think we can take C++ development styles offline and chat personally, maybe in
person soon. :)
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: MrsP Testbed
Hello Ricardo, - Am 4. Sep 2019 um 15:52 schrieb Ricardo Gomes (1161078) 1161...@isep.ipp.pt: > Greetings, > > During the last six months, I have been studying RTEMS as part of my final > project to complete my degree, more specifically analysing the MrsP protocol > in > order to perform an evaluation of its implementation on RTEMS. I would be great if you can publish the evaluation once it is finished. Please let me know if you need a reviewer. > In order to accomplish this analysis, I developed a set of samples that allows > one to test several properties of MrsP, based its own rules, as described in > [1], including the use of nested resources, presented in [2]. Beyond that, I > have also adapted those test cases, using OMIP instead of MrsP, in order to > establish comparisons between both protocols. > > So far the set of develop test cases were executed using QEMU, as up to now > I’m > not able to execute SMP code in a Raspberry PI 2 (I will address this topic > with more detail later on another thread). > > I wanted to know if: > > 1- there is any interest from the community for me to submit these tests to > the > RTEMS repository, or at least the ones considered relevant > > 2- In case the answer to 1 is affirmative, If I should create a new ticket and > submit the test cases as individual patches. an independent set of test cases would be good. Currently, the tests and the implementation are from the same person. SMP test code in the test suite must compile and link on all SMP targets. If you plan to submit the code, please plan with enough time for some review/change iterations. > > Thank you for your attention. > > Best Regards, > > Ricardo Gomes > > > P.S. After I complete my final report I can make it available if someone is > interested. Yes, I am definitely interested. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Wrap Interrupt Handlers for Recording?
On 5/9/19 2:25 pm, Sebastian Huber wrote: > - Am 4. Sep 2019 um 23:41 schrieb Chris Johns chr...@rtems.org: > >> On 5/9/19 2:09 am, Sebastian Huber wrote: >>> Hello, >>> >>> I would like to wrap calls to interrupt handlers which use the generic >>> interrupt >>> framework () to get RTEMS_RECORD_INTERRUPT_ENTRY and >>> RTEMS_RECORD_INTERRUPT_EXIT events. This cannot be done by the linker since >>> the >>> loop to call the handlers is inlined due to performance reasons. I would >>> like >>> to add some sort of a callback mechanism which is invoked in >>> rtems_interrupt_handler_install() and rtems_interrupt_handler_remove() >>> operations (similar to the user extensions). There are some options to do >>> this. >>> >>> 1. A new linker set with functions. >>> >>> 2. A new user extension, maybe a generic: >>> >>> void (*event)(rtems_extension_event event, void *arg); >>> >>> 3. An API to install/remove a specific callback for this purpose. >>> >> >> 4. Update or add a new API call to return the currently installed >>handler. This way interrupts can be chained. > > This API already exists: > > https://docs.rtems.org/doxygen/branches/master/group__rtems__interrupt__extension.html#ga31d23275b676018c06e13c7bedc87983 > > The problem with this approach is that it doesn't wrap new handlers and if > you remove a wrapped handler, then a memory leak or worse may happen. Yes care needs to be taken with this approach. > >> >>> I am in favour of 1. I also would like to hide it from the user for now. >> >> Does 1. allow runtime installing and then tracing of an interrupt? I know 3. >> would. > > Yes, 1., 2., and 3. do the same, the difference is how you install the > wrapper functionality and maybe how many you can install. It is difficult because you may want to trace one of a number of interrupt sources or you may want to trigger tracing of another event due to system issues. > > 5. Use a weak function. > Would this mean the overhead of the weak function happens all the time? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] record: Add support for interrupt handlers
- Am 5. Sep 2019 um 0:28 schrieb Chris Johns chr...@rtems.org:
> On 4/9/19 9:46 pm, Sebastian Huber wrote:
>> On 04/09/2019 08:06, Chris Johns wrote:
+void LTTNGClient::WriteIRQHandlerExit(PerCPUContext* pcpu, const
ClientItem&
item) {
+ pcpu->content_size += kEventIRQHandlerExitBits;
+ pcpu->packet_size += kEventIRQHandlerExitBits;
+
+ EventIRQHandlerExit& ih = pcpu->irq_handler_exit;
+ ih.header.ns = item.ns;
+ ih.irq = static_cast(item.data);
+ fwrite(, sizeof(ih), 1, pcpu->event_stream);
>>> https://en.cppreference.com/w/cpp/io :)
>>
>> I had a look a this, it seems the error reporting capabilities of
>> are
>> quite bad (nothing like strerror(errno)).
>
> Interesting point to make given the return code from `fwrite` is not checked.
> :)
Yes, but at least the return status of fopen() is checked.
> Also it should be `std::fwrite`.
Ok, it seems was included via . I will fix this.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Wrap Interrupt Handlers for Recording?
- Am 4. Sep 2019 um 23:41 schrieb Chris Johns chr...@rtems.org: > On 5/9/19 2:09 am, Sebastian Huber wrote: >> Hello, >> >> I would like to wrap calls to interrupt handlers which use the generic >> interrupt >> framework () to get RTEMS_RECORD_INTERRUPT_ENTRY and >> RTEMS_RECORD_INTERRUPT_EXIT events. This cannot be done by the linker since >> the >> loop to call the handlers is inlined due to performance reasons. I would like >> to add some sort of a callback mechanism which is invoked in >> rtems_interrupt_handler_install() and rtems_interrupt_handler_remove() >> operations (similar to the user extensions). There are some options to do >> this. >> >> 1. A new linker set with functions. >> >> 2. A new user extension, maybe a generic: >> >> void (*event)(rtems_extension_event event, void *arg); >> >> 3. An API to install/remove a specific callback for this purpose. >> > > 4. Update or add a new API call to return the currently installed >handler. This way interrupts can be chained. This API already exists: https://docs.rtems.org/doxygen/branches/master/group__rtems__interrupt__extension.html#ga31d23275b676018c06e13c7bedc87983 The problem with this approach is that it doesn't wrap new handlers and if you remove a wrapped handler, then a memory leak or worse may happen. > >> I am in favour of 1. I also would like to hide it from the user for now. > > Does 1. allow runtime installing and then tracing of an interrupt? I know 3. > would. Yes, 1., 2., and 3. do the same, the difference is how you install the wrapper functionality and maybe how many you can install. 5. Use a weak function. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] record: Add support for interrupt handlers
On 4/9/19 9:46 pm, Sebastian Huber wrote:
> On 04/09/2019 08:06, Chris Johns wrote:
>>> +void LTTNGClient::WriteIRQHandlerExit(PerCPUContext* pcpu, const
>>> ClientItem&
>>> item) {
>>> + pcpu->content_size += kEventIRQHandlerExitBits;
>>> + pcpu->packet_size += kEventIRQHandlerExitBits;
>>> +
>>> + EventIRQHandlerExit& ih = pcpu->irq_handler_exit;
>>> + ih.header.ns = item.ns;
>>> + ih.irq = static_cast(item.data);
>>> + fwrite(, sizeof(ih), 1, pcpu->event_stream);
>> https://en.cppreference.com/w/cpp/io :)
>
> I had a look a this, it seems the error reporting capabilities of
> are
> quite bad (nothing like strerror(errno)).
Interesting point to make given the return code from `fwrite` is not checked. :)
Also it should be `std::fwrite`.
I did not know `std::fwrite` was documented in the C++ interface, well it is on
cppreference.com.
Further down in this file `std::cerr` is used to report errors which is great so
this is a mix of C and C++ and why I posted the link. I would like to avoid the
cases that exist in covoar where `fprintf(stderr, ...)` is used to print errors.
I see this as C programming in C++.
> A C++ alternative would be:
>
> https://www.boost.org/doc/libs/1_70_0/libs/filesystem/doc/index.htm
We have discussed boost and my position has not changed.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Wrap Interrupt Handlers for Recording?
On 5/9/19 2:09 am, Sebastian Huber wrote: > Hello, > > I would like to wrap calls to interrupt handlers which use the generic > interrupt framework () to get > RTEMS_RECORD_INTERRUPT_ENTRY and RTEMS_RECORD_INTERRUPT_EXIT events. This > cannot be done by the linker since the loop to call the handlers is inlined > due to performance reasons. I would like to add some sort of a callback > mechanism which is invoked in rtems_interrupt_handler_install() and > rtems_interrupt_handler_remove() operations (similar to the user extensions). > There are some options to do this. > > 1. A new linker set with functions. > > 2. A new user extension, maybe a generic: > > void (*event)(rtems_extension_event event, void *arg); > > 3. An API to install/remove a specific callback for this purpose. > 4. Update or add a new API call to return the currently installed handler. This way interrupts can be chained. > I am in favour of 1. I also would like to hide it from the user for now. Does 1. allow runtime installing and then tracing of an interrupt? I know 3. would. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] barrier: Remove unfinished sentence
Remove the unfinished sentence "Since a barrier is, by definition, never immediately [...]" and jump directly to "The task may wait [forever or for a timeout]" instead. I cannot figure out what the unfinished sentence is supposed to be - "released"? "passed"? --- c-user/barrier_manager.rst | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/c-user/barrier_manager.rst b/c-user/barrier_manager.rst index e5d69b0..9a57645 100644 --- a/c-user/barrier_manager.rst +++ b/c-user/barrier_manager.rst @@ -119,10 +119,9 @@ Waiting at a Barrier The ``rtems_barrier_wait`` directive is used to wait at -the specified barrier. Since a barrier is, by definition, never immediately, -the task may wait forever for the barrier to be released or it may -specify a timeout. Specifying a timeout limits the interval the task will -wait before returning with an error status code. +the specified barrier. The task may wait forever for the barrier to be +released or it may specify a timeout. Specifying a timeout limits the interval +the task will wait before returning with an error status code. If the barrier is configured as automatic and there are already one less then the maximum number of waiters, then the call will unblock all tasks waiting at -- 2.11.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] barrier: Remove leftover semaphore remnants
Remove various incorrect references to "lock" and "obtain" and to an option set which is not part of the barrier interface. It looks like the barrier documentation was started based on a copy of the semaphore documentation and these things are surviving remnants. Also remove an unfinished sentence in the barrier wait description, since the intended information is already provided in the under the NOTE label. --- c-user/barrier_manager.rst | 38 +++--- 1 file changed, 7 insertions(+), 31 deletions(-) diff --git a/c-user/barrier_manager.rst b/c-user/barrier_manager.rst index b0bf3bf..e5d69b0 100644 --- a/c-user/barrier_manager.rst +++ b/c-user/barrier_manager.rst @@ -324,8 +324,7 @@ NOTES: .. _rtems_barrier_wait: -.. index:: obtain a barrier -.. index:: lock a barrier +.. index:: wait at a barrier .. index:: rtems_barrier_wait BARRIER_WAIT - Wait at a barrier @@ -356,14 +355,11 @@ DIRECTIVE STATUS CODES: DESCRIPTION: -This directive acquires the barrier specified by ``id``. The -``RTEMS_WAIT`` and ``RTEMS_NO_WAIT`` components of the options parameter -indicate whether the calling task wants to wait for the barrier to become -available or return immediately if the barrier is not currently available. -With either ``RTEMS_WAIT`` or ``RTEMS_NO_WAIT``, if the current barrier -count is positive, then it is decremented by one and the barrier is -successfully acquired by returning immediately with a successful return -code. +This directive waits at the barrier specified by ``id``. The timeout +parameter specifies the maximum interval the calling task is willing to be +blocked waiting for the barrier. If it is set to ``RTEMS_NO_TIMEOUT``, +then the calling task will wait forever. If the barrier is available or +the ``RTEMS_NO_WAIT`` option component is set, then timeout is ignored. Conceptually, the calling task should always be thought of as blocking when it makes this call and being unblocked when the barrier is released. If @@ -372,24 +368,7 @@ DESCRIPTION: callers will block except for the one which is the Nth task which trips the automatic release condition. -The timeout parameter specifies the maximum interval the calling task is -willing to be blocked waiting for the barrier. If it is set to -``RTEMS_NO_TIMEOUT``, then the calling task will wait forever. If the -barrier is available or the ``RTEMS_NO_WAIT`` option component is set, then -timeout is ignored. - NOTES: - -The following barrier acquisition option constants are defined by RTEMS: - -.. list-table:: - :class: rtems-table - - * - ``RTEMS_WAIT`` - - task will wait for barrier (default) - * - ``RTEMS_NO_WAIT`` - - task should not wait - A clock tick is required to support the timeout functionality of this directive. @@ -399,7 +378,6 @@ NOTES: .. _rtems_barrier_release: -.. index:: wait at a barrier .. index:: release a barrier .. index:: rtems_barrier_release @@ -425,9 +403,7 @@ DIRECTIVE STATUS CODES: DESCRIPTION: This directive releases the barrier specified by id. All tasks waiting at -the barrier will be unblocked. If the running task's preemption mode is -enabled and one of the unblocked tasks has a higher priority than the -running task. +the barrier will be unblocked. NOTES: The calling task may be preempted if it causes a higher priority task to be -- 2.11.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
FormalRTEMS - Postdoc in formal verification of real-time OS
The School of Computer Science and Statistics in Trinity College Dublin is seeking a post-doctoral Research Fellow in the field of formal software verification, for a duration of 15-18 months, to start as soon as possible. Salary range €40k-€51.5k p.a., depending on experience and precise duration. RTEMS-SMP Qualification is an activity funded by the European Space Agency to perform pre-qualification of an upcoming release of the open-source real-time operating system RTEMS (rtems.org). This release provides support for running RTEMS on multi-core systems. Researchers from Lero, the Irish Software Research Centre are involved in a task that explores the use of formal verification techniques in this qualification process. The task is to deploy formal techniques such as model-checking and possibly theorem proving, to assist in improving the quality of qualification results in key areas. Key areas under consideration include: modelling and verifying the multicore scheduling algorithms MrsP and OMIP and key synchronisation primitives; exploring how formal methods can help with test generation, and particularly for assembly code, with coverage analysis; and probabilistic reasoning to work around testing difficulties due to lack of predictability inherent in multi-core systems. This will require the development and revision of requirements for these algorithms, development of formal models for appropriate formal tools and ways to automate, as far as is practical, the running of those tools. Two key challenges are: to produce outputs that are suitable for software qualification; while doing this in a way that is acceptable to the open-source community (rtems.org) that maintains the operating system. The ideal candidate will have a PhD in software verification with PhD and postdoctoral experience of a number of the following: formal verification tools used in industry such as Promela/SPIN,TLA+, Frama-C; formal models of concurrency; weak memory models; probabilistic modelling; refactoring code to minimise false positives from static analysis tools; software certification and qualification processes; real-time operating systems; and related topics. The position is based at Trinity College Dublin, Ireland (http://www.tcd.ie) and the research fellow will become of a member of Lero - the Irish Software Research Centre (http://lero.ie). It will also involve travel to some of the partners, as well as the the European Space Research and Technology Centre (ESTEC). The activity is being run by a consortium led by Thales Edisoft (Portugal), with partners Embedded Brains (Germany), Jena Optronik (Germany), CISTER Research Centre, ISEP (Portugal), and Trinity College Dublin (Ireland) as part of Lero, the Irish Software Research Centre. Further details, including how to apply, can be obtained from https://www.scss.tcd.ie/Andrew.Butterfield/recruitment/ESA-RTEMS-SMP-Task-3.html which will be regularly updated, or via twitter hashtag #FormalRTEMS. Application deadline, 12noon, Irish Standard Time, Wednesday, 18th September. Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations & Methods Research Group School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3] Basic Support for Trace Compass
> Hello Chris, > > I would like to check in the latest documentation patch from Ravindra as > is and then work on top of it. Otherwise his work is not included in the > project history > I have already sent the v5 of LTTng sched_switch documentation patch: https://lists.rtems.org/pipermail/devel/2019-August/027569.html It has one single patch attachment. I have mentioned what changed from v4 to v5. Thanks > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Wrap Interrupt Handlers for Recording?
Hello, I would like to wrap calls to interrupt handlers which use the generic interrupt framework () to get RTEMS_RECORD_INTERRUPT_ENTRY and RTEMS_RECORD_INTERRUPT_EXIT events. This cannot be done by the linker since the loop to call the handlers is inlined due to performance reasons. I would like to add some sort of a callback mechanism which is invoked in rtems_interrupt_handler_install() and rtems_interrupt_handler_remove() operations (similar to the user extensions). There are some options to do this. 1. A new linker set with functions. 2. A new user extension, maybe a generic: void (*event)(rtems_extension_event event, void *arg); 3. An API to install/remove a specific callback for this purpose. I am in favour of 1. I also would like to hide it from the user for now. -- 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
MrsP Testbed
Greetings, During the last six months, I have been studying RTEMS as part of my final project to complete my degree, more specifically analysing the MrsP protocol in order to perform an evaluation of its implementation on RTEMS. In order to accomplish this analysis, I developed a set of samples that allows one to test several properties of MrsP, based its own rules, as described in [1], including the use of nested resources, presented in [2]. Beyond that, I have also adapted those test cases, using OMIP instead of MrsP, in order to establish comparisons between both protocols. So far the set of develop test cases were executed using QEMU, as up to now I’m not able to execute SMP code in a Raspberry PI 2 (I will address this topic with more detail later on another thread). I wanted to know if: 1- there is any interest from the community for me to submit these tests to the RTEMS repository, or at least the ones considered relevant 2- In case the answer to 1 is affirmative, If I should create a new ticket and submit the test cases as individual patches. Thank you for your attention. Best Regards, Ricardo Gomes P.S. After I complete my final report I can make it available if someone is interested. References: [1] Alan Burns, Andy Wellings, “A schedulability Compatible Multiprocessos Resource Sharing Protocol - MrsP,” . In: 25th Euromicro Conference on Real-Time Systems (ECRTS) (2013) [2] B. Brandenburg, “A Fully Preemptive Multiprocessor Semaphore Protocol for Latency-Sensitive Real-Time Applications,” in Proceedings of the 25th Euromicro Conference on Real-Time Systems (ECRTS), Paris, 2013. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] record: Add support for interrupt handlers
On 04/09/2019 08:06, Chris Johns wrote:
+void LTTNGClient::WriteIRQHandlerExit(PerCPUContext* pcpu, const ClientItem&
item) {
+ pcpu->content_size += kEventIRQHandlerExitBits;
+ pcpu->packet_size += kEventIRQHandlerExitBits;
+
+ EventIRQHandlerExit& ih = pcpu->irq_handler_exit;
+ ih.header.ns = item.ns;
+ ih.irq = static_cast(item.data);
+ fwrite(, sizeof(ih), 1, pcpu->event_stream);
https://en.cppreference.com/w/cpp/io :)
I had a look a this, it seems the error reporting capabilities of
are quite bad (nothing like strerror(errno)). A C++
alternative would be:
https://www.boost.org/doc/libs/1_70_0/libs/filesystem/doc/index.htm
--
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
Re: [PATCH v3] Basic Support for Trace Compass
Hello Chris, I would like to check in the latest documentation patch from Ravindra as is and then work on top of it. Otherwise his work is not included in the project history. -- 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
Re: [PATCH] record: Add support for interrupt handlers
On 4/9/19 5:37 pm, Sebastian Huber wrote:
> On 04/09/2019 08:44, Chris Johns wrote:
>> On 4/9/19 4:27 pm, Sebastian Huber wrote:
>>> On 04/09/2019 08:06, Chris Johns wrote:
> +}
> +
> void LTTNGClient::AddThreadName(PerCPUContext* pcpu, const ClientItem&
> item) {
> if (pcpu->thread_name_index >= THREAD_NAME_SIZE) {
> return;
> @@ -286,6 +339,12 @@ void LTTNGClient::PrintItem(const ClientItem& item) {
> pcpu.thread_ns = item.ns;
> pcpu.thread_name_index = 0;
> break;
> + case RTEMS_RECORD_INTERRUPT_ENTRY:
> + WriteIRQHandlerEntry(, item);
> + break;
> + case RTEMS_RECORD_INTERRUPT_EXIT:
> + WriteIRQHandlerExit(, item);
... then take the address of? I prefer to see references being used where
possible.
>>> This is the Google style:
>>>
>>> https://google.github.io/styleguide/cppguide.html#Reference_Arguments
>>>
>>> I think it makes sense. You see right at the calling place, that a
>>> parameter may
>>> be modified.
>> I do not agree, they forgot to discuss the help the compiler gives you and
>> so I
>> will not adopt it. The Con has "... as they have value syntax but pointer
>> semantics" which is being little simplistic. I could go on but will not it is
>> style and may be related to a large existing code base and that may carry
>> real
>> weight.
>
> I am not a Google C++ Style Guide expert. I guess this rule is somehow related
> to one of the primary goals of the guide:
>
> https://google.github.io/styleguide/cppguide.html#Goals
>
> "Optimize for the reader, not the writer"
>
> The reader here is not the compiler.
I think the compiler is a better reader of code than any of us. :)
> It is fine, if you don't like this rule. We don't have to follow this guide in
> very aspect.
Looking at this I think we may have too.
> I just would like to have some common place default rule set (e.g.
> the Google C++ Style Guide) and it should be allowed to follow the rules.
Sure.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] record: Add support for interrupt handlers
On 04/09/2019 08:44, Chris Johns wrote:
On 4/9/19 4:27 pm, Sebastian Huber wrote:
On 04/09/2019 08:06, Chris Johns wrote:
+}
+
void LTTNGClient::AddThreadName(PerCPUContext* pcpu, const ClientItem& item)
{
if (pcpu->thread_name_index >= THREAD_NAME_SIZE) {
return;
@@ -286,6 +339,12 @@ void LTTNGClient::PrintItem(const ClientItem& item) {
pcpu.thread_ns = item.ns;
pcpu.thread_name_index = 0;
break;
+ case RTEMS_RECORD_INTERRUPT_ENTRY:
+ WriteIRQHandlerEntry(, item);
+ break;
+ case RTEMS_RECORD_INTERRUPT_EXIT:
+ WriteIRQHandlerExit(, item);
... then take the address of? I prefer to see references being used where
possible.
This is the Google style:
https://google.github.io/styleguide/cppguide.html#Reference_Arguments
I think it makes sense. You see right at the calling place, that a parameter may
be modified.
I do not agree, they forgot to discuss the help the compiler gives you and so I
will not adopt it. The Con has "... as they have value syntax but pointer
semantics" which is being little simplistic. I could go on but will not it is
style and may be related to a large existing code base and that may carry real
weight.
I am not a Google C++ Style Guide expert. I guess this rule is somehow
related to one of the primary goals of the guide:
https://google.github.io/styleguide/cppguide.html#Goals
"Optimize for the reader, not the writer"
The reader here is not the compiler.
It is fine, if you don't like this rule. We don't have to follow this
guide in very aspect. I just would like to have some common place
default rule set (e.g. the Google C++ Style Guide) and it should be
allowed to follow the rules.
--
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
Re: [PATCH] record: Add support for interrupt handlers
On 4/9/19 4:27 pm, Sebastian Huber wrote:
> On 04/09/2019 08:06, Chris Johns wrote:
>>> +}
>>> +
>>> void LTTNGClient::AddThreadName(PerCPUContext* pcpu, const ClientItem&
>>> item) {
>>> if (pcpu->thread_name_index >= THREAD_NAME_SIZE) {
>>> return;
>>> @@ -286,6 +339,12 @@ void LTTNGClient::PrintItem(const ClientItem& item) {
>>> pcpu.thread_ns = item.ns;
>>> pcpu.thread_name_index = 0;
>>> break;
>>> + case RTEMS_RECORD_INTERRUPT_ENTRY:
>>> + WriteIRQHandlerEntry(, item);
>>> + break;
>>> + case RTEMS_RECORD_INTERRUPT_EXIT:
>>> + WriteIRQHandlerExit(, item);
>> ... then take the address of? I prefer to see references being used where
>> possible.
>
> This is the Google style:
>
> https://google.github.io/styleguide/cppguide.html#Reference_Arguments
>
> I think it makes sense. You see right at the calling place, that a parameter
> may
> be modified.
I do not agree, they forgot to discuss the help the compiler gives you and so I
will not adopt it. The Con has "... as they have value syntax but pointer
semantics" which is being little simplistic. I could go on but will not it is
style and may be related to a large existing code base and that may carry real
weight.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] record: Add support for interrupt handlers
On 04/09/2019 08:06, Chris Johns wrote:
+}
+
void LTTNGClient::AddThreadName(PerCPUContext* pcpu, const ClientItem& item) {
if (pcpu->thread_name_index >= THREAD_NAME_SIZE) {
return;
@@ -286,6 +339,12 @@ void LTTNGClient::PrintItem(const ClientItem& item) {
pcpu.thread_ns = item.ns;
pcpu.thread_name_index = 0;
break;
+case RTEMS_RECORD_INTERRUPT_ENTRY:
+ WriteIRQHandlerEntry(, item);
+ break;
+case RTEMS_RECORD_INTERRUPT_EXIT:
+ WriteIRQHandlerExit(, item);
... then take the address of? I prefer to see references being used where
possible.
This is the Google style:
https://google.github.io/styleguide/cppguide.html#Reference_Arguments
I think it makes sense. You see right at the calling place, that a
parameter may be modified.
--
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
Re: [PATCH] record: Add support for interrupt handlers
On 4/9/19 3:55 pm, Sebastian Huber wrote:
> Update #3665.
> ---
> trace/record/record-main-lttng.cc | 86
> +--
> 1 file changed, 82 insertions(+), 4 deletions(-)
>
> diff --git a/trace/record/record-main-lttng.cc
> b/trace/record/record-main-lttng.cc
> index 55ac294..340c511 100644
> --- a/trace/record/record-main-lttng.cc
> +++ b/trace/record/record-main-lttng.cc
> @@ -96,6 +96,24 @@ struct EventSchedSwitch {
> static const size_t kEventSchedSwitchBits =
> sizeof(EventSchedSwitch) * BITS_PER_CHAR;
>
> +struct EventIRQHandlerEntry {
> + EventHeaderCompact header;
> + int32_t irq;
> + uint8_t name[1];
> +} __attribute__((__packed__));
> +
> +static const size_t kEventIRQHandlerEntryBits =
> +sizeof(EventIRQHandlerEntry) * BITS_PER_CHAR;
> +
> +struct EventIRQHandlerExit {
> + EventHeaderCompact header;
> + int32_t irq;
> + int32_t ret;
> +} __attribute__((__packed__));
> +
> +static const size_t kEventIRQHandlerExitBits =
> +sizeof(EventIRQHandlerExit) * BITS_PER_CHAR;
> +
> struct PerCPUContext {
>FILE* event_stream;
>uint64_t timestamp_begin;
> @@ -106,6 +124,8 @@ struct PerCPUContext {
>uint64_t thread_ns;
>size_t thread_name_index;
>EventSchedSwitch sched_switch;
> + EventIRQHandlerEntry irq_handler_entry;
> + EventIRQHandlerExit irq_handler_exit;
> };
>
> class LTTNGClient : public Client {
> @@ -116,6 +136,17 @@ class LTTNGClient : public Client {
> memset(_ctx_, 0, sizeof(pkt_ctx_));
> memcpy(pkt_ctx_.header.uuid, kUUID, sizeof(pkt_ctx_.header.uuid));
> pkt_ctx_.header.ctf_magic = CTF_MAGIC;
> +
> +for (size_t i = 0; i < RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT; ++i) {
> + PerCPUContext& pcpu = per_cpu_[i];
> + pcpu.sched_switch.header.id = COMPACT_HEADER_ID;
> + pcpu.sched_switch.header.event_id = 0;
> + pcpu.irq_handler_entry.header.id = COMPACT_HEADER_ID;
> + pcpu.irq_handler_entry.header.event_id = 1;
> + pcpu.irq_handler_entry.name[0] = '\0';
> + pcpu.irq_handler_exit.header.id = COMPACT_HEADER_ID;
> + pcpu.irq_handler_exit.header.event_id = 2;
> +}
>}
>
>void Destroy() {
> @@ -158,6 +189,10 @@ class LTTNGClient : public Client {
>
>void WriteSchedSwitch(PerCPUContext* pcpu, const ClientItem& item);
>
> + void WriteIRQHandlerEntry(PerCPUContext* pcpu, const ClientItem& item);
> +
> + void WriteIRQHandlerExit(PerCPUContext* pcpu, const ClientItem& item);
Why pass pointers and not references when ...
> +
>void AddThreadName(PerCPUContext* pcpu, const ClientItem& item);
>
>void PrintItem(const ClientItem& item);
> @@ -218,8 +253,6 @@ void LTTNGClient::WriteSchedSwitch(PerCPUContext* pcpu,
>pcpu->packet_size += kEventSchedSwitchBits;
>
>EventSchedSwitch& ss = pcpu->sched_switch;
> - ss.header.id = COMPACT_HEADER_ID;
> - ss.header.event_id = 0;
>ss.header.ns = item.ns;
>
>uint32_t api_index = GetAPIIndexOfID(item.data);
> @@ -229,6 +262,26 @@ void LTTNGClient::WriteSchedSwitch(PerCPUContext* pcpu,
>fwrite(, sizeof(ss), 1, pcpu->event_stream);
> }
>
> +void LTTNGClient::WriteIRQHandlerEntry(PerCPUContext* pcpu, const
> ClientItem& item) {
> + pcpu->content_size += kEventIRQHandlerEntryBits;
> + pcpu->packet_size += kEventIRQHandlerEntryBits;
> +
> + EventIRQHandlerEntry& ih = pcpu->irq_handler_entry;
> + ih.header.ns = item.ns;
> + ih.irq = static_cast(item.data);
> + fwrite(, sizeof(ih), 1, pcpu->event_stream);
> +}
> +
> +void LTTNGClient::WriteIRQHandlerExit(PerCPUContext* pcpu, const ClientItem&
> item) {
> + pcpu->content_size += kEventIRQHandlerExitBits;
> + pcpu->packet_size += kEventIRQHandlerExitBits;
> +
> + EventIRQHandlerExit& ih = pcpu->irq_handler_exit;
> + ih.header.ns = item.ns;
> + ih.irq = static_cast(item.data);
> + fwrite(, sizeof(ih), 1, pcpu->event_stream);
https://en.cppreference.com/w/cpp/io :)
> +}
> +
> void LTTNGClient::AddThreadName(PerCPUContext* pcpu, const ClientItem& item)
> {
>if (pcpu->thread_name_index >= THREAD_NAME_SIZE) {
> return;
> @@ -286,6 +339,12 @@ void LTTNGClient::PrintItem(const ClientItem& item) {
>pcpu.thread_ns = item.ns;
>pcpu.thread_name_index = 0;
>break;
> +case RTEMS_RECORD_INTERRUPT_ENTRY:
> + WriteIRQHandlerEntry(, item);
> + break;
> +case RTEMS_RECORD_INTERRUPT_EXIT:
> + WriteIRQHandlerExit(, item);
... then take the address of? I prefer to see references being used where
possible.
Chris
> + break;
> case RTEMS_RECORD_THREAD_NAME:
>AddThreadName(, item);
>break;
> @@ -371,7 +430,6 @@ static const char kMetadata[] =
> "\tmap = clock.monotonic.value;\n"
> "} := uint64_clock_monotonic_t;\n"
> "\n"
> -"\n"
> "trace {\n"
> "\tmajor = 1;\n"
> "\tminor = 8;\n"
> @@ -435,7 +493,7 @@ static const char kMetadata[] =
> "};\n"
> "\n"
> "event {\n"
> -"\tname = \"sched_switch\";\n"
> +
