[PATCH] bsps/irq: Clarify interrupt vector operations
Clarify that the presence of error conditions is implementation-specific. Close #4843. --- bsps/include/bsp/irq-generic.h | 27 +-- 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h index bbfb1979f4..2d330d8d83 100644 --- a/bsps/include/bsp/irq-generic.h +++ b/bsps/include/bsp/irq-generic.h @@ -259,7 +259,10 @@ rtems_status_code bsp_interrupt_vector_is_enabled( * @retval ::RTEMS_SUCCESSFUL The requested operation was successful. * * @retval ::RTEMS_UNSATISFIED The request to enable the interrupt vector has - * not been satisfied. + * not been satisfied. The presence of this error condition is + * implementation-specific. The interrupt vector attributes obtained by + * rtems_interrupt_get_attributes() should indicate if it is possible to + * enable a particular interrupt vector. */ rtems_status_code bsp_interrupt_vector_enable( rtems_vector_number vector ); @@ -280,7 +283,10 @@ rtems_status_code bsp_interrupt_vector_enable( rtems_vector_number vector ); * @retval ::RTEMS_SUCCESSFUL The requested operation was successful. * * @retval ::RTEMS_UNSATISFIED The request to disable the interrupt vector has - * not been satisfied. + * not been satisfied. The presence of this error condition is + * implementation-specific. The interrupt vector attributes obtained by + * rtems_interrupt_get_attributes() should indicate if it is possible to + * disable a particular interrupt vector. */ rtems_status_code bsp_interrupt_vector_disable( rtems_vector_number vector ); @@ -318,8 +324,11 @@ rtems_status_code bsp_interrupt_is_pending( * * @retval ::RTEMS_SUCCESSFUL The requested operation was successful. * - * @retval ::RTEMS_UNSATISFIED The request to cause the interrupt vector has - * not been satisfied. + * @retval ::RTEMS_UNSATISFIED The request to raise the interrupt vector has + * not been satisfied. The presence of this error condition is + * implementation-specific. The interrupt vector attributes obtained by + * rtems_interrupt_get_attributes() should indicate if it is possible to + * raise a particular interrupt vector. */ rtems_status_code bsp_interrupt_raise( rtems_vector_number vector ); @@ -336,7 +345,10 @@ rtems_status_code bsp_interrupt_raise( rtems_vector_number vector ); * @retval ::RTEMS_SUCCESSFUL The requested operation was successful. * * @retval ::RTEMS_UNSATISFIED The request to cause the interrupt vector has - * not been satisfied. + * not been satisfied. The presence of this error condition is + * implementation-specific. The interrupt vector attributes obtained by + * rtems_interrupt_get_attributes() should indicate if it is possible to + * raise a particular interrupt vector on a specific processor. */ rtems_status_code bsp_interrupt_raise_on( rtems_vector_number vector, @@ -353,7 +365,10 @@ rtems_status_code bsp_interrupt_raise_on( * @retval ::RTEMS_SUCCESSFUL The requested operation was successful. * * @retval ::RTEMS_UNSATISFIED The request to cause the interrupt vector has - * not been satisfied. + * not been satisfied. The presence of this error condition is + * implementation-specific. The interrupt vector attributes obtained by + * rtems_interrupt_get_attributes() should indicate if it is possible to + * clear a particular interrupt vector. */ rtems_status_code bsp_interrupt_clear( rtems_vector_number vector ); -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GitLab and BuildBot
Hello Chris, On 2023-02-09 23:26, Chris Johns wrote: On 9/2/2023 6:24 pm, Christian MAUDERER wrote: Hello Chris, On 2023-02-08 23:35, Chris Johns wrote: On 8/2/2023 8:04 pm, Christian MAUDERER wrote: On 2023-02-07 23:37, Chris Johns wrote: On 7/2/2023 9:31 pm, Christian MAUDERER wrote: On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: That shouldn't be a pure decision by the one who pays for the work but one that is (in the optimal case) discussed and specified in the tickets. I did not know that was happening. I am sorry if you think it is and if I gave you that impression. There have been relatively new tickets that changed the status from "needs-funding" to "funded" nearly without delay. That was a bit surprising for me. It seems that the tickets are still updated based on feedback so that is fine and it's great that someone funded them. It just would have been nice if there would have been some announcement for two or three days like "Someone wants to fund the tickets 1, 2 and that part of 4 exactly like they are written now. If there are big objections with the direction, please speak up now." I have never seen EB, your employer, make such an announcement about private commercial in confidence contracts in this way and I would never expect EB to do that so I think it is outrageous you think you can ask this here like this. The funding is a private commercial agreement Amar has and it is no different to the ones your employer makes. Any questions need to be directed to Amar directly but I suggest the questions should be along of the lines of what you can fund. Seems that I exaggerated too much. It's a tendency that I have sometimes as an attempt to be descriptive. I'm sorry if that I haven't been more careful in my choice of words. Thanks and I understand it is not a natural language for you. Of course, it's not relevant for the list whether it's paid or not and who is paying. It doesn't have to have any special form either. But announcements for changes to the devel list are not unusual in general. For bigger changes it's often done before the change. Sometimes vague but it's at least announced (Example: New build system [1], [2], ...). If someone wants to know more or objects the planned changes he can speak up in these mail threads and concerns can be discussed and in the worst case a change can be rejected entirely. For smaller changes everyone just sends patches to the list that are usually accepted and sometimes rejected if someone objects. For infrastructure changes, a patch review after it is done isn't possible. So these are more the big kind of changes that should be announced with at least a few days time for someone to object or discuss. Tickets are nice but they are not very visible. Clearly explaining what is happening is important and if that has not been done then I apologise. The planned work on rtems.org has been split along the lines of infrastructure and services. Infrastructure is stuff no one normally cares about except Amar and myself with oversight by Joel and Gedare. The list includes redundant Cisco firewall updates, base OS updates, movement of jails support, the mess of IPMI+Java+Windows, logs, certs and what ever else the tickets have. The infrastructure lets us provide the services we run. The services we have will run as they have for the last 9 years. The upgraded infrastructure will let add new services such as CI and that is part of the selection process you have kindly participated in. Thanks for the explanation. This list is open and public for the project and its community and I will not tolerant any commercial activity of any type. Sorry, shouldn't have mentioned "Someone wants to fund ...". The tickets already had something similar in the comments, so I didn't think that someone would object as long as it is an anonymous "Someone wants to fund ..." and not "Company X wants to fund ...". Understood. My comment was a reminder to everyone and not specifically you. This discussion is archived so making sure what we are talking about is clear is important. Regarding the tickets, there are many cases over the years of those providing services performing services internally, raising tickets and committing changes. I see no issue here and I am fine with that continuing to happen. Finally, my understanding of the funded tickets is most of the work is to rebuild the servers to be current and capable of running modern CI systems, what ever that ends up being. Maintenance tasks that keep the systems running are fine without an announcement. These are a lot of great work that happens behind the scenes. The maintenance has been happening for nearly 9 years unfunded. A lot of organisations and individuals have created a lot of systems running RTEMS and serviced a lot of clients in that time accessing this system. Lets not lose sight of that :) But these tasks don't change how a user can ac
[PATCH] score: Replace goto with a break
The goto label was directly after the loop, so we can replace the goto
with a break.
Close #4847.
---
cpukit/score/src/threaddispatch.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/cpukit/score/src/threaddispatch.c
b/cpukit/score/src/threaddispatch.c
index b2426fa8ac..ad4c1aca3e 100644
--- a/cpukit/score/src/threaddispatch.c
+++ b/cpukit/score/src/threaddispatch.c
@@ -301,12 +301,13 @@ void _Thread_Do_dispatch( Per_CPU_Control *cpu_self,
ISR_Level level )
heir = _Thread_Get_heir_and_make_it_executing( cpu_self );
/*
- * When the heir and executing are the same, then we are being
- * requested to do the post switch dispatching. This is normally
- * done to dispatch signals.
+ * If the heir and executing are the same, then there is no need to do a
+ * context switch. Proceed to run the post switch actions. This is
+ * normally done to dispatch signals.
*/
-if ( heir == executing )
- goto post_switch;
+if ( heir == executing ) {
+ break;
+}
/*
* Since heir and executing are not the same, we need to do a real
@@ -341,7 +342,11 @@ void _Thread_Do_dispatch( Per_CPU_Control *cpu_self,
ISR_Level level )
_ISR_Local_disable( level );
} while ( cpu_self->dispatch_necessary );
-post_switch:
+ /*
+ * We are done with context switching. Proceed to run the post switch
+ * actions.
+ */
+
_Assert( cpu_self->thread_dispatch_disable_level == 1 );
cpu_self->thread_dispatch_disable_level = 0;
_Profiling_Thread_dispatch_enable( cpu_self, 0 );
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Downtime for devel.rtems.org
Everything should be back up and running again please let me know if there are any issues. The only user-facing service we have using the database is https://devel.rtems.org/ so no other service is affected by this. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [patch] fixes 4557
Hi Zack,
This is close but there are a couple of issues in the commit message we need
fixed. They are the subject line the closing the ticket automatically.
Please run `git commit --amend` to edit the commit message.
Please change commit text to the contents between the dashes:
libmisc/shell: User can't cut using ctrl e and x in medit
Closes #4557
Then send the email like you just have here.
Thanks
Chris
On 10/2/2023 1:35 pm, zack leung wrote:
> fixes 4557 user can't cut using ctrl e and x in medit
> ---
> cpukit/libmisc/shell/main_edit.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/cpukit/libmisc/shell/main_edit.c
> b/cpukit/libmisc/shell/main_edit.c
> index 6e954639e2..8317452b7b 100644
> --- a/cpukit/libmisc/shell/main_edit.c
> +++ b/cpukit/libmisc/shell/main_edit.c
> @@ -1713,7 +1713,6 @@ static void copy_selection(struct editor *ed) {
> ed->env->clipboard = (unsigned char *) realloc(ed->env->clipboard,
> ed->env->clipsize);
> if (!ed->env->clipboard) return;
> copy(ed, ed->env->clipboard, selstart, ed->env->clipsize);
> - select_toggle(ed);
> }
>
> static void cut_selection(struct editor *ed) {
> @@ -2132,7 +2131,7 @@ static void edit(struct editor *ed) {
>
> case ctrl('e'): select_toggle(ed); break;
> case ctrl('a'): select_all(ed); break;
> - case ctrl('c'): copy_selection(ed); break;
> + case ctrl('c'): copy_selection(ed);select_toggle(ed); break;
> case ctrl('f'): find_text(ed, 0); break;
> case ctrl('l'): goto_line(ed); break;
> case ctrl('g'): find_text(ed, 1); break;
> --
> 2.39.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[patch] fixes 4557
fixes 4557 user can't cut using ctrl e and x in medit
---
cpukit/libmisc/shell/main_edit.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/cpukit/libmisc/shell/main_edit.c
b/cpukit/libmisc/shell/main_edit.c
index 6e954639e2..8317452b7b 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -1713,7 +1713,6 @@ static void copy_selection(struct editor *ed) {
ed->env->clipboard = (unsigned char *) realloc(ed->env->clipboard,
ed->env->clipsize);
if (!ed->env->clipboard) return;
copy(ed, ed->env->clipboard, selstart, ed->env->clipsize);
- select_toggle(ed);
}
static void cut_selection(struct editor *ed) {
@@ -2132,7 +2131,7 @@ static void edit(struct editor *ed) {
case ctrl('e'): select_toggle(ed); break;
case ctrl('a'): select_all(ed); break;
-case ctrl('c'): copy_selection(ed); break;
+case ctrl('c'): copy_selection(ed);select_toggle(ed); break;
case ctrl('f'): find_text(ed, 0); break;
case ctrl('l'): goto_line(ed); break;
case ctrl('g'): find_text(ed, 1); break;
--
2.39.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-release] rtems-notes-6.md: Add removal of libmisc/serdbg
OK. I will apply if you do not because I want to move that file :) Chris On 10/2/2023 2:11 am, Joel Sherrill wrote: > Updates #2828. > --- > rtems-notes-6.md | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/rtems-notes-6.md b/rtems-notes-6.md > index 70b66a3..7197def 100644 > --- a/rtems-notes-6.md > +++ b/rtems-notes-6.md > @@ -262,7 +262,8 @@ The following improvements were made to the RTEMS Shell: > > ## General > > -* TBD > +* The obsolete libmisc/serdbg was removed. Use libdebugger instead. This > functionality > + was not built as part of the 5 release series in anticipation of its > removal. > > ## Architectures > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Downtime for devel.rtems.org
On 10/2/2023 8:12 am, Amar Takhar wrote: > At some point today 2022-02-09 https://devel.rtems.org/ will go down as the > machine that hosts our database goes through some upgrades. Any issues or > intermittent outages should be gone by 6AM GMT 2022-02-10. To users with accounts on dispatch.rtems.org your home directories will be backed up and restored. If there are things like cron jobs etc I suggest you get a copy of the config or a copy of your $HOME if you are concerned. Note, your git and ftp directories are links so there is no need to back those up. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GitLab and BuildBot
On 9/2/2023 6:24 pm, Christian MAUDERER wrote: > Hello Chris, > > On 2023-02-08 23:35, Chris Johns wrote: >> On 8/2/2023 8:04 pm, Christian MAUDERER wrote: >>> On 2023-02-07 23:37, Chris Johns wrote: On 7/2/2023 9:31 pm, Christian MAUDERER wrote: > On 2023-02-07 07:03, Chris Johns wrote: >> On 30/1/2023 10:12 pm, Christian MAUDERER wrote: > That shouldn't be a pure decision by the one who pays for the work but one > that > is (in the optimal case) discussed and specified in the tickets. I did not know that was happening. I am sorry if you think it is and if I gave you that impression. >>> >>> There have been relatively new tickets that changed the status from >>> "needs-funding" to "funded" nearly without delay. That was a bit surprising >>> for me. >>> >>> It seems that the tickets are still updated based on feedback so that is >>> fine >>> and it's great that someone funded them. It just would have been nice if >>> there >>> would have been some announcement for two or three days like "Someone wants >>> to >>> fund the tickets 1, 2 and that part of 4 exactly like they are written now. >>> If >>> there are big objections with the direction, please speak up now." >> >> I have never seen EB, your employer, make such an announcement about private >> commercial in confidence contracts in this way and I would never expect EB >> to do >> that so I think it is outrageous you think you can ask this here like this. >> The >> funding is a private commercial agreement Amar has and it is no different to >> the >> ones your employer makes. Any questions need to be directed to Amar directly >> but >> I suggest the questions should be along of the lines of what you can fund. > > Seems that I exaggerated too much. It's a tendency that I have sometimes as an > attempt to be descriptive. I'm sorry if that I haven't been more careful in my > choice of words. Thanks and I understand it is not a natural language for you. > Of course, it's not relevant for the list whether it's paid or not and who is > paying. It doesn't have to have any special form either. > > But announcements for changes to the devel list are not unusual in general. > For > bigger changes it's often done before the change. Sometimes vague but it's at > least announced (Example: New build system [1], [2], ...). If someone wants to > know more or objects the planned changes he can speak up in these mail threads > and concerns can be discussed and in the worst case a change can be rejected > entirely. > > For smaller changes everyone just sends patches to the list that are usually > accepted and sometimes rejected if someone objects. > > For infrastructure changes, a patch review after it is done isn't possible. So > these are more the big kind of changes that should be announced with at least > a > few days time for someone to object or discuss. Tickets are nice but they are > not very visible. Clearly explaining what is happening is important and if that has not been done then I apologise. The planned work on rtems.org has been split along the lines of infrastructure and services. Infrastructure is stuff no one normally cares about except Amar and myself with oversight by Joel and Gedare. The list includes redundant Cisco firewall updates, base OS updates, movement of jails support, the mess of IPMI+Java+Windows, logs, certs and what ever else the tickets have. The infrastructure lets us provide the services we run. The services we have will run as they have for the last 9 years. The upgraded infrastructure will let add new services such as CI and that is part of the selection process you have kindly participated in. >> This list is open and public for the project and its community and I will not >> tolerant any commercial activity of any type. >> > > Sorry, shouldn't have mentioned "Someone wants to fund ...". The tickets > already > had something similar in the comments, so I didn't think that someone would > object as long as it is an anonymous "Someone wants to fund ..." and not > "Company X wants to fund ...". Understood. My comment was a reminder to everyone and not specifically you. This discussion is archived so making sure what we are talking about is clear is important. >> Regarding the tickets, there are many cases over the years of those providing >> services performing services internally, raising tickets and committing >> changes. >> I see no issue here and I am fine with that continuing to happen. >> >> Finally, my understanding of the funded tickets is most of the work is to >> rebuild the servers to be current and capable of running modern CI systems, >> what >> ever that ends up being. >> > > Maintenance tasks that keep the systems running are fine without an > announcement. These are a lot of great work that happens behind the scenes. The maintenance has been happening for nearly 9 years unfunded. A lot of organisations and individuals have created a lot of systems
Re: [PATCH rtems] libmisc/serdbg: Remove obsolete serial debug
Looks good and thanks
Chris
On 10/2/2023 2:11 am, Joel Sherrill wrote:
> Closes #2828.
> ---
> cpukit/include/rtems/serdbg.h | 168 ---
> cpukit/include/rtems/serdbgcnf.h | 101
> cpukit/include/rtems/termios_printk.h | 116 -
> cpukit/include/rtems/termios_printk_cnf.h | 91 --
> cpukit/libmisc/serdbg/README | 134 ---
> cpukit/libmisc/serdbg/serdbg.c| 105
> cpukit/libmisc/serdbg/serdbgio.c | 264
> --
> cpukit/libmisc/serdbg/termios_printk.c| 245 ---
> spec/build/cpukit/librtemscpu.yml | 4 -
> 9 files changed, 1228 deletions(-)
> delete mode 100644 cpukit/include/rtems/serdbg.h
> delete mode 100644 cpukit/include/rtems/serdbgcnf.h
> delete mode 100644 cpukit/include/rtems/termios_printk.h
> delete mode 100644 cpukit/include/rtems/termios_printk_cnf.h
> delete mode 100644 cpukit/libmisc/serdbg/README
> delete mode 100644 cpukit/libmisc/serdbg/serdbg.c
> delete mode 100644 cpukit/libmisc/serdbg/serdbgio.c
> delete mode 100644 cpukit/libmisc/serdbg/termios_printk.c
>
> diff --git a/cpukit/include/rtems/serdbg.h b/cpukit/include/rtems/serdbg.h
> deleted file mode 100644
> index eef2a01..000
> --- a/cpukit/include/rtems/serdbg.h
> +++ /dev/null
> @@ -1,168 +0,0 @@
> -/* SPDX-License-Identifier: BSD-2-Clause */
> -
> -/*
> - * RTEMS remote gdb over serial line
> - *
> - * This file declares intialization functions to add
> - * a gdb remote debug stub to an RTEMS system.
> - */
> -
> -/*
> - * Copyright (c) 2002 IMD Ingenieurbuero fuer Microcomputertechnik
> - * All rights reserved.
> - *
> - * Redistribution and use in source and binary forms, with or without
> - * modification, are permitted provided that the following conditions
> - * are met:
> - * 1. Redistributions of source code must retain the above copyright
> - *notice, this list of conditions and the following disclaimer.
> - * 2. Redistributions in binary form must reproduce the above copyright
> - *notice, this list of conditions and the following disclaimer in the
> - *documentation and/or other materials provided with the distribution.
> - *
> - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> - * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> - * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> - * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> - * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> - * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> - * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> - * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> - * POSSIBILITY OF SUCH DAMAGE.
> - */
> -
> -#ifndef _SERDBG_H
> -#define _SERDBG_H
> -
> -#include
> -#include
> -
> -#ifdef __cplusplus
> -extern "C" {
> -#endif
> -
> -typedef struct {
> - uint32_t baudrate; /* debug baud rate, e.g. 57600*/
> - void (*callout)(void);/* callout pointer during polling */
> - int (*open_io)(const char *dev_name, uint32_t baudrate); /* I/O open fnc
> */
> - const char *devname; /* debug device, e.g. "/dev/tty01"*/
> - bool skip_init_bkpt; /* if TRUE, do not stop when initializing */
> -} serdbg_conf_t;
> -
> -/*
> - * must be defined in init module...
> - */
> -extern serdbg_conf_t serdbg_conf;
> -
> -
> -/*=*\
> -| Function: |
> -\*-*/
> -void putDebugChar
> -(
> -/*-*\
> -| Purpose: |
> -| send character to remote debugger |
> -+---+
> -| Input Parameters: |
> -\*-*/
> - charc /* char to send*/
> - );
> -/*-*\
> -| Return Value: |
> -| |
> -\*=*/
> -
> -/*==
Downtime for devel.rtems.org
At some point today 2022-02-09 https://devel.rtems.org/ will go down as the machine that hosts our database goes through some upgrades. Any issues or intermittent outages should be gone by 6AM GMT 2022-02-10. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] doxygen: Document CONFIGURE_INIT
On 09.02.23 16:47, Sebastian Huber wrote:
+ * While ``CONFIGURE_INIT`` is defined, when ${header-confdefs:/name} is
Sorry, there is a bug in the script.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] doxygen: Document CONFIGURE_INIT
---
cpukit/doxygen/appl-config.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 5dc84824da..fb071f07d4 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -50,6 +50,17 @@
* @ingroup RTEMSAPI
*/
+/* Generated from spec:/acfg/if/init */
+
+/**
+ * @brief This define enables the generation of the application configuration.
+ *
+ * While ``CONFIGURE_INIT`` is defined, when ${header-confdefs:/name} is
+ * included, the application configuration is generated according to the
+ * application configuration options provided by the user.
+ */
+#define CONFIGURE_INIT
+
/* Generated from spec:/acfg/if/group-bdbuf */
/**
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems] libmisc/serdbg: Remove obsolete serial debug
Closes #2828.
---
cpukit/include/rtems/serdbg.h | 168 ---
cpukit/include/rtems/serdbgcnf.h | 101
cpukit/include/rtems/termios_printk.h | 116 -
cpukit/include/rtems/termios_printk_cnf.h | 91 --
cpukit/libmisc/serdbg/README | 134 ---
cpukit/libmisc/serdbg/serdbg.c| 105
cpukit/libmisc/serdbg/serdbgio.c | 264 --
cpukit/libmisc/serdbg/termios_printk.c| 245 ---
spec/build/cpukit/librtemscpu.yml | 4 -
9 files changed, 1228 deletions(-)
delete mode 100644 cpukit/include/rtems/serdbg.h
delete mode 100644 cpukit/include/rtems/serdbgcnf.h
delete mode 100644 cpukit/include/rtems/termios_printk.h
delete mode 100644 cpukit/include/rtems/termios_printk_cnf.h
delete mode 100644 cpukit/libmisc/serdbg/README
delete mode 100644 cpukit/libmisc/serdbg/serdbg.c
delete mode 100644 cpukit/libmisc/serdbg/serdbgio.c
delete mode 100644 cpukit/libmisc/serdbg/termios_printk.c
diff --git a/cpukit/include/rtems/serdbg.h b/cpukit/include/rtems/serdbg.h
deleted file mode 100644
index eef2a01..000
--- a/cpukit/include/rtems/serdbg.h
+++ /dev/null
@@ -1,168 +0,0 @@
-/* SPDX-License-Identifier: BSD-2-Clause */
-
-/*
- * RTEMS remote gdb over serial line
- *
- * This file declares intialization functions to add
- * a gdb remote debug stub to an RTEMS system.
- */
-
-/*
- * Copyright (c) 2002 IMD Ingenieurbuero fuer Microcomputertechnik
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
- * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- */
-
-#ifndef _SERDBG_H
-#define _SERDBG_H
-
-#include
-#include
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-typedef struct {
- uint32_t baudrate; /* debug baud rate, e.g. 57600*/
- void (*callout)(void);/* callout pointer during polling */
- int (*open_io)(const char *dev_name, uint32_t baudrate); /* I/O open fnc */
- const char *devname; /* debug device, e.g. "/dev/tty01"*/
- bool skip_init_bkpt; /* if TRUE, do not stop when initializing */
-} serdbg_conf_t;
-
-/*
- * must be defined in init module...
- */
-extern serdbg_conf_t serdbg_conf;
-
-
-/*=*\
-| Function: |
-\*-*/
-void putDebugChar
-(
-/*-*\
-| Purpose: |
-| send character to remote debugger |
-+---+
-| Input Parameters: |
-\*-*/
- charc /* char to send*/
- );
-/*-*\
-| Return Value: |
-| |
-\*=*/
-
-/*=*\
-| Function: |
-\*-*/
-int getDebugChar
-(
-/*-*\
-| Purpose:
[PATCH rtems-release] rtems-notes-6.md: Add removal of libmisc/serdbg
Updates #2828. --- rtems-notes-6.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rtems-notes-6.md b/rtems-notes-6.md index 70b66a3..7197def 100644 --- a/rtems-notes-6.md +++ b/rtems-notes-6.md @@ -262,7 +262,8 @@ The following improvements were made to the RTEMS Shell: ## General -* TBD +* The obsolete libmisc/serdbg was removed. Use libdebugger instead. This functionality + was not built as part of the 5 release series in anticipation of its removal. ## Architectures -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] spec/bsps: Deduplicate objxilinxsupport
On 09.02.23 01:44, Chris Johns wrote: On 7/2/2023 5:55 pm, Sebastian Huber wrote: On 06.02.23 23:09, Gedare Bloom wrote: ok. I'm not sure, maybe we need a note about this in https://docs.rtems.org/branches/master/eng/build-system.html A hint in the documentation would be helpful. Even more helpful would be a consistency check before patch sets are pulled in. For example, it is a bug if you have a diamond in the build dependency graph and the nodes with an indegree greater than one install files. If the nodes with an indegree greater than one build source files with identical build options, then this is also a bug. However, a valid special case could be a node which is built with different build flags, for example: lib -> grp_a (-DFLAG_A) -> objxyz \---> grp_b (-DFLAG_B) -> objxyz I would expect that case would map to separate build objects? For object files I think waf is able to support this. For installed files it doesn't work. How do you suggest someone proceed to add a check? Would that check happen when the spec files are parsed? That is, we assume the pickled output loaded on each build is OK? You don't have to check this during a build. These issues can be detected by analyzing the build specification items. The support for this is in rtems-central. So my proposal would be that we check this in pull requests (which we don't have at the moment). Do we have any unittests for the build system? Adding a check would mean we need a test case to generate the problem? It is possible to write unit tests for the build system and I did some experiments with this while writing it. However, the unit tests are quite incomplete, out dated, and not integrated. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
