Re: New validation test suites

[Chris Johns]

On 15/2/22 12:43 am, Sebastian Huber wrote:
> On 03/02/2022 09:09, Sebastian Huber wrote:
>> On 30/01/2022 23:26, Chris Johns wrote:
>>>>>> We just have to create a
>>>>>> release branch for RTEMS 6 and reference release branch commits in the
>>>>>> submodules.
>>>>> How do you validate the generated sources in the sub-modules match those 
>>>>> in
>>>>> the
>>>>> branched submodules? I think this should be done as part of the release
>>>>> procedure to catch any mistakes.
>>>> I will write something about this in the release procedure documentation.
>>> Thank you, I appreciate this. This is a big help.
>>
>> I added a note to the post-branch procedure:
>>
>> https://docs.rtems.org/branches/master/eng/release-process.html#post-branch-procedure
> 

Thank you.

I noticed the documenting of branches in the procedure. Is it required they be
present to run the procedure? An important phase of making a release is the
release candidates and these are run off master. Branching before we know we are
close to working is an important aspect of the pre-release testing as it brings
a range of parts together. This should happen before branching.

> How do we want to proceed here?

I am currently rather busy on something and will be for a while. As a result I
have been a little distracted and I apologise for this.

> I have no idea what should I do next.

As has been stated, making a release takes some time and effort and my
experience of doing it has taught me all the detail needs to be covered. Until I
can see rtems-central integrated into a release we cannot not depend on it.
Given the way the validation tests have been created merging makes rtems.git
depend on rtems-central if merged. In the past we have not taken care of these
things and it has fallen to me to sort out and I prefer that does not happen in
this case.

I should also state the rtems-central repo is on probation and even if it is
added to a release it will still remain like that for a reasonable period of
time. It is still not clear where the line of responsibility lies with that repo
and the long term maintenance of the qual effort. This may appear abrupt however
I need to be clear about this so there is no misunderstanding.

> The new validation tests are not the only work from the pre-qualification
> activity I would like to integrate. We also have work from Andrew Butterfields
> related to formal methods. There are changes in the GR712RC and GR740 BSPs, 
> the
> gcov code coverage support, and build system changes to support the build of
> RTEMS libraries which contain only the pre-qualified feature set.

Making a release is documented here:

https://git.rtems.org/rtems-release/tree/README.txt

I run a single command that creates a complete release. How will the procedure
outlined in the eng manual be implemented here? [1]

What will an rtems-central tarball look like? I am specifically concerned the
export process to turn a git repo into a tarball will include a copy of the
sub-modules. This is the current way the release scripts work. If this is the
case we will have 2 copies of some repos in the release and I think that is a
bad idea.

Chris

[1] The release scripts assume an autoconf RTEMS and so I suspect what is there
is broken. This makes the rtems-central integration more complicated than it
need be. I have not looked at what is needed.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] Add option --build-manuals to build multiple specific manuals.

[Chris Johns]

On 12/2/22 3:37 am, Shashvat wrote:
> Hi Gedare!!
> 
> Is there a ticket associated with this, or any feature request? Or
>> just something you thought of doing?
>>
> 
> I am sorry I should have mentioned the motive behind the option.
> I was planning to work on ticket # which works on a specific
> posix-users manual afaik. I wanted waf to build only this particular manual
> so asked Chris on discord if it is possible and he told me how it was
> broken, and that it would be good to add an option that enables this.

I think this is nice feature to have if you are concentrating on a specific 
manual.

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

Re: [PATCH rtems-libbsd v2 0/3] MicroBlaze AXI Ethernet Support

[Chris Johns]

Alex,

The AIX IP here is used in a number of places. Should we use:

Xilinx AXI Ethernet Support

?

It may help others looking for support.

Chris

On 11/2/22 9:12 am, Alex White wrote:
> v2:
> - Reworked patches to follow CONTRIBUTING.md guide
> - Excluded unneeded vmem calls
> - Moved ethernet frame alignment handling to the network interface driver
> 
> This patch set adds support for Xilinx's AXI Ethernet IP core. It has
> been tested both in QEMU and on the KCU105 board using the default
> FPGA implementation from the Xilinx's KCU105 PetaLinux BSP.
> 
> Alex White (1):
>   if_xae: Port to RTEMS
> 
> Jennifer Averett (2):
>   Add MicroBlaze support
>   if_xae: Import from FreeBSD
> 
>  buildset/default.ini  |1 +
>  freebsd/sys/dev/mii/tiphy.h   |   57 +
>  freebsd/sys/dev/xdma/xdma.c   |  501 
>  freebsd/sys/dev/xdma/xdma.h   |  285 +
>  freebsd/sys/dev/xdma/xdma_bank.c  |  100 ++
>  freebsd/sys/dev/xdma/xdma_mbuf.c  |  151 +++
>  freebsd/sys/dev/xdma/xdma_queue.c |  126 ++
>  freebsd/sys/dev/xdma/xdma_sg.c|  661 ++
>  freebsd/sys/dev/xdma/xdma_sglist.c|  103 ++
>  freebsd/sys/dev/xilinx/axidma.c   |  677 ++
>  freebsd/sys/dev/xilinx/axidma.h   |   96 ++
>  freebsd/sys/dev/xilinx/if_xae.c   | 1108 +
>  freebsd/sys/dev/xilinx/if_xaereg.h|  122 ++
>  freebsd/sys/dev/xilinx/if_xaevar.h|   80 ++
>  .../sys/microblaze/include/machine/in_cksum.h |   83 ++
>  libbsd.py |   41 +-
>  rtemsbsd/include/bsp/nexus-devices.h  |   10 +-
>  rtemsbsd/include/rtems/bsd/local/xdma_if.h|  144 +++
>  rtemsbsd/local/xdma_if.c  |   57 +
>  .../rtems/bsd/test/network-config.h.in|2 +
>  20 files changed, 4401 insertions(+), 4 deletions(-)
>  create mode 100644 freebsd/sys/dev/mii/tiphy.h
>  create mode 100644 freebsd/sys/dev/xdma/xdma.c
>  create mode 100644 freebsd/sys/dev/xdma/xdma.h
>  create mode 100644 freebsd/sys/dev/xdma/xdma_bank.c
>  create mode 100644 freebsd/sys/dev/xdma/xdma_mbuf.c
>  create mode 100644 freebsd/sys/dev/xdma/xdma_queue.c
>  create mode 100644 freebsd/sys/dev/xdma/xdma_sg.c
>  create mode 100644 freebsd/sys/dev/xdma/xdma_sglist.c
>  create mode 100644 freebsd/sys/dev/xilinx/axidma.c
>  create mode 100644 freebsd/sys/dev/xilinx/axidma.h
>  create mode 100644 freebsd/sys/dev/xilinx/if_xae.c
>  create mode 100644 freebsd/sys/dev/xilinx/if_xaereg.h
>  create mode 100644 freebsd/sys/dev/xilinx/if_xaevar.h
>  create mode 100644 freebsd/sys/microblaze/include/machine/in_cksum.h
>  create mode 100644 rtemsbsd/include/rtems/bsd/local/xdma_if.h
>  create mode 100644 rtemsbsd/local/xdma_if.c
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-libbsd commit] sys/kern: Add VFS support

[Chris Johns]

On 9/2/22 7:43 pm, Sebastian Huber wrote:
> On 09/02/2022 09:41, Sebastian Huber wrote:
>> On 08/02/2022 11:07, Chris Johns wrote:
>>>> It seems that the commit is not present in the master branch. This means 
>>>> all
>>>> the
>>>> work will be lost when we update to a newer FreeBSD baseline.
>>> Yes. It is an out standing task that I need to get funding for.
>>>
>>> What are your plans and if you are looking to update, timeline?
>>
>> The last update was in 2019, so we ship a pretty outdated FreeBSD in libbsd. 
>> I
>> currently estimate the work to do an update, but I don't have a timeline.
> 
> Actually the last update was "Update to FreeBSD stable/12 2020-02-10".
> 

Which branch or branches are you referring too?

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

Re: [rtems-libbsd commit] sys/kern: Add VFS support

[Chris Johns]

On 8/2/22 12:48 am, Sebastian Huber wrote:
> Hello Chris,
> 
> sorry, this slipped through may review list.

Thanks for the review.

> 
> On 02/09/2021 04:43, Chris Johns wrote:
>> @@ -1232,9 +993,6 @@ osendmsg(struct thread *td, struct osendmsg_args *uap)
>>   #endif
>>   #endif /* __rtems__ */
>>   -#ifdef __rtems__
>> -static
>> -#endif /* __rtems__ */
>>   int
>>   sys_sendmsg(struct thread *td, struct sendmsg_args *uap)
>>   {
>> @@ -1257,35 +1015,7 @@ sys_sendmsg(struct thread *td, struct sendmsg_args 
>> *uap)
>>   free(iov, M_IOV);
>>   return (error);
>>   }
>> -#ifdef __rtems__
>> -ssize_t
>> -sendmsg(int socket, const struct msghdr *message, int flags)
>> -{
>> -    struct thread *td = rtems_bsd_get_curthread_or_null();
>> -    struct sendmsg_args ua = {
>> -    .s = socket,
>> -    .msg = message,
>> -    .flags = flags
>> -    };
>> -    int error;
>> -
>> -    if (td != NULL) {
>> -    error = sys_sendmsg(td, );
>> -    } else {
>> -    error = ENOMEM;
>> -    }
>> -
>> -    if (error == 0) {
>> -    return td->td_retval[0];
>> -    } else {
>> -    rtems_set_errno_and_return_minus_one(error);
>> -    }
>> -}
>> -#endif /* __rtems__ */
> 
> Why did you move all these system call implementations for RTEMS into a 
> separate
> file? The sys_sendmsg() was a static function so the compiler was able to
> optimize the use of struct sendmsg_args away and there was no function call
> overhead.  In the successful case the return value was determined by
> td->td_retval[0]. I don't think this now the case?
> 
> ssize_t
> sendmsg(int socket, const struct msghdr *message, int flags)
> {
> struct thread *td = rtems_bsd_get_curthread_or_null();
> struct sendmsg_args ua;
> int ffd;
> int error;
> if (RTEMS_BSD_SYSCALL_TRACE) {
>     printf("bsd: sys: sendmsg: %d\n", socket);
> }
> if (td == NULL) {
>     return rtems_bsd_error_to_status_and_errno(ENOMEM);
> }
> ffd = rtems_bsd_libio_iop_hold(socket, NULL);
> if (ffd < 0) {
>     return rtems_bsd_error_to_status_and_errno(EBADF);
> }
> ua.s = ffd;
> ua.msg = message;
> ua.flags = flags;
> error = sys_sendmsg(td, );
> rtems_bsd_libio_iop_drop(socket);
> return rtems_bsd_error_to_status_and_errno(error);> }
> 
> Unfortunately syscalls01 only tests error conditions and not a good case.

It looks like a bug. I think there should be a check of `error` after the drop
and the call's result returned.

> It seems that the commit is not present in the master branch. This means all 
> the
> work will be lost when we update to a newer FreeBSD baseline.

Yes. It is an out standing task that I need to get funding for.

What are your plans and if you are looking to update, timeline?

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

Re: Where can I get the kernel sources?

[Chris Johns]

On 3/2/22 4:02 am, Heinz Junkes wrote:
> I think I slept through the latest development. Sorry about that.

Welcome back.

> Where can I get the rtems sources (c/src)?

This directory has gone. It had only existed on the master branch recently to
hold the autoconf build files and we have now removed all autoconf support from
master. RTEMS 6 is the first release with the new waf build support.

The sources that lived under the `c/src` had been moved over a period of time in
stages. The first major change was moving all the header files to
`cpukit/include` and `bsps/include`, then non-bsp sources were moved to various
places then finally the bsp sources were moved to `bsps`. The autoconf build
files were not mived because we knew they were going to be removed.

The tree under the top level directory `bsps` is kind of the same as the old
path of `c/src/lib/libbsp`. There has been some changes in the bsps but this is
mostly improved reuse of sources across bsps.

Also gone from the tree is `cpukit/libnetworking`. The legacy networking stack
is now in a separate repo ... https://git.rtems.org/rtems-net-legacy/.

I hope this helps

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

[RBW] Re: New Bike-Trade Day - A(nother) Quickbeam

[JohnS]

Patch, that's a great looking bike. I'm always impressed with how versatile 
the QB/S1 are, commuter, rando-like, trail, does it all, as long as it's 
not too hilly (DP would recommend walking in that case, lowest common gear).

Good luck,
JohnS 

Who's only Riv is an orange QB.

On Monday, January 31, 2022 at 10:54:44 AM UTC-5 Doug H. wrote:

> Bill,
> There is a 57 cm Frank Jones Sr. on eBay if that interests you. I'll post 
> the link in case you hadn't seen it. 
> https://www.ebay.com/itm/185245621839?mkevt=1=1=0=711-53200-19255-0=20008=5335981329=with-subcat
> Doug
>
> On Monday, January 31, 2022 at 10:46:59 AM UTC-5 Bill Lindsay wrote:
>
>> APPROVE!
>>
>> I want a silver 58cm Quickbeam.  There's a green 60cm locally, but I 
>> don't like British Racing Green on bikes.  I might end up with it anyway, 
>> but I'm not going to cry if somebody else buys it.  If that 60cm green was 
>> a 58cm silver, I'd already have it...
>>
>> Bill Lindsay
>> El Cerrito, CA
>>
>> On Monday, January 31, 2022 at 6:28:48 AM UTC-8 Patch T wrote:
>>
>>> Hi Bunch,
>>>
>>> *tl:dr - Kyle's Quickbeam was too big. Mine was maybe too small. We 
>>> swapped. Photos.*
>>>
>>> I've ridden an orange Quickbeam for about 5 years. It's seen all sorts 
>>> of builds, all sorts of rides, camping trips, commutes; the slow end of a 
>>> toxic relationship and the start of a healthy one, an engagement, a 
>>> cross-country move (again), a pandemic a career change... As you can 
>>> imagine, I'm in love with the bike. My first and only Rivendell (so far) 
>>> but I don't really feel the itch for another. Ok maybe a Mountain Mixte. Or 
>>> Roadeo. Or Saluki, maybe. I digress. 
>>>
>>> I sold a few frames so I could purchase it, used, from an angel named 
>>> John who even let me pay in installments. I've learned a lot about bikes 
>>> and about wrenching, but also about sizing in the short 5 years since - one 
>>> thing I learned is that I should/could ride larger bikes than I thought. 
>>>
>>> For a while it was my only bike. Kyle from Golden Saddle Cycles used to 
>>> frequently catch me outside riding the QB back when I lived in LA, or when 
>>> I visited his shop, and every time he would remind me he'd gladly purchase 
>>> that bike when I'm ready to sell. You can imagine my answer - however, he 
>>> never let up. 
>>>
>>> Fast forward to cruising Instagram late last year, now living in NYC, 
>>> and I saw that Kyle finally got his holy grail - a silver Quickbeam - but 
>>> in a size too big for him. He thought he'd like to try out a French fit, 
>>> but it didn't work out. So I wrote him, thinking his new-to-him 56 would 
>>> fit me better (or, differently + nicely) than my beloved 54. He agreed, and 
>>> we packed and shipped each other our frames (he had me ship his to Black 
>>> Magic Paint!) 
>>>
>>> I've spent the past month rebuilding; highlights include a TA crank, 
>>> shiny VO fenders, Compass Maes Parallel bar, Swift rando bag, dyno 
>>> lighting, Paul brakes (minimoto front, touring rear), 38mm Gravelking 
>>> slicks.
>>>
>>> Was it worth the $80ish in shipping? Maybe. It's not necessarily *more* 
>>> comfortable, but *differently* comfortable. I do like having a shorter 
>>> stem, and less seatpost showing than before - that feeling of being *in* 
>>> it, rather than *above* it. All in all - with the new color and different 
>>> (again) parts - it's kinda like a new bike day, for under $100.
>>>
>>> Patch
>>> BK/NYC
>>>  [image: image3 (2).jpeg][image: image1 (16).jpeg]
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/6125a20d-d221-4f9d-9d24-6f597b8a86fen%40googlegroups.com.

Re: RISC-V BSP Build Failures on Ubuntu

[Chris Johns]

On 30/1/22 7:19 am, Joel Sherrill wrote:
> Hi
> https://lists.rtems.org/pipermail/build/2022-January/031425.html
> 
> bsp-builder is reporting this. Help appreciated. Looks like it could
> be a tooling issue
> 
> Failures Report
> ===
>1 posix-debug riscv/frdme310arty build:
>   configure: /home/tester/rtems-cron-6/rtems/waf configure\
>   --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
>   /rtems-cron-6/rtems --rtems-config=config-riscv-frdme310arty-posix-\
>   debug.ini
>  error: ld/collect2:0 error: no error message found!

Could you please check the detailed and log and see what the actual error
message is? There is code in the bsp builder to handle these linker errors and
it seems it may need an update.

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

Re: New validation test suites

[Chris Johns]

On 27/1/22 6:09 pm, Sebastian Huber wrote:
> On 27/01/2022 03:24, Chris Johns wrote:
>> On 25/1/22 5:37 pm, Sebastian Huber wrote:
>>> On 25/01/2022 01:09, Chris Johns wrote:
>>>> On 25/1/22 1:39 am, Sebastian Huber wrote:
>>>>> how do we want to proceed with the integration of the new validation test
>>>>> suite?
>>>>> At the moment it is not clear to me what issues are left to resolve and 
>>>>> what I
>>>>> can do to address them?
>>>>
>>>> I believe I have been clear about what I see as being needed:
>>>>
>>>> https://lists.rtems.org/pipermail/devel/2022-January/070323.html
>>>
>>> Sorry, I don't know what I have to do next.
>>
>> Sure and I am sorry if this was not clear.
>>
>>> The release process for rtems-central is quite clear from my point of view.
>>
>> I would not have raised this if I was in the same position. You are the only
>> person I know who understand rtems-central. I only have an overview of it 
>> and I
>> I am sorry but I have no spare time in invest in learning more about it. I do
>> have the responsibility of releasing RTEMS and if I accept these changes 
>> without
>> any of the needed support in place history has taught me I am left to provide
>> it. Tools and scripts that shows how a process is to work would go a long 
>> long
>> way to resolving this issue.
>>
>> The RTEMS Release repo is a series of FreeBSD scripts I use to release ...
>>
>> https://git.rtems.org/rtems-release/
>>
>> I have not touched it in a while and it needs work to change it to support 
>> waf.
> 
> Ok, I will update
> 
> https://docs.rtems.org/branches/master/eng/release-process.html
> 
> to account for rtems-central.git.
> 
> It seems that there is some work to do to make an RTEMS 6.1 release happen in
> general (this issue is independent of the new validation tests). We should
> figure out which core developers can contribute what.

Yes and I would welcome that.

> 
>>
>>> We just have to create a
>>> release branch for RTEMS 6 and reference release branch commits in the
>>> submodules.
>>
>> How do you validate the generated sources in the sub-modules match those in 
>> the
>> branched submodules? I think this should be done as part of the release
>> procedure to catch any mistakes.
> 
> I will write something about this in the release procedure documentation.

Thank you, I appreciate this. This is a big help.

Chris
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] cpukit: Add description of release version numbers

[Chris Johns]

On 29/1/22 2:36 am, Sebastian Huber wrote:
> On 28/01/2022 15:28, Christian MAUDERER wrote:
>> So I think at the moment, the engineering manual is wrong. The release branch
>> will always have the number N.0.0 as long as we don't change the release 
>> process.
> 
> I think the manual is right and the version on the RTEMS 5 release branch is
> wrong. It should be 5.1.1. Right after the 5.2.0 release it should be 5.2.1.

I will need to take a look and resolve this for an RTEMS 6 release.

A brief review, without examining the detail, would lead me to believe the
manual may need updating but I am not sure.

I think a unified method for controlling version numbers would be good.

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

Roadmap and communication of features planned for releases

[Jason Johns]

This came up via a query at Reddit 
https://reddit.com/r/django/comments/setc9n/official_roadmap/ and I wasn’t 
able to find anything other than what is already in the comments. That also 
made me curious and feel that more communication about planned features and 
changes could be useful.

Thanks!


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/27b5c12d-6473-4831-a635-47d01de55249n%40googlegroups.com.

Re: [PATCH] rtems-tools-6.cfg: Bump hash

[Chris Johns]

OK

On 28/1/22 12:48 am, Ryan Long wrote:
> ---
>  rtems/config/tools/rtems-tools-6.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-tools-6.cfg 
> b/rtems/config/tools/rtems-tools-6.cfg
> index d493955..f7a766e 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version 6736c738baee94a31ec4f8bc4484582eb7839556
> + %define rtems_tools_version 756897818360a6c110886fb5740303563c92f7a4
>   %define rtems_tools_ext bz2
>  %endif
>  
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools 
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
>  %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> - 
> DK6eZJJTXeO3g7PJrB+CsqUU/aYgb3/46MjUP8OqSLYTEOCStoIAm9NjHkWZCIPpJyqQIeEpX8Aerd3RfFiuYA==
> + 
> PBGJPJX2E9g3JCmaijG/FsyAokN/9mjAeEd8NzLejDE0TbVxEHuPpnrhKRkpUeYHi7ljG76OX61p3GgVD06vgg==
>  
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Chris Johns]

On 25/1/22 5:37 pm, Sebastian Huber wrote:
> On 25/01/2022 01:09, Chris Johns wrote:
>> On 25/1/22 1:39 am, Sebastian Huber wrote:
>>> how do we want to proceed with the integration of the new validation test 
>>> suite?
>>> At the moment it is not clear to me what issues are left to resolve and 
>>> what I
>>> can do to address them?
>>
>> I believe I have been clear about what I see as being needed:
>>
>> https://lists.rtems.org/pipermail/devel/2022-January/070323.html
> 
> Sorry, I don't know what I have to do next.

Sure and I am sorry if this was not clear.

> The release process for rtems-central is quite clear from my point of view. 

I would not have raised this if I was in the same position. You are the only
person I know who understand rtems-central. I only have an overview of it and I
I am sorry but I have no spare time in invest in learning more about it. I do
have the responsibility of releasing RTEMS and if I accept these changes without
any of the needed support in place history has taught me I am left to provide
it. Tools and scripts that shows how a process is to work would go a long long
way to resolving this issue.

The RTEMS Release repo is a series of FreeBSD scripts I use to release ...

https://git.rtems.org/rtems-release/

I have not touched it in a while and it needs work to change it to support waf.

> We just have to create a
> release branch for RTEMS 6 and reference release branch commits in the 
> submodules.

How do you validate the generated sources in the sub-modules match those in the
branched submodules? I think this should be done as part of the release
procedure to catch any mistakes.

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

Re: [RBW] Best grocery pannier? Nice lightweight wool cycling "jacket" or full-zip mid-weight jersey?

[JohnS]

About #2, found this nice Merino wool outer layer with rear pockets at 
Search & State (by way of Radavist). Not cheap at $215, but what wool 
garment is???

https://searchandstate.com/products/long-sleeve-merino-ranger/#

Good luck,
JohnS

On Saturday, January 22, 2022 at 4:32:09 PM UTC-5 Patrick Moore wrote:

> Joyce and Turnip: Thank you. Joyce, I see that the Seattle CL offer is 
> red, at least, as far as I can judge from my monitor and with my 
> color-vision-deprived eyes. If I were closer I might well grasp. Too bad 
> I', 1,500 miles away.
>
> In fact. I'm not in the market just now, but I may well be in the market 
> in a few months, and this Ortlieb shopping-specific design is the best I've 
> looked at; and apparently it comes in red, which I favor for the 
> Rivendel-esque* Sage Green frame it would be used on. 
>
> *The bike is the Matthews 2:1, but it's a Riv clone+ which also copies 
> pretty closely with its powdercoat the wonderful Sage Green (with 
> lovely Cream Accents) Joe Bell paint of the 2003 exemplar. The Sage Green 
> color is (*I* think) very well set off by red accents in bar tape and 
> panniers.
>
> + Copied angles and lengths, and the powdercoat is very similar tho' 
> without the cream accents; but saved from plagiarism and (one hopes) 
> obloquy because standard gauge / thinnish-wall 531, and narrow 118 mm OL to 
> accommodate both 114  and 120 OL hubs -- SA hub gear and fixed gear drive 
> wheels -- plus various odd housing stops for the SA shifter bits, and 
> oddball internal dyno-wire routing, weird custom rack attachments, etc etc.
>
>
>
> On Sat, Jan 22, 2022 at 1:09 PM JAS  wrote:
>
>> Patrick,
>> Here's an Ortlieb shopper I spotted this morning on the Seattle 
>> Craigslist:
>>
>> https://seattle.craigslist.org/see/bop/d/bellevue-ortlieb-waterproof-bike-basket/7436299979.html
>>
>> --Joyce
>> On Saturday, January 22, 2022 at 8:28:10 AM UTC-8 Patrick Moore wrote:
>>
>>> Thank you, Pat; this is the one. REI is out and I don't see it on other 
>>> sites, but I'll keep looking.
>>>
>>> On Sat, Jan 22, 2022 at 6:33 AM Pat Smith  wrote:
>>>
>>>> Love my ortlieb bike shopper. Much better than a back roller for 
>>>> groceries. It used to come in red. I've got one in red
>>>>
>>>> https://www.rei.com/product/885305/ortlieb-bike-shopper-pannier-single
>>>>
>>>> Pat in DC
>>>>
>>>> On Saturday, January 22, 2022 at 12:03:39 AM UTC-5 Patrick Moore wrote:
>>>>
>>>>> Thanks, Eric; and those come in red, too!
>>>>>
>>>>> I want something with a flap and something that can be adapted to an 
>>>>> Ortlieb or Arkle-type "clamp" mounting system and be offset to the rear 
>>>>> by 
>>>>> about 3". I've owned at least 2 different grocery panniers of this 
>>>>> design, 
>>>>> and they work well on smooth unobstructed routes, but I've lost one such 
>>>>> similar pannier when riding on a dirt road; either fell off on a bump, or 
>>>>> perhaps was scraped off when I went through some path entry barriers. 
>>>>> (Fortunately I had nothing particularly valuable in the pannier at the 
>>>>> time.)
>>>>>
>>>>> On Fri, Jan 21, 2022 at 9:22 AM Eric Marth  wrote:
>>>>>
>>>>>> Forgive me if these don't check all of your boxes, I don't have that 
>>>>>> much processing power. But check 'em out! 
>>>>>>
>>>>>> https://www.jandd.com/detail.asp?PRODUCT_ID=FGBP
>>>>>>
>>>>> -- 
>>>>
>>> You received this message because you are subscribed to the Google 
>>>> Groups "RBW Owners Bunch" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to rbw-owners-bun...@googlegroups.com.
>>>>
>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/rbw-owners-bunch/c77dfc7b-1bc3-4cd5-8be4-5fec2ed433a6n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/rbw-owners-bunch/c77dfc7b-1bc3-4cd5-8be4-5fec2ed433a6n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>>
>>> ---
>>> Patrick Moore
>>> Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
>>>
>>> -- 
>&

Re: New validation test suites

[Chris Johns]

On 25/1/22 1:39 am, Sebastian Huber wrote:
> how do we want to proceed with the integration of the new validation test 
> suite?
> At the moment it is not clear to me what issues are left to resolve and what I
> can do to address them?

I believe I have been clear about what I see as being needed:

https://lists.rtems.org/pipermail/devel/2022-January/070323.html

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

Re: [PATCH] rtems-tools-6.cfg: Bump hash to get new INI files

[Chris Johns]

On 21/1/22 1:32 am, Joel Sherrill wrote:
> This looks good to me. If no one objects, I will push it.

Ok to push. Thanks

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

Re: [PATCH] sb/linux.py: Simplify "distro" determination

[Chris Johns]

I do not use Linux enough to know if this is OK.

I have no problem with this being pushed if other Linux users are happy.

Chtis

On 20/1/22 11:03 pm, Sebastian Huber wrote:
> This fixes an issue on Debian 11 which contains "Debian" in /etc/issue
> (captital D).
> ---
>  source-builder/sb/linux.py | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/source-builder/sb/linux.py b/source-builder/sb/linux.py
> index d89377b..d71ac39 100644
> --- a/source-builder/sb/linux.py
> +++ b/source-builder/sb/linux.py
> @@ -76,20 +76,16 @@ def load():
>  except:
>  pass
>  
> +distro = distro.lower()
> +
>  # Manage distro aliases
>  if distro in ['centos']:
>  distro = 'redhat'
>  elif distro in ['fedora']:
>  if distro_ver < 17:
>  distro = 'redhat'
> -elif distro in ['centos', 'fedora']:
> -distro = 'redhat'
> -elif distro in ['Ubuntu', 'ubuntu', 'MX', 'LinuxMint', 'linuxmint']:
> +elif distro in ['ubuntu', 'mx', 'linuxmint']:
>  distro = 'debian'
> -elif distro in ['Arch']:
> -distro = 'arch'
> -elif distro in ['SuSE']:
> -distro = 'suse'
>  
>  variations = {
>  'debian' : { '__bzip2':('exe', 'required', '/bin/bzip2'),
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/5] rtems-bsp-builder Configuration Cleanup

[Chris Johns]

OK to push.

Thank you for taking the time to get this sorted.

Chris

On 22/1/22 2:26 am, Joel Sherrill wrote:
> As part of adding aarch64 BSPs to tier 1, it become obvious that
> these config files had not received attention lately. Multiple
> architectures and BSPs needed to be added. Some BSPs that had
> been removed needed to be removed here as well.
> 
> With the legacy TCP/IP stack no longer in rtems.git, it made 
> sense to eliminate the build variance on network. This will
> have a huge impact on the execution time of the build sweeps.
> 
> Build results for everything, tier-1, tier-2, and tier-3 are
> posted to build@.
> 
> Hopefully not controversial since it wasn't in the best shape
> when I started.
> 
> --joel
> 
> Joel Sherrill (5):
>   rtems-bsps-tiers.ini: Add missing architectures and BSPs as tier 3
>   rtems-bsps-tiers.ini: Update comment to use tier 2 definitiion in docs
>   rtems-bsps-arm.ini, config/rtems-bsps.ini: Remove build variance on
> network
>   rtems-bsps.ini: Add missing architectures and BSPs
>   rtems-bsps-tiers.ini: Move appropriate aarch64 BSPs to Tier 1 and 2
> 
>  config/rtems-bsps-arm.ini   |  1 -
>  config/rtems-bsps-tiers.ini | 36 ++--
>  config/rtems-bsps.ini   | 31 +--
>  3 files changed, 43 insertions(+), 25 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 1/2] microblaze: Add AXI Ethernet support

[Chris Johns]

On 21/1/22 8:18 am, Alex White wrote:
> On Thu, Jan 20, 2022 at 12:30 AM Chris Johns  wrote:
>>
>> On 20/1/22 2:54 pm, Alex White wrote:
>>> From: Jennifer Averett 
>>>  rtemsbsd/rtems/rtems-kernel-vmem.c|   17 +
>>> diff --git a/rtemsbsd/rtems/rtems-kernel-vmem.c 
>>> b/rtemsbsd/rtems/rtems-kernel-vmem.c
>>> index f64fbd17..70708902 100644
>>> --- a/rtemsbsd/rtems/rtems-kernel-vmem.c
>>> +++ b/rtemsbsd/rtems/rtems-kernel-vmem.c
>>> @@ -41,6 +41,11 @@
>>>
>>>  static MALLOC_DEFINE(M_VMEM, "vmem", "VMEM buffers");
>>>
>>> +int vmem_add(vmem_t *vm, vmem_addr_t addr, vmem_size_t size, int flags)
>>> +{
>>> + return 0;
>>> +}
>>> +
>>>  int
>>>  vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t *addrp)
>>>  {
>>> @@ -48,6 +53,18 @@ vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, 
>>> vmem_addr_t *addrp)
>>>   return 0;
>>>  }
>>>
>>> +static int dummy_vmem;
>>> +
>>> +vmem_t *vmem_create(const char *name, vmem_addr_t base,
>>> +vmem_size_t size, vmem_size_t quantum, vmem_size_t qcache_max, int 
>>> flags)
>>> +{
>>> + return _vmem;
>>> +}
>>> +
>>> +void vmem_destroy(vmem_t *vm)
>>> +{
>>> +}
>>> +
>>>  void
>>>  vmem_free(vmem_t *vm, vmem_addr_t addr, vmem_size_t size)
>>>  {
>>
>> What is pulling this interface in?
> 
> The added vmem functions are pulled in by freebsd/sys/dev/xdma/xdma.c

So how can it be an empty stub and the XDMA driver operate? Is the allocator
being called?

>>
>> Why have they been stubbed out?
> 
> They were stubbed out to provide the minimal implementation needed to get 
> xdma working, and xdma is ultimately used by the AXI Ethernet subsystem.
> 
> The alternatives we saw were to pull in the full FreeBSD vmem implementation 
> (overkill) or modify
> freebsd/sys/dev/xdma/xdma.c to not use vmem functions.

What sort of memory does this allocator allocate? Can some heap memory be used?

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

Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1

[Chris Johns]

On 20/1/22 9:04 am, Joel Sherrill wrote:
> On Wed, Jan 19, 2022 at 2:56 PM Chris Johns  wrote:
>>
>> On 20/1/22 5:08 am, Joel Sherrill wrote:
>>> Are the Tier 1 architectures/BSPs documented anywhere besides an INI file?
>>
>> I do not think they are.
> 
> Me either. I vaguely recall we have had this conversation before.
> 
> Where should they be? Sebastian says we have 5 now.

I am not sure. The user manual or a wiki page with a link in the user manual?

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

Re: [PATCH rtems-libbsd 1/2] microblaze: Add AXI Ethernet support

[Chris Johns]

On 20/1/22 2:54 pm, Alex White wrote:
> From: Jennifer Averett 
>  rtemsbsd/rtems/rtems-kernel-vmem.c|   17 +
> diff --git a/rtemsbsd/rtems/rtems-kernel-vmem.c 
> b/rtemsbsd/rtems/rtems-kernel-vmem.c
> index f64fbd17..70708902 100644
> --- a/rtemsbsd/rtems/rtems-kernel-vmem.c
> +++ b/rtemsbsd/rtems/rtems-kernel-vmem.c
> @@ -41,6 +41,11 @@
>  
>  static MALLOC_DEFINE(M_VMEM, "vmem", "VMEM buffers");
>  
> +int vmem_add(vmem_t *vm, vmem_addr_t addr, vmem_size_t size, int flags)
> +{
> + return 0;
> +}
> +
>  int
>  vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t *addrp)
>  {
> @@ -48,6 +53,18 @@ vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, 
> vmem_addr_t *addrp)
>   return 0;
>  }
>  
> +static int dummy_vmem;
> +
> +vmem_t *vmem_create(const char *name, vmem_addr_t base,
> +vmem_size_t size, vmem_size_t quantum, vmem_size_t qcache_max, int flags)
> +{
> + return _vmem;
> +}
> +
> +void vmem_destroy(vmem_t *vm)
> +{
> +}
> +
>  void
>  vmem_free(vmem_t *vm, vmem_addr_t addr, vmem_size_t size)
>  {

What is pulling this interface in?

Why have they been stubbed out?

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

Re: Older gcc for MacOS

[Chris Johns]

On 8/1/22 9:34 am, Joel Sherrill wrote:
> On Fri, Jan 7, 2022 at 4:17 PM Chris Johns  wrote:
>>
>> On 8/1/22 8:28 am, Ryan Long wrote:
>>> Hi,
>>>
>>> Our MacOS VM is failing to build several of the tools on the RTEMS 5 
>>> branch. We
>>> think that using an older version of gcc should get all of the tools to 
>>> build. I
>>> tried build gcc-4.8 with the RSB, but I get the following error.
>>>
>>>
>>> tester@VM-MacOS bare % ../source-builder/sb-set-builder
>>> --prefix=${HOME}/rtems-cron-5/tools/gcc-48 gnu-tools-4.8.2
>>> RTEMS Source Builder - Set Builder, 5 (6225eadda1de modified)
>>> Build Set: gnu-tools-4.8.2
>>> error: gnu-tools-4.8.2:24: cannot find file: devel/gcc-4.8.2-newlib-cvs-1
>>> Build Set: Time 0:00:00.000607
>>> Build FAILED
>>>
>>>
>>> Does anyone know how to get these tools to build?
>>>
>>
>> It looks like the recipe has rotted.
> 
> Was there a native gcc recipe? The name includes newlib which would
> imply it is intended for use with RTEMS.

The `bare/config` tree had recipes to build bare metal tool chains.

> Also clearly old with cvs in the name.
> 
> Having the ability to build an older gcc would ease the burden of
> using 5 on newer FreeBSD, Linux, etc with stricter compilers. As
> with everything, doing it with the RSB gives us control.

Yes but do we want to head down that path?

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

Re: [PATCH 0/5] Update rtems-bsp-builder to match RTEMS master

[Chris Johns]

Looks great and thank you for taking care of this.

Chris

On 20/1/22 5:04 am, Joel Sherrill wrote:
> The set of ini files for rtems-bsp-builder was out of sync
> with the set of architectures and BSPs currently in RTEMS.
> This patch set adds three architectures and a handful of BSPs.
> 
> Build results with these patches are at:
> 
> https://lists.rtems.org/pipermail/build/2022-January/031032.html
> 
> --joel
> 
> Joel Sherrill (5):
>   rtems-bsps-arm.ini: Add missing BSPs
>   rtems-bsps-riscv.ini: Add missing BSPs
>   rtems-bsps-aarch64.ini: New file
>   rtems-bsps-microblaze.ini: New file
>   rtems-bsps-x86_64.ini: New file
> 
>  config/rtems-bsps-aarch64.ini| 31 +++
>  config/rtems-bsps-arm.ini| 16 +---
>  config/rtems-bsps-microblaze.ini | 25 +
>  config/rtems-bsps-riscv.ini  |  4 +++-
>  config/rtems-bsps-x86_64.ini | 25 +
>  5 files changed, 97 insertions(+), 4 deletions(-)
>  create mode 100644 config/rtems-bsps-aarch64.ini
>  create mode 100644 config/rtems-bsps-microblaze.ini
>  create mode 100644 config/rtems-bsps-x86_64.ini
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1

[Chris Johns]

On 20/1/22 5:08 am, Joel Sherrill wrote:
> Are the Tier 1 architectures/BSPs documented anywhere besides an INI file?

I do not think they are.

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

[RBW] Re: WTB: Nitto wire guard

[JohnS]

Hello Jamin,

You may want to do a search on this guard. As I recall at least one group 
member wasn't very happy with it.

Regards,
JohnS


On Tuesday, January 18, 2022 at 11:42:56 PM UTC-5 jamin orrall wrote:

> Looking for a Nitto wire guard, I have attached a photo.  They seem to be 
> out of stock except for international dealers.  Would rather a tiny piece 
> of wire not have to travel so far.  Anyone have one in the US? I'm in Los 
> Angeles.
>
> Thanks
> Jamin
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/0790b5e3-76d4-44f1-bc49-7ec2bd0c9bf4n%40googlegroups.com.

Re: [PATCH rtems-tools] rtems-bsps-powerpc.ini: Remove powerpc/halekala

[Chris Johns]

OK

Thanks
Chris

On 19/1/22 5:17 am, Joel Sherrill wrote:
> Updates #4302.
> ---
>  config/rtems-bsps-powerpc.ini | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/config/rtems-bsps-powerpc.ini b/config/rtems-bsps-powerpc.ini
> index b4dc02c..fc69827 100644
> --- a/config/rtems-bsps-powerpc.ini
> +++ b/config/rtems-bsps-powerpc.ini
> @@ -24,7 +24,6 @@
>  bsps = beatnik,
> br_uid,
> gwlcfm,
> -   haleakala,
> hsc_cm01,
> icecube,
> mcp750,
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1

[Chris Johns]

Ok to push.

Thank you
Chris

On 19/1/22 3:19 am, Kinsey Moore wrote:
> Hardware test results have recently been posted for AArch64.
> 
> Closes #4581
> ---
>  config/rtems-bsps-tiers.ini | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/config/rtems-bsps-tiers.ini b/config/rtems-bsps-tiers.ini
> index 875c5df..ba9e6b5 100644
> --- a/config/rtems-bsps-tiers.ini
> +++ b/config/rtems-bsps-tiers.ini
> @@ -21,10 +21,11 @@
>  # Tier 1: no build errors and no unexpected tests failures on hardware.
>  #
>  [tier-1]
> -archs = arm, i386, powerpc
> +archs = arm, i386, powerpc, aarch64
>  bsps_arm = beagleboneblack, imx7, xilinx_zynq_zedboard
>  bsps_i386 = pc686
>  bsps_powerpc = qoriq_e500
> +bsps_aarch64 = xilinx_zynqmp_lp64_zu3eg, xilinx_zynqmp_ilp32_zu3eg
>  
>  #
>  # Tier 2: no build errors and no unexpected tests failures on hardware and
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Chris Johns]

On 17/1/22 8:51 pm, Sebastian Huber wrote:
> On 17/01/2022 09:47, Chris Johns wrote:
>> On 17/1/22 7:04 pm, Sebastian Huber wrote:
>>> On 17/01/2022 08:52, Chris Johns wrote:
>>>> My understanding of the status of these patches is the remaining topic is 
>>>> the
>>>> release dependencies. I have not had time to give this any consideration
>>>> however
>>>> I have a feeling it will not be easy or simple because of the 
>>>> inter-dependency
>>>> of the repos and sub-module relationship. I hope I am wrong about this.
>>>
>>> In order to work with the generated test programs you have to use the
>>> specification items which are in rtems-central.  Most of the validation 
>>> tests
>>> are defined through transitions from pre-conditions to post-conditions. 
>>> Working
>>> directly with the generated sources is too complicated. I don't know what
>>> complicates a release here, the rtems-central is just another repository 
>>> which
>>> needs a release branch. In the release branch, the submodules track the
>>> corresponding release branch of the referenced repository.
>>
>> A release has tarballs of sources and not git repos so I am not sure how
>> branches help? How does the submodules in rtems-central get captured? The
>> current release scripts expand sub-modules which means they need to 
>> reconcile or
>> we will have different copies of the code in the release.
>>
>> At the point of release how does the release manager know the rtems-central
>> scripts match the generated sources in the down stream repos that are 
>> released?
> 
> The rtems-central contains nothing relevant to an user of RTEMS. There is no
> need to provide a release archive. The purpose of the branch is the 
> maintenance
> of an RTEMS release branch.

This thread indicates my position about releases needing to be solved to move
forwards. This patch set is the first export from rtems-central that we cannot
maintain outside of rtems-central. It has been a requirement of the qual effort
that we can cleanly separate the two parts and accepting these patches changes
that. I still have real reservations about that happening.

>>> Please note, that the RTEMS sources used by rtems-central are currently not
>>> one-to-one a commit of the RTEMS master branch. There are about 90 
>>> additional
>>> patches. The patch set with the new validation sets is a part of it.
>>
>> Which is a concern and why a release needs to check and make sure everything 
>> is
>> in sync.
>>
>> Ideally the rtems-central submodule hashes match the release tarball sources 
>> for
>> each repo. This is the task as I see it.
>>
>> I am sure this can be resolved and I prefer it happens before being pushed 
>> so it
>> is not left as a task for the release manager.
> 
> The only way to reduce the gap between the RTEMS version referenced by
> rtems-central and the RTEMS master is to integrate patch sets step by step. 
> Some
> patch sets are specific to the sparc/leon3 BSPs and the build system. 

If rtems.git is a submodule where are the changes being held?

And please understand, I think these tests are important and I would like to see
them merged.

> I am not sure if this should delay the RTEMS 6 release.

You could be right, I am not sure. I am still digging myself out of a pile of
things.

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

[RBW] Re: Velotaxonomy: What are we, anyway?

[JohnS]

Plus 1 for the Meetup app (meetup.com), great way to find like minded 
cyclists in your area. My local bike club uses it to post all of its rides 
from rail to trail rides (flat, 12-14 mph pace) to near race pace roadies 
(18-20 mph with hills), and everything in between.

Good Luck!
JohnS

On Monday, January 17, 2022 at 12:57:42 PM UTC-5 Ian A wrote:

> You might be able to find a MeetUp Group or Touring Cyclist  style group , 
> neither tend to be competitive. Randonneur clubs often have a Populaire 
> which is typically a full day style 100km (60mile) ride and every type of 
> rider shows up to those, even parent/child tandem riders and it is a lot of 
> fun.
>
> If there is no MeetUp Group on your area or nothing that is what you are 
> looking for, there is an opportunity to start one and see how it goes. When 
> I lived in Vancouver, I started group riding with a MeetUp Group on 
> Saturdays and it was fun for a while. Then I found the BC Randonneurs and 
> that was fantastic until I rode off to Tierra del Fuego. Distance riding 
> got under my skin!
>
> IanA (back north in) Alberta Canada 
>
> On Monday, January 17, 2022 at 7:31:09 AM UTC-7 Bicycle Belle Ding Ding! 
> wrote:
>
>> [image: 0168267B-AB4E-4252-B2D2-09FC827BCB73.jpeg]We recently moved to 
>> SW Michigan. I was a total Lone Wolf (borrowing from Eben Weiss, The Bike 
>> Snob) in Vegas but I dream of having Real Life Bike Friends here. This List 
>> has really been a gift to me, but it has also made me want more: I want 
>>  REAL people and REAL experiences with them. I have found a shop that hosts 
>> rides of various kinds 9 months out of the year. There is hope!
>>
>> The trouble is: I don’t know what I am, and neither does anyone else. 
>>
>> I have never done a group ride. I don’t know how fast or slow I am, and I 
>> don’t know how far I can go. I don’t know etiquette or what would tick off 
>> other riders in the group. (My “group rides” were with my 2 sons on the way 
>> to school. And it’s true that you learn a rhythm that works for your group 
>> and on the rare occasion my husband got included, he made us all nervous.) 
>> I would like to have a good first experience and not be a drag for a group. 
>> I think failure would send me right back into Lone Wolfdom. I suppose I 
>> will just have to risk it.
>>
>> When I say I ride, everyone thinks Roadie, and then they think of their 
>> friend who is also a Roadie and want to plan a meeting for us. Now, I doubt 
>> I’m going to keep up with a group of road bikes on my Platypus. When I say 
>> I don’t have a road bike, the person will say, “Oh, you like to mountain 
>> bike!” When I try to explain, try to say what it is that I ride, I don’t 
>> have words. If I admit I don’t have a road bike or mountain bike people 
>> assume hybrid bike from big box store = not a serious rider. I don’t know 
>> what I am. I don’t know what “we” are. Where do bikes like ours fit? Who do 
>> we ride with?
>>
>> In looking at local events online, it seems there are Roadies and there 
>> are Gravel Kings (my own term). If I roll up on my fendered, raspberry 
>> sparkle Platypus, both groups will be uncomfortable. 
>>
>> My shop did mention some community rides, and those I will try, though I 
>> suspect they might be short and slow for my taste. There are some very 
>> exciting events state-wide here, but they do seem to be geared to road 
>> bikers. I admit that I know very little about bike culture here, and 
>> talking to real people might open up a lot of possibilities. Where are 
>> these people I can talk to?!
>>
>> The locals tell me spring will be here in March. I’ve got 2 months to 
>> figure out where I fit, Rivsters. 
>>
>> Who can relate? Who has words of wisdom? Who just wants to commiserate? 
>> Are we the outcasts of bike culture or are we unicorns? Where are we in the 
>> Velotaxonomy? How do we make the cool people take us seriously? Should I 
>> buy Lycra? 
>>
>> What I wouldn’t give for a couple of RivSisters living locally…
>> Leah
>>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/c6ab683b-4585-4759-91a6-2bfe1b29517cn%40googlegroups.com.

Re: New validation test suites

[Chris Johns]

On 17/1/22 7:04 pm, Sebastian Huber wrote:
> On 17/01/2022 08:52, Chris Johns wrote:
>> My understanding of the status of these patches is the remaining topic is the
>> release dependencies. I have not had time to give this any consideration 
>> however
>> I have a feeling it will not be easy or simple because of the 
>> inter-dependency
>> of the repos and sub-module relationship. I hope I am wrong about this.
> 
> In order to work with the generated test programs you have to use the
> specification items which are in rtems-central.  Most of the validation tests
> are defined through transitions from pre-conditions to post-conditions. 
> Working
> directly with the generated sources is too complicated. I don't know what
> complicates a release here, the rtems-central is just another repository which
> needs a release branch. In the release branch, the submodules track the
> corresponding release branch of the referenced repository.

A release has tarballs of sources and not git repos so I am not sure how
branches help? How does the submodules in rtems-central get captured? The
current release scripts expand sub-modules which means they need to reconcile or
we will have different copies of the code in the release.

At the point of release how does the release manager know the rtems-central
scripts match the generated sources in the down stream repos that are released?

> Please note, that the RTEMS sources used by rtems-central are currently not
> one-to-one a commit of the RTEMS master branch. There are about 90 additional
> patches. The patch set with the new validation sets is a part of it.

Which is a concern and why a release needs to check and make sure everything is
in sync.

Ideally the rtems-central submodule hashes match the release tarball sources for
each repo. This is the task as I see it.

I am sure this can be resolved and I prefer it happens before being pushed so it
is not left as a task for the release manager.

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

Re: New validation test suites

[Chris Johns]

On 15/1/22 2:02 am, Sebastian Huber wrote:
> On 11/01/2022 17:09, Sebastian Huber wrote:
>>
>> I will do a test run on a arm/imx7 board tomorrow. The new validation tests
>> already passed some time ago on this board.
> 
> Running the complete new validation test suite revealed a bug in the arm
> interrupt handling:

Nice.

> https://devel.rtems.org/ticket/4579
> 
> With the proposed fix I get now the following results for the arm/imx7 BSP on 
> a
> TQMa7x module
> (https://www.tq-group.com/en/products/tq-embedded/arm-architecture/tqma7x/):
> 
> Passed:    674
> Failed:  2
> User Input:  6
> Expected Fail:   0
> Indeterminate:   0
> Benchmark:   3
> Timeout: 0
> Test too long:   0
> Invalid: 0
> Wrong Version:   0
> Wrong Build: 0
> Wrong Tools: 0
> Wrong Header:    0
> --
> Total: 685
> Failures:
>  dl06.exe.img
>  minimum.exe.img
> User Input:
>  dl10.exe.img
>  termios.exe.img
>  fileio.exe.img
>  monitor.exe.img
>  top.exe.img
>  capture.exe.img
> Benchmark:
>  dhrystone.exe.img
>  linpack.exe.img
>  whetstone.exe.img
> Average test time: 0:00:09.704139
> Testing time : 1:50:47.335244
> 
> The dl06 failure is expected, I will update the build configuration 
> accordingly.
> 

Thanks

My understanding of the status of these patches is the remaining topic is the
release dependencies. I have not had time to give this any consideration however
I have a feeling it will not be easy or simple because of the inter-dependency
of the repos and sub-module relationship. I hope I am wrong about this.

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

Re: Older gcc for MacOS

[Chris Johns]

On 8/1/22 8:28 am, Ryan Long wrote:
> Hi,
> 
> Our MacOS VM is failing to build several of the tools on the RTEMS 5 branch. 
> We
> think that using an older version of gcc should get all of the tools to 
> build. I
> tried build gcc-4.8 with the RSB, but I get the following error.
> 
> 
> tester@VM-MacOS bare % ../source-builder/sb-set-builder
> --prefix=${HOME}/rtems-cron-5/tools/gcc-48 gnu-tools-4.8.2
> RTEMS Source Builder - Set Builder, 5 (6225eadda1de modified)
> Build Set: gnu-tools-4.8.2
> error: gnu-tools-4.8.2:24: cannot find file: devel/gcc-4.8.2-newlib-cvs-1
> Build Set: Time 0:00:00.000607
> Build FAILED
> 
> 
> Does anyone know how to get these tools to build?
> 

It looks like the recipe has rotted.

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

Re: [PATCH 1/2] microblaze: Add support for libbsd.

[Chris Johns]

On 5/1/22 5:10 am, Alex White wrote:
> From: Jennifer Averett 
> 
> ---
>  .../microblaze_fpga/dts/microblaze-dtb.c  | 962 ++
>  .../microblaze/microblaze_fpga/dts/system.dts | 452 
>  bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c |  21 +
>  bsps/microblaze/microblaze_fpga/include/bsp.h |   4 +
>  .../bsps/microblaze/microblaze_fpga/obj.yml   |   2 +
>  5 files changed, 1441 insertions(+)
>  create mode 100644 bsps/microblaze/microblaze_fpga/dts/microblaze-dtb.c
>  create mode 100644 bsps/microblaze/microblaze_fpga/dts/system.dts
>  create mode 100644 bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c

How does a user with an FPGA microblaze implementation provide there own FDT? I
see the clock speed is a setting.

Is there a means to add such support available?

I am OK with a specific implementation keyed into a specific BSP being in our
source but that must be limited to a specific piece of hardware and FPGA is too
general given this is a soft processor. I think there needs to a workflow that
allows users to customize these settings for their own build.

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

Re: [PATCH 0/2] microblaze: libbsd support

[Chris Johns]

Which repo is this for?

On 5/1/22 5:10 am, Alex White wrote:
> This patch set adds support for libbsd to the MicroBlaze BSPs and contains 
> fixes
> for issues found while debugging the rtems-libbsd telnetd01 test in QEMU and 
> on
> the Xilinx KCU105 board.
> 
> Alex White (1):
>   microblaze: Add support for libbsd networking
> 
> Jennifer Averett (1):
>   microblaze: Add support for libbsd.
> 
>  .../microblaze_fpga/dts/microblaze-dtb.c  | 963 ++
>  .../microblaze/microblaze_fpga/dts/system.dts | 452 
>  bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c |  22 +
>  bsps/microblaze/microblaze_fpga/include/bsp.h |   9 +
>  bsps/microblaze/microblaze_fpga/irq/irq.c |   2 +-
>  .../microblaze_fpga/start/bspstart.c  |   6 +
>  .../start/microblaze_enable_dcache.S  |  20 +
>  .../start/microblaze_enable_icache.S  |  20 +
>  .../start/microblaze_invalidate_dcache.S  |  29 +
>  .../start/microblaze_invalidate_icache.S  |  28 +
>  cpukit/score/cpu/microblaze/cpu.c |   1 -
>  cpukit/score/cpu/microblaze/cpu_asm.S |   4 +-
>  .../bsps/microblaze/microblaze_fpga/grp.yml   |  12 +
>  .../bsps/microblaze/microblaze_fpga/obj.yml   |   6 +
>  .../microblaze_fpga/optdcachebaseaddress.yml  |  18 +
>  .../microblaze_fpga/optdcachelinelen.yml  |  17 +
>  .../microblaze_fpga/optdcachesize.yml |  17 +
>  .../microblaze_fpga/opticachebaseaddress.yml  |  18 +
>  .../microblaze_fpga/opticachelinelen.yml  |  17 +
>  .../microblaze_fpga/opticachesize.yml |  17 +
>  20 files changed, 1673 insertions(+), 5 deletions(-)
>  create mode 100644 bsps/microblaze/microblaze_fpga/dts/microblaze-dtb.c
>  create mode 100644 bsps/microblaze/microblaze_fpga/dts/system.dts
>  create mode 100644 bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c
>  create mode 100644 
> bsps/microblaze/microblaze_fpga/start/microblaze_enable_dcache.S
>  create mode 100644 
> bsps/microblaze/microblaze_fpga/start/microblaze_enable_icache.S
>  create mode 100644 
> bsps/microblaze/microblaze_fpga/start/microblaze_invalidate_dcache.S
>  create mode 100644 
> bsps/microblaze/microblaze_fpga/start/microblaze_invalidate_icache.S
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optdcachebaseaddress.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optdcachelinelen.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optdcachesize.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/opticachebaseaddress.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/opticachelinelen.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/opticachesize.yml
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RBW] Re: Saddle Recommendation Requested

[JohnS]

I had bought a Velo Voam Breeze saddle for a Hawthorne step thru that I had 
built for my wife but ended up giving it to my my hairstylist. She seems to 
like it. Unfortunately that model is on back order at the few sites that I 
checked. Seems to be the recurring problem with bike parts these days.

https://www.treefortbikes.com/Velo-Voam-Breeze-Saddle

Good luck,
JohnS


On Thursday, December 30, 2021 at 12:38:18 PM UTC-5 Elisabeth Sherwood 
wrote:

> p.s.  Went to Trek's website and this is the one we got for my mother's 
> bike: 
>
>
> https://www.trekbikes.com/us/en_US/equipment/cycling-components/bike-saddles/fitness-bike-saddles/bontrager-commuter-comp-bike-saddle/p/21588/?colorCode=black
>
> And this one seems similar; a little narrower, and a little cheaper: 
>
>
> https://www.trekbikes.com/us/en_US/equipment/cycling-components/bike-saddles/fitness-bike-saddles/bontrager-sport-bike-saddle/p/14011/?colorCode=black
>
> Liz
>
>
>
> On Thursday, December 30, 2021 at 9:30:44 AM UTC-8 Elisabeth Sherwood 
> wrote:
>
>> Hi George,
>>
>> A couple years ago my mother bought a Trek 7100 or similar (step-through 
>> upright/comfort hybrid). I didn't really think anything of it (positive or 
>> negative), other than, oh, that's a decent upright/comfort hybrid for her 
>> that she can ride around the neighborhood. 
>>
>> And then one day I tried to ride it. I nearly died. It came/comes with a 
>> very short, very "puffy" saddle (although not soft -- you don't really sink 
>> down on the saddle), with very short rails.  So it pushes the rider quite 
>> forward, toward the bars, and then puts weight on the rider's hands/arms.  
>> And because it's so darn short, with short rails, there's nothing you can 
>> do about it. You can't move it, or you, backwards to get the weight off 
>> your arms.
>>
>> Anyway, went to the local Trek store (that's all there is here) and found 
>> a relatively wide saddle with longer rails. It's from Bontrager, but don't 
>> know what model (but it wasn't expensive).  It's actually quite wide -- 
>> it's probably 168mm at the widest part of the saddle -- and it's not at all 
>> "puffy", but it's really quite comfortable to ride.  (It has a center 
>> cut-out, but given the riding position it doesn't seem necessary!) My 
>> mother loves riding her bike now.  (And I can ride it and not think, "good 
>> lord! What sadist designed this bicycle??")
>>
>> So, that's my advice -- find something kind of standard but wide enough 
>> to sit *on*, with long enough rails to move the saddle back and forth. 
>>
>> Good luck!
>>
>> Liz Sherwood
>> Washington, DC (thought currently in the Palm Springs area, where my 
>> mother's bike is... :-) )
>>
>> On Thursday, December 30, 2021 at 7:41:06 AM UTC-8 George Schick wrote:
>>
>>> Over the past several weeks I've been overhauling a bike that belongs to 
>>> a lady who can't afford much.  It's a Huffy Broadmoor so nothing fancy. 
>>>  Anyway, I've been talking to her about changing saddles.  This bike has a 
>>> step-through frame pretty much on the order of some of the Riv bikes like 
>>> the Platy and it is equipped with run-of-the-mill bars, which means that 
>>> she's riding in an upright position.  So she has one of those thick, 
>>> heavily padded, wide, wide saddles that looks like someone cut it out of a 
>>> mattress.  I have convinced her to look for something more suitable for 
>>> efficient pedaling (she's apparently been riding around in the highest gear 
>>> - 80 inch - at what must be a very low cadence).
>>>
>>> So...what are some of you who ride Riv bikes that have been introduced 
>>> in recent years that encourage an upright riding style using for a saddle? 
>>>  Seems like some of the pics I've seen on this blog show bikes equipped 
>>> with narrower leather models.  Not sure if she'll be amenable to those, but 
>>> any input is welcome.  I've also talked to her about "sits" bone width and 
>>> measurements she's taken seem to indicate that their around the 110-115mm 
>>> range.
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/adf9a527-9652-41c6-b7d7-f5bd02ee45a3n%40googlegroups.com.

[RBW] Re: WTB/WTT: Paul Racer Silver (for black)

[JohnS]

Brakes are sold. 

Happy Holidays Everyone!

JohnS


On Wednesday, December 22, 2021 at 2:51:36 PM UTC-5 Dorothy C wrote:

> The original Paul Racers, not the medium are discontinued, it seems
>
> On Wednesday, December 22, 2021 at 11:04:13 AM UTC-8 JohnS wrote:
>
>> Hello Sean and Ryan, apparently Paul Racers are a rare commodity since 
>> two other people replied off list for them as well. So that would mean Sean 
>> is 4th and Ryan is 5th in line. Sorry.
>>
>> JohnS
>>
>> On Tuesday, December 21, 2021 at 9:38:43 PM UTC-5 Abcyclehank wrote:
>>
>>> I will get behind the original poster and Sean B. .
>>>
>>> Ryan Hankinson
>>> (616)929-4226 <(616)%20929-4226>
>>>
>>> On Tuesday, December 21, 2021 at 2:14:24 PM UTC-5 JohnS wrote:
>>>
>>>> Hello Taylor,
>>>>
>>>> I have a pair of Racers in silver that I would like to sell. I was 
>>>> planning to convert my Surly Pacer to 650B, but I didn't like the look or 
>>>> ride, so I gave up on it. So the brakes are nearly new, only rode around 
>>>> the block with them. The reach is too long for the Pacer, so I may as well 
>>>> sell them to someone who can use them. I'll PM you with the details and 
>>>> pics later today.
>>>>
>>>> JohnS
>>>>
>>>> On Tuesday, December 21, 2021 at 11:31:45 AM UTC-5 lconley wrote:
>>>>
>>>>> The panda look requires you to mix the black and silver parts between 
>>>>> the brakes, I believe.
>>>>>
>>>>> Laing
>>>>>
>>>>> On Tuesday, December 21, 2021 at 11:20:02 AM UTC-5 Taylor M wrote:
>>>>>
>>>>>> I have an incoming A Homer Hilsen and a set of mismatched Paul Racer 
>>>>>> brakes, one black (front) and one brushed silver (rear). Anyone have a 
>>>>>> silver front Racer brake to sell or trade for a black one? Also happy to 
>>>>>> buy a complete set if that's preferrable.
>>>>>>
>>>>>> If not, the panda look is cool now, right...?
>>>>>>
>>>>>> Thanks!
>>>>>> T
>>>>>>
>>>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/19e9cd57-7294-41c9-9210-7e54ebc1a056n%40googlegroups.com.

[RBW] Re: WTB/WTT: Paul Racer Silver (for black)

[JohnS]

Hello Sean and Ryan, apparently Paul Racers are a rare commodity since two 
other people replied off list for them as well. So that would mean Sean is 
4th and Ryan is 5th in line. Sorry.

JohnS

On Tuesday, December 21, 2021 at 9:38:43 PM UTC-5 Abcyclehank wrote:

> I will get behind the original poster and Sean B. .
>
> Ryan Hankinson
> (616)929-4226 <(616)%20929-4226>
>
> On Tuesday, December 21, 2021 at 2:14:24 PM UTC-5 JohnS wrote:
>
>> Hello Taylor,
>>
>> I have a pair of Racers in silver that I would like to sell. I was 
>> planning to convert my Surly Pacer to 650B, but I didn't like the look or 
>> ride, so I gave up on it. So the brakes are nearly new, only rode around 
>> the block with them. The reach is too long for the Pacer, so I may as well 
>> sell them to someone who can use them. I'll PM you with the details and 
>> pics later today.
>>
>> JohnS
>>
>> On Tuesday, December 21, 2021 at 11:31:45 AM UTC-5 lconley wrote:
>>
>>> The panda look requires you to mix the black and silver parts between 
>>> the brakes, I believe.
>>>
>>> Laing
>>>
>>> On Tuesday, December 21, 2021 at 11:20:02 AM UTC-5 Taylor M wrote:
>>>
>>>> I have an incoming A Homer Hilsen and a set of mismatched Paul Racer 
>>>> brakes, one black (front) and one brushed silver (rear). Anyone have a 
>>>> silver front Racer brake to sell or trade for a black one? Also happy to 
>>>> buy a complete set if that's preferrable.
>>>>
>>>> If not, the panda look is cool now, right...?
>>>>
>>>> Thanks!
>>>> T
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/744deea7-9a51-44cc-9aa2-a78d5709eca3n%40googlegroups.com.

Re: Alternative download paths for RSB?

[Chris Johns]

On 22/12/21 6:37 am, Joel Sherrill wrote:
> On Tue, Dec 21, 2021, 12:45 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> > How can we ensure that all mirrors listed work?
> 
> They would need to be tested and that means more code in the RSB to do it.
> 
> And another thing to check. Worries me.

Yes. What about fetching all the packages on each git commit to a spot on our
ftp server the RSB checks? The hashes will make sure things are OK to use and it
will avoid download when is present.

Chris


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

Re: [PATCH v2] ReportsBase: Change raw pointer to unique_ptr

[Chris Johns]

OK

Thanks
Chris

On 22/12/21 7:49 am, Ryan Long wrote:
> Replaced raw pointer used with ReportsBase-derived classes to make code
> cleaner and make it to where pointers do not have to be manually
> deleted.
> 
> Closes #4376
> ---
>  tester/covoar/ReportsBase.cc | 77 
> +---
>  1 file changed, 36 insertions(+), 41 deletions(-)
> 
> diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> index 219e5af..0fb9ce0 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -591,80 +591,75 @@ void GenerateReports(
>boolbranchInfoAvailable
>  )
>  {
> -  typedef std::list reportList_t;
> +  using reportList_ptr = std::unique_ptr;
> +  using reportList = std::vector;
>  
> -  reportList_t   reportList;
> -  reportList_t::iterator ritr;
> +  reportList reports;
>std::stringreportName;
> -  ReportsBase*   reports;
>time_t timestamp;
>  
>  
>timestamp = time( NULL ); /* get current cal time */
> -  reports = new ReportsText(
> -timestamp,
> -symbolSetName,
> -allExplanations,
> -projectName,
> -outputDirectory,
> -symbolsToAnalyze,
> -branchInfoAvailable
> +  reports.emplace_back(
> +new ReportsText(
> +  timestamp,
> +  symbolSetName,
> +  allExplanations,
> +  projectName,
> +  outputDirectory,
> +  symbolsToAnalyze,
> +  branchInfoAvailable
> +)
>);
> -  reportList.push_back( reports );
> -  reports = new ReportsHtml(
> -timestamp,
> -symbolSetName,
> -allExplanations,
> -projectName,
> -outputDirectory,
> -symbolsToAnalyze,
> -branchInfoAvailable
> +  reports.emplace_back(
> +new ReportsHtml(
> +  timestamp,
> +  symbolSetName,
> +  allExplanations,
> +  projectName,
> +  outputDirectory,
> +  symbolsToAnalyze,
> +  branchInfoAvailable
> +)
>);
> -  reportList.push_back( reports );
>  
> -  for ( ritr = reportList.begin(); ritr != reportList.end(); ritr++ ) {
> -reports = *ritr;
> +  for ( auto& report: reports ) {
>  
> -reportName = "index" + reports->ReportExtension();
> +reportName = "index" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteIndex( reportName );
> +report->WriteIndex( reportName );
>  
> -reportName = "annotated" + reports->ReportExtension();
> +reportName = "annotated" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteAnnotatedReport( reportName );
> +report->WriteAnnotatedReport( reportName );
>  
> -reportName = "branch" + reports->ReportExtension();
> +reportName = "branch" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteBranchReport( reportName );
> +report->WriteBranchReport( reportName );
>  
> -reportName = "uncovered" + reports->ReportExtension();
> +reportName = "uncovered" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteCoverageReport( reportName );
> +report->WriteCoverageReport( reportName );
>  
> -reportName = "sizes" + reports->ReportExtension();
> +reportName = "sizes" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteSizeReport( reportName );
> +report->WriteSizeReport( reportName );
>  
> -reportName = "symbolSummary" + reports->ReportExtension();
> +reportName = "symbolSummary" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteSymbolSummaryReport( reportName, symbolsToAnalyze );
> -  }
> -
> -  for ( ritr = reportList.begin(); ritr != reportList.end(); ritr++ ) {
> -reports = *ritr;
> -delete reports;
> +report->WriteSymbolSummaryReport( reportName, symbolsToAnalyze );
>}
>  
>ReportsBase::WriteSummaryReport(
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RBW] Re: WTB/WTT: Paul Racer Silver (for black)

[JohnS]

Hello Taylor,

I have a pair of Racers in silver that I would like to sell. I was planning 
to convert my Surly Pacer to 650B, but I didn't like the look or ride, so I 
gave up on it. So the brakes are nearly new, only rode around the block 
with them. The reach is too long for the Pacer, so I may as well sell them 
to someone who can use them. I'll PM you with the details and pics later 
today.

JohnS

On Tuesday, December 21, 2021 at 11:31:45 AM UTC-5 lconley wrote:

> The panda look requires you to mix the black and silver parts between the 
> brakes, I believe.
>
> Laing
>
> On Tuesday, December 21, 2021 at 11:20:02 AM UTC-5 Taylor M wrote:
>
>> I have an incoming A Homer Hilsen and a set of mismatched Paul Racer 
>> brakes, one black (front) and one brushed silver (rear). Anyone have a 
>> silver front Racer brake to sell or trade for a black one? Also happy to 
>> buy a complete set if that's preferrable.
>>
>> If not, the panda look is cool now, right...?
>>
>> Thanks!
>> T
>>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/09950834-5cba-4b8b-8b44-1f1901ce6340n%40googlegroups.com.

Re: Alternative download paths for RSB?

[Chris Johns]

On 22/12/21 1:45 am, Joel Sherrill wrote:
> On Tue, Dec 21, 2021 at 12:33 AM Sebastian Huber
>  wrote:
>>
>> On 20/12/2021 22:52, Chris Johns wrote:
>>> On 21/12/21 2:33 am, Joel Sherrill wrote:
>>>> On Mon, Dec 20, 2021 at 8:54 AM Joel Sherrill  wrote:
>>>>>
>>>>> On Mon, Dec 20, 2021 at 6:59 AM Sebastian Huber
>>>>>  wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> it seems the GNU web server is down:
>>>>>
>>>>> Yep. Still down.
>>>>>
>>>>> i reached out to the sourceware admins to see if they knew who to
>>>>> contact. I couldn't find a gnu.org address.
>>>>
>>>> Social media post from FSF forwarded by one of the sourceware admins
>>>> about a general outage at the FSF:
>>>> https://hostux.social/@fsfstatus/107479476196064925
>>>>
>>>> Looks to be up now. RSB handling mirrors would be good. Although
>>>> it would seem to be complex to ensure that all entries and mirrors are
>>>> correct.
>>>>
>>>>>
>>>>>>
>>>>>> download: https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2 ->
>>>>>> sources/mpfr-3.1.4.tar.bz2
>>>>>> download: https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: error:
>>>>>> 
>>>>>> error: downloading https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: all
>>>>>> paths have failed, giving up
>>>>>> Build FAILED
>>>>>> error: downloading https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: all
>>>>>> paths have failed, giving up
>>>>>> Build Set: Time 0:04:23.318509
>>>>>> Build FAILED
>>>>>>
>>>>>> The error message suggests that it is possible to add alternative
>>>>>> download sources. How can I do this? This didn't work:
>>>>>>
>>>>>> diff --git a/source-builder/config/gcc-9.cfg
>>>>>> b/source-builder/config/gcc-9.cfg
>>>>>> index f8cf69b..1d7c716 100644
>>>>>> --- a/source-builder/config/gcc-9.cfg
>>>>>> +++ b/source-builder/config/gcc-9.cfg
>>>>>> @@ -21,4 +21,8 @@
>>>>>>%source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
>>>>>>%source set mpfr 
>>>>>> https://ftp.gnu.org/gnu/mpfr/mpfr-%{mpfr_version}.tar.bz2
>>>>>>
>>>>>> +%source set mpc
>>>>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/mpc-%{mpc_version}.tar.gz
>>>>>> +%source set gmp
>>>>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/gmp-%{gmp_version}.tar.bz2
>>>>>> +%source set mpfr
>>>>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/mpfr-%{mpfr_version}.tar.bz2
>>>>>> +
>>>>>>%include %{_configdir}/gcc-common-1.cfg
>>>>>
>>>>> This would be Chris' department. Sorry
>>>
>>> I would update the `%source` keyword to accept:
>>>
>>> %source mirror mpc 1 https://ftp.mpi-inf.mpg.de/../mpc-%{mpc_version}.tar.gz
>>>
>>> where `1` is an integer priority and 1 is highest. The code is here:
>>>
>>> https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/sources.py#n55
>>>
>>> There is no such thing as a list in the macros so I suspect you would need 
>>> to
>>> dereference the source where the results of `_make_key` would reference 
>>> another
>>> series of macro keys that are the mirrors.
>>>
>>> Do we want to start maintaining lists of mirrors in RSB configurations? I am
>>> undecided. As developers we do not notice the online status due to the RSB
>>> cache. For sites and users would deployment be a better long term solution?
>>
>> Thanks for the hints. I added a ticket for this:
>>
>> https://devel.rtems.org/ticket/4573
> 
> How can we ensure that all mirrors listed work?

They would need to be tested and that means more code in the RSB to do it.

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

Re: [PATCH rtems-tools v1] ReportsBase: Change raw pointer to unique_ptr

[Chris Johns]

On 21/12/21 10:08 am, Ryan Long wrote:
> On 12/20/2021 5:03 PM, Chris Johns wrote:
>> On 21/12/21 7:24 am, Ryan Long wrote:
>>
>>>     reportList_t   reportList;
>> Then make this `reports`.
>>
>>>     reportList_t::iterator ritr;
>>>     std::string    reportName;
>>> -  ReportsBase*   reports;
>>>     time_t timestamp;
>>>         timestamp = time( NULL ); /* get current cal time */
>>> -  reports = new ReportsText(
>>> +  reportList.emplace_back(new ReportsText(
>> Should `std::make_unique(...)` be used?
> I was going to use this, but it was added in c++14.

Ak OK and thanks. I am using c++14 these days and had not noticed. I will leave
this with you.

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

Re: [PATCH rtems-tools v1] ReportsBase: Change raw pointer to unique_ptr

[Chris Johns]

On 21/12/21 7:24 am, Ryan Long wrote:
> Replaced raw pointer used with ReportsBase-derived classes to make code
> cleaner and make it to where pointers do not have to be manually
> deleted.
> 
> Closes #4376
> ---
>  tester/covoar/ReportsBase.cc | 21 ++---
>  1 file changed, 6 insertions(+), 15 deletions(-)
> 
> diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> index 219e5af..8ec65c0 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -591,17 +591,16 @@ void GenerateReports(
>boolbranchInfoAvailable
>  )
>  {
> -  typedef std::list reportList_t;
> +  typedef std::vector> reportList_t;

Are we OK to use `*_t` in types?

Plus I have moved to ...

using reportList = std::vector>

so I would use the following to avoid '>>':

using reportList_ptr = std::unique_ptr;
using reportLists = std::vector;

The vector is a container of report lists and not a container of report list
singular.

A minor point, I do not embed the container type into the type alias because
someone may decide to change this to `std::deque` or `std::forward_list` and the
name becomes misleading.

>reportList_t   reportList;

Then make this `reports`.

>reportList_t::iterator ritr;
>std::stringreportName;
> -  ReportsBase*   reports;
>time_t timestamp;
>  
>  
>timestamp = time( NULL ); /* get current cal time */
> -  reports = new ReportsText(
> +  reportList.emplace_back(new ReportsText(

Should `std::make_unique(...)` be used?

Thanks
Chris

>  timestamp,
>  symbolSetName,
>  allExplanations,
> @@ -609,9 +608,8 @@ void GenerateReports(
>  outputDirectory,
>  symbolsToAnalyze,
>  branchInfoAvailable
> -  );
> -  reportList.push_back( reports );
> -  reports = new ReportsHtml(
> +  ));
> +  reportList.emplace_back(new ReportsHtml(
>  timestamp,
>  symbolSetName,
>  allExplanations,
> @@ -619,11 +617,9 @@ void GenerateReports(
>  outputDirectory,
>  symbolsToAnalyze,
>  branchInfoAvailable
> -  );
> -  reportList.push_back( reports );
> +  ));
>  
> -  for ( ritr = reportList.begin(); ritr != reportList.end(); ritr++ ) {
> -reports = *ritr;
> +  for ( auto& reports: reportList ) {
>  
>  reportName = "index" + reports->ReportExtension();
>  if ( verbose ) {
> @@ -662,11 +658,6 @@ void GenerateReports(
>  reports->WriteSymbolSummaryReport( reportName, symbolsToAnalyze );
>}
>  
> -  for ( ritr = reportList.begin(); ritr != reportList.end(); ritr++ ) {
> -reports = *ritr;
> -delete reports;
> -  }
> -
>ReportsBase::WriteSummaryReport(
>  "summary.txt",
>  symbolSetName,
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Alternative download paths for RSB?

[Chris Johns]

On 21/12/21 2:33 am, Joel Sherrill wrote:
> On Mon, Dec 20, 2021 at 8:54 AM Joel Sherrill  wrote:
>>
>> On Mon, Dec 20, 2021 at 6:59 AM Sebastian Huber
>>  wrote:
>>>
>>> Hello,
>>>
>>> it seems the GNU web server is down:
>>
>> Yep. Still down.
>>
>> i reached out to the sourceware admins to see if they knew who to
>> contact. I couldn't find a gnu.org address.
> 
> Social media post from FSF forwarded by one of the sourceware admins
> about a general outage at the FSF:
> https://hostux.social/@fsfstatus/107479476196064925
> 
> Looks to be up now. RSB handling mirrors would be good. Although
> it would seem to be complex to ensure that all entries and mirrors are
> correct.
> 
>>
>>>
>>> download: https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2 ->
>>> sources/mpfr-3.1.4.tar.bz2
>>> download: https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: error:
>>> 
>>> error: downloading https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: all
>>> paths have failed, giving up
>>> Build FAILED
>>> error: downloading https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: all
>>> paths have failed, giving up
>>> Build Set: Time 0:04:23.318509
>>> Build FAILED
>>>
>>> The error message suggests that it is possible to add alternative
>>> download sources. How can I do this? This didn't work:
>>>
>>> diff --git a/source-builder/config/gcc-9.cfg
>>> b/source-builder/config/gcc-9.cfg
>>> index f8cf69b..1d7c716 100644
>>> --- a/source-builder/config/gcc-9.cfg
>>> +++ b/source-builder/config/gcc-9.cfg
>>> @@ -21,4 +21,8 @@
>>>   %source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
>>>   %source set mpfr https://ftp.gnu.org/gnu/mpfr/mpfr-%{mpfr_version}.tar.bz2
>>>
>>> +%source set mpc
>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/mpc-%{mpc_version}.tar.gz
>>> +%source set gmp
>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/gmp-%{gmp_version}.tar.bz2
>>> +%source set mpfr
>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/mpfr-%{mpfr_version}.tar.bz2
>>> +
>>>   %include %{_configdir}/gcc-common-1.cfg
>>
>> This would be Chris' department. Sorry

I would update the `%source` keyword to accept:

%source mirror mpc 1 https://ftp.mpi-inf.mpg.de/../mpc-%{mpc_version}.tar.gz

where `1` is an integer priority and 1 is highest. The code is here:

https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/sources.py#n55

There is no such thing as a list in the macros so I suspect you would need to
dereference the source where the results of `_make_key` would reference another
series of macro keys that are the mirrors.

Do we want to start maintaining lists of mirrors in RSB configurations? I am
undecided. As developers we do not notice the online status due to the RSB
cache. For sites and users would deployment be a better long term solution?

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

Re: New validation test suites

[Chris Johns]

On 16/12/21 6:36 pm, Sebastian Huber wrote:
> On 16/12/2021 04:51, Chris Johns wrote:
>> On 16/12/21 3:27 am, Sebastian Huber wrote:
>>> On 15/12/2021 06:46, Chris Johns wrote:
>>>> On 14/12/21 6:24 pm, Sebastian Huber wrote:
>>>>> Hello Chris,
>>>>>
>>>>> On 13/12/2021 22:01, Chris Johns wrote:
>>>>>> On 14/12/21 1:53 am, Sebastian Huber wrote:
>>> [...]
>>>>>>> We finished the specification of the pre-qualified RTEMS feature set. 
>>>>>>> The
>>>>>>> specification is available in an RTEMS Project repository:
>>>>>>>
>>>>>>> https://git.rtems.org/rtems-central/tree/spec
>>>>>>
>>>>>> I had a quick look. Is there a more user friendly view of this data?
>>>>>>
>>>>>> I think the term "specification" is a little bit misleading because the 
>>>>>> data
>>>>>> files are not easily read by a person. I understand this is the 
>>>>>> specification
>>>>>> data set however it is not what I am traditionally use to seeing.
>>>>>
>>>>> You can use the "./specview.py" script to get views of the specification. 
>>>>>  For
>>>>> example, this command displays the transition map for the 
>>>>> rtems_signal_send()
>>>>> directive:
>>>>
>>>> Is specview.py part of rtems.git?
>>>
>>> No, this script is in rtems-central.  This is also the location of the
>>> specification items.
>>
>> I am not sure linking a script from that repo like this is helpful.
>>
>>>> If not part of rtems.git how much data is there for all the output? That 
>>>> is it
>>>> is generated and held in the repo with the tests?
>>>
>>> In rtems.git, there are only the generated sources.
>>>
>>> [...]
>>
>> There should be no reach back to the upstream specs, scripts etc and for good
>> reasons. The information you posted is nice and useful and I do not wish to
>> release manage rtems-central to accommodate these tests in a release.
>>
>> Would capturing that information with the tests be something worth doing?
> 
> I don't think it would be useful. If you want to modify the tests you should
> work with the specification items and the corresponding scripts.

This is not about modifying the tests. As I previously stated the tests provide
little detail on the verification matrix being solved.

In relation to where is best to make changes, rtems-central may be the best
place however we will accept patches to the tests as they are in rtems.git. How
that is pushed back to rtems-central is not a focus here.

> Adding the
> tables as comments would blow up the sources considerably. Some tests have 
> about
> 5 table entries and the table entries depend on C preprocessor defines.

Ah yes I agree and what I was wanting to understand.

I think we need to understand what a release will contain because the specs used
are not captured with a release. I appreciate the efforts to make this available
as a workflow for development and for the pre-qual process but I am now
critically examining what this means for a release. For example lets say years
after a release someone questions a test, they will only have the test source
code in the release package and I think this is a short coming. Adding the
rtems-central repo as a package to the releases source may be a solution however
this creates further issues. How do I know the master of the rtems-central and
the committed sources match when creating the release as separate pieces of
rtems.git may have been updated at different commit points in rtems-central?

I suggest we get together when we can. Contact me off-line and lets see if we
can arrange a time :)

> 
> [...]
>>>>> In an earlier version of the header, we had a link which you didn't like:
>>>>
>>>> If I need to look at the formatting rules the heading "Software Development
>>>> Management" is easy to see and then a click on "Coding Standards" gives me 
>>>> what
>>>> I am looking for.
>>>>
>>>> To generate these headers I click on "Software Requirements Engineering" 
>>>> and
>>>> then do I just guess until I find it in the "How To" section? I am actually
>>>> asking this be sorted out so it is not left hanging and we are not left
>>>> guessing
>>>> what to do. If it can be rearrange into something meaningful it 

Re: [PATCH rtems-libbsd] Import arm64 in_cksum.h correctly

[Chris Johns]

OK

Thanks
Chris

On 16/12/21 3:05 am, Kinsey Moore wrote:
> When this file was brought in, it came from the wrong location or
> freebsd-org hash. This corrects the file such that freebsd-to-rtems.py
> runs cleanly.
> ---
>  freebsd/sys/arm64/include/machine/in_cksum.h | 43 +++-
>  1 file changed, 6 insertions(+), 37 deletions(-)
> 
> diff --git a/freebsd/sys/arm64/include/machine/in_cksum.h 
> b/freebsd/sys/arm64/include/machine/in_cksum.h
> index d55b838b..522ba005 100644
> --- a/freebsd/sys/arm64/include/machine/in_cksum.h
> +++ b/freebsd/sys/arm64/include/machine/in_cksum.h
> @@ -1,6 +1,4 @@
>  /*-
> - * SPDX-License-Identifier: BSD-3-Clause
> - *
>   * Copyright (c) 1990 The Regents of the University of California.
>   * All rights reserved.
>   *
> @@ -31,7 +29,6 @@
>   *   from tahoe: in_cksum.c  1.2 86/01/05
>   *   from:   @(#)in_cksum.c  1.3 (Berkeley) 1/19/91
>   *   from: Id: in_cksum.c,v 1.8 1995/12/03 18:35:19 bde Exp
> - *   from: src/sys/alpha/include/in_cksum.h,v 1.7 2005/03/02 21:33:20 joerg
>   * $FreeBSD$
>   */
>  
> @@ -40,44 +37,16 @@
>  
>  #include 
>  
> +#ifdef _KERNEL
>  #define  in_cksum(m, len)in_cksum_skip(m, len, 0)
> -
> +u_short in_addword(u_short sum, u_short b);
> +u_short in_cksum_skip(struct mbuf *m, int len, int skip);
> +u_int do_cksum(const void *, int);
>  #if defined(IPVERSION) && (IPVERSION == 4)
> -/*
> - * It it useful to have an Internet checksum routine which is inlineable
> - * and optimized specifically for the task of computing IP header checksums
> - * in the normal case (where there are no options and the header length is
> - * therefore always exactly five 32-bit words.
> - */
> -#ifdef __CC_SUPPORTS___INLINE
> -
> -static __inline void
> -in_cksum_update(struct ip *ip)
> -{
> - int __tmpsum;
> - __tmpsum = (int)ntohs(ip->ip_sum) + 256;
> - ip->ip_sum = htons(__tmpsum + (__tmpsum >> 16));
> -}
> -
> -#else
> -
> -#define  in_cksum_update(ip) 
> \
> - do {\
> - int __tmpsum;   \
> - __tmpsum = (int)ntohs(ip->ip_sum) + 256;\
> - ip->ip_sum = htons(__tmpsum + (__tmpsum >> 16));\
> - } while(0)
> -
> -#endif
> +u_int in_cksum_hdr(const struct ip *);
>  #endif
>  
> -#ifdef _KERNEL
> -#if defined(IPVERSION) && (IPVERSION == 4)
> -u_int in_cksum_hdr(const struct ip *ip);
> -#endif
> -u_short in_addword(u_short sum, u_short b);
>  u_short in_pseudo(u_int sum, u_int b, u_int c);
> -u_short in_cksum_skip(struct mbuf *m, int len, int skip);
> -#endif
>  
> +#endif /* _KERNEL */
>  #endif /* _MACHINE_IN_CKSUM_H_ */
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB 5] sb: Merge mailer changes from rtems-tools

[Chris Johns]

OK

Thanks
Chris

On 16/12/21 8:38 am, Alex White wrote:
> This adds the improved mailer.py script from rtems-tools.
> 
> Closes #4554
> ---
>  source-builder/sb/mailer.py | 194 
> +---
>  source-builder/sb/options.py|  26 +-
>  source-builder/sb/setbuilder.py |   2 +
>  3 files changed, 189 insertions(+), 33 deletions(-)
> 
> diff --git a/source-builder/sb/mailer.py b/source-builder/sb/mailer.py
> index 42b4fa6..1d3cbb5 100644
> --- a/source-builder/sb/mailer.py
> +++ b/source-builder/sb/mailer.py
> @@ -1,21 +1,33 @@
>  #
>  # RTEMS Tools Project (http://www.rtems.org/)
> -# Copyright 2013 Chris Johns (chr...@rtems.org)
> +# Copyright 2013-2016 Chris Johns (chr...@rtems.org)
> +# Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
>  # All rights reserved.
>  #
>  # This file is part of the RTEMS Tools package in 'rtems-tools'.
>  #
> -# Permission to use, copy, modify, and/or distribute this software for any
> -# purpose with or without fee is hereby granted, provided that the above
> -# copyright notice and this permission notice appear in all copies.
> +# 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 HOLDER 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.
>  #
> -# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> -# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> -# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> -# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> -# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> -# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> -# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  
>  #
>  # Manage emailing results or reports.
> @@ -28,18 +40,72 @@ import smtplib
>  import socket
>  
>  import error
> +import execute
>  import options
>  import path
>  
> +_options = {
> +'--mail' : 'Send email report or results.',
> +'--use-gitconfig': 'Use mail configuration from git config.',
> +'--mail-to'  : 'Email address to send the email to.',
> +'--mail-from': 'Email address the report is from.',
> +'--smtp-host': 'SMTP host to send via.',
> +'--smtp-port': 'SMTP port to send via.',
> +'--smtp-user': 'User for SMTP authentication.',
> +'--smtp-password': 'Password for SMTP authentication.'
> +}
> +
>  def append_options(opts):
> -opts['--mail'] = 'Send email report or results.'
> -opts['--smtp-host'] = 'SMTP host to send via.'
> -opts['--mail-to'] = 'Email address to send the email too.'
> -opts['--mail-from'] = 'Email address the report is from.'
> +for o in _options:
> +opts[o] = _options[o]
> +
> +def add_arguments(argsp):
> +argsp.add_argument('--mail', help = _options['--mail'], action = 
> 'store_true')
> +argsp.add_argument('--use-gitconfig', help = 
> _options['--use-gitconfig'], action = 'store_true')
> +no_add = ['--mail', '--use-gitconfig']
> +for o in [opt for opt in list(_options) if opt not in no_add]:
> +argsp.add_argument(o, help = _options[o], type = str)
>  
>  class mail:
>  def __init__(self, opts):
>  self.opts = opts
> +self.gitconfig_lines = None
> +if opts.find_arg('--use-gitconfig') is not None:
> +# Read the output of `git config --

Re: [PATCH rtems-tools 5 0/5] Port mailer.py fixes to rtems-tools 5 branch

[Chris Johns]

OK

Thanks
Chris

On 16/12/21 8:32 am, Alex White wrote:
> Hi,
> 
> This patch set adds the changes related to report mailing to rtems-tools 5.
> 
> See #4553
> 
> Thanks,
> 
> Alex White
> 
> Alex White (5):
>   rtemstoolkit/mailer.py: Return full smtp-host arg value
>   rtemstoolkit: Filter mail options from log output
>   rtemstoolkit/mailer.py: Add SMTP login options
>   rtemstoolkit/mailer.py: Add --use-gitconfig option
>   rtems-bsp-builder: Fix mail support
> 
>  rtemstoolkit/mailer.py  | 86 +
>  rtemstoolkit/options.py | 17 +++-
>  tester/rt/check.py  | 17 +++-
>  3 files changed, 111 insertions(+), 9 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Chris Johns]

On 16/12/21 3:27 am, Sebastian Huber wrote:
> On 15/12/2021 06:46, Chris Johns wrote:
>> On 14/12/21 6:24 pm, Sebastian Huber wrote:
>>> Hello Chris,
>>>
>>> On 13/12/2021 22:01, Chris Johns wrote:
>>>> On 14/12/21 1:53 am, Sebastian Huber wrote:
> [...]
>>>>> We finished the specification of the pre-qualified RTEMS feature set. The
>>>>> specification is available in an RTEMS Project repository:
>>>>>
>>>>> https://git.rtems.org/rtems-central/tree/spec
>>>>
>>>> I had a quick look. Is there a more user friendly view of this data?
>>>>
>>>> I think the term "specification" is a little bit misleading because the 
>>>> data
>>>> files are not easily read by a person. I understand this is the 
>>>> specification
>>>> data set however it is not what I am traditionally use to seeing.
>>>
>>> You can use the "./specview.py" script to get views of the specification.  
>>> For
>>> example, this command displays the transition map for the 
>>> rtems_signal_send()
>>> directive:
>>
>> Is specview.py part of rtems.git?
> 
> No, this script is in rtems-central.  This is also the location of the
> specification items.

I am not sure linking a script from that repo like this is helpful.

>> If not part of rtems.git how much data is there for all the output? That is 
>> it
>> is generated and held in the repo with the tests?
> 
> In rtems.git, there are only the generated sources.
> 
> [...]

There should be no reach back to the upstream specs, scripts etc and for good
reasons. The information you posted is nice and useful and I do not wish to
release manage rtems-central to accommodate these tests in a release.

Would capturing that information with the tests be something worth doing?

>>>>> The validation tests are generated from the specification using the
>>>>> "./spec2modules.py" script and end up in the RTEMS sources of a Git
>>>>> submodule. I
>>>>> think the specification and the generation tool is now sufficiently 
>>>>> stable so
>>>>> that the validation test code can be integrated in the RTEMS master 
>>>>> branch.
>>>>> The
>>>>> patch set is too big for the mailing list, so you can review it here:
>>>>>
>>>>> https://git.rtems.org/sebh/rtems.git/log/?h=validation
>>>>
>>>> The link failed.
>>>
>>> Yes, viewing my personal repository no longer works.  I am not sure if this 
>>> is a
>>> temporary issue.  This is why I added the github link.
>>
>> It seems to have been temporary. It is back again.
>>
>>>
>>>>
>>>>> https://github.com/sebhub/rtems/tree/validation
>>>>
>>>> The header in a test says the regeneration instructions are in the 
>>>> engineering
>>>> manual but I could not quickly find them?
>>>
>>> https://docs.rtems.org/branches/master/eng/req/howto.html#generate-content-after-changes
>>>
>>>
>>>
>>> In an earlier version of the header, we had a link which you didn't like:
>>
>> If I need to look at the formatting rules the heading "Software Development
>> Management" is easy to see and then a click on "Coding Standards" gives me 
>> what
>> I am looking for.
>>
>> To generate these headers I click on "Software Requirements Engineering" and
>> then do I just guess until I find it in the "How To" section? I am actually
>> asking this be sorted out so it is not left hanging and we are not left 
>> guessing
>> what to do. If it can be rearrange into something meaningful it would help. 
>> :)
> 
> Well, if you read the text in the header:
> 
>  * For information on updating and regenerating please refer to the How-To
>  * section in the Software Requirements Engineering chapter of the
>  * RTEMS Software Engineering manual.  The manual is provided as a part of
>  * a release.  For development sources please refer to the online
>  * documentation at:
>  *
>  * https://docs.rtems.org
> 
> You should read the How-to section or not?

Yes I should have and thanks for pointing this out but I did not see this and
the manual as it stands did not help. I think it should change. It can be
performed post this patch set but I think the documentation would read better if
changed.

>>>> What hardware have the validation tests been run 

Re: New validation test suites

[Chris Johns]

On 14/12/21 6:24 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 13/12/2021 22:01, Chris Johns wrote:
>> On 14/12/21 1:53 am, Sebastian Huber wrote:
>>> Hello,
>>>
>>> the ESA activity to pre-qualify parts of RTEMS according to ECSS 
>>> requirements is
>>> nearly complete. There is a short presentation available here:
>>>
>>> https://indico.esa.int/event/374/timetable/
>>
>> Was the change in memory usage for 4.8 of 23812 bytes to 68896 explained?
> 
> The foot print increase has mainly five reasons:
> 
> * General GCC code generation
> 
> * Chip errata workarounds done by GCC
> 
> * More features used from RTEMS (for example uniprocessor synchronization done
> via task priorities vs. mutex synchronization)
> 
> * SMP support of RTEMS
> 
> * New RTEMS features such as transitive priority inheritance
> 

Thanks.

>>> We finished the specification of the pre-qualified RTEMS feature set. The
>>> specification is available in an RTEMS Project repository:
>>>
>>> https://git.rtems.org/rtems-central/tree/spec
>>
>> I had a quick look. Is there a more user friendly view of this data?
>>
>> I think the term "specification" is a little bit misleading because the data
>> files are not easily read by a person. I understand this is the specification
>> data set however it is not what I am traditionally use to seeing.
> 
> You can use the "./specview.py" script to get views of the specification.  For
> example, this command displays the transition map for the rtems_signal_send()
> directive:

Is specview.py part of rtems.git?

If not part of rtems.git how much data is there for all the output? That is it
is generated and held in the repo with the tests?

> 
> ./specview.py --filter=action-table /rtems/signal/req/send
> .. table::
>     :class: longtable
> 
>     = == = === ===  == == 
> =
> =
>     Entry Descriptor Task  Set Handler ASR  Nested Status Handler 
>  
> Recursive
>     = == = === ===  == == 
> =
> =
>     0 0  NoObj Zero    Invalid Enabled  Yes    InvNum NoCall  
>   No
>     1 0  NoObj Zero    Invalid Enabled  No InvNum NoCall  
>   No
>     2 0  NoObj Zero    Invalid Disabled Yes    InvNum NoCall  
>   No
>     3 0  NoObj Zero    Invalid Disabled No InvNum NoCall  
>   No
>     4 0  NoObj Zero    Valid   Enabled  Yes    InvNum NoCall  
>   No
>     5 0  NoObj Zero    Valid   Enabled  No InvNum NoCall  
>   No
>     6 0  NoObj Zero    Valid   Disabled Yes    InvNum NoCall  
>   No
>     7 0  NoObj Zero    Valid   Disabled No InvNum NoCall  
>   No
>     8 1  NoObj NonZero Invalid Enabled  Yes    InvId NoCall   
>  No
>     9 1  NoObj NonZero Invalid Enabled  No InvId NoCall   
>  No
>     10    1  NoObj NonZero Invalid Disabled Yes    InvId NoCall   
>  No
>     11    1  NoObj NonZero Invalid Disabled No InvId NoCall   
>  No
>     12    1  NoObj NonZero Valid   Enabled  Yes    InvId NoCall   
>  No
>     13    1  NoObj NonZero Valid   Enabled  No InvId NoCall   
>  No
>     14    1  NoObj NonZero Valid   Disabled Yes    InvId NoCall   
>  No
>     15    1  NoObj NonZero Valid   Disabled No InvId NoCall   
>  No
>     16    0  Self  Zero    Invalid Enabled  Yes    InvNum NoCall  
>   No
>     17    0  Self  Zero    Invalid Enabled  No InvNum NoCall  
>   No
>     18    0  Self  Zero    Invalid Disabled Yes    InvNum NoCall  
>   No
>     19    0  Self  Zero    Invalid Disabled No InvNum NoCall  
>   No
>     20    0  Self  Zero    Valid   Enabled  Yes    InvNum NoCall  
>   No
>     21    0  Self  Zero    Valid   Enabled  No InvNum NoCall  
>   No
>     22    0  Self  Zero    Valid   Disabled Yes    InvNum NoCall  
>   No
>     23    0  Self  Zero    Valid   Disabled No InvNum NoCall  
>   No
>     24    2  Self  NonZero Invalid Enabled  Yes    NotDef NoCall  
>   No
>     25    2  Self  NonZero Invalid Enabled  No NotDef NoCall  
>   No
>     26    2  Self  NonZero Invalid Disabled Yes    NotDef NoCall  
>   No
>     27    2  Self  NonZero Invalid Disabled No NotDef NoCall  
>   No
>     28    6  

Re: [PATCH] TraceConverter.cc: Fix Uncaught exception issue

[Chris Johns]

OK

On 14/12/21 12:47 am, Ryan Long wrote:
> CID 1471639: Uncaught exception
> 
> Closes #4501
> ---
>  tester/covoar/TraceConverter.cc | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/tester/covoar/TraceConverter.cc b/tester/covoar/TraceConverter.cc
> index 8e30ae5..2c5330a 100644
> --- a/tester/covoar/TraceConverter.cc
> +++ b/tester/covoar/TraceConverter.cc
> @@ -87,14 +87,30 @@ int main(
>std::string tracefile;
>std::string logname = "/tmp/qemu.log";
>Coverage::ExecutableInfo*   executableInfo;
> -  rld::process::tempfile  objdumpFile( ".dmp" );
> -  rld::process::tempfile  err( ".err" );
>Coverage::DesiredSymbolssymbolsToAnalyze;
>boolverbose = false;
>std::string dynamicLibrary;
>int ec = 0;
>std::shared_ptr targetInfo;
>  
> +  try
> +  {
> +rld::process::tempfile objdumpFile( ".dmp" );
> +  }
> +  catch ( rld::error re )
> +  {
> +std::cerr << "Failed to make .dmp tempfile " << std::endl;
> +  }
> +
> +  try
> +  {
> +rld::process::tempfile err( ".err" );
> +  }
> +  catch ( rld::error re )
> +  {
> +std::cerr << "Failed to make .err tempfile " << std::endl;
> +  }
> +
>setup_signals();
>  
> //
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Chris Johns]

On 14/12/21 1:53 am, Sebastian Huber wrote:
> Hello,
> 
> the ESA activity to pre-qualify parts of RTEMS according to ECSS requirements 
> is
> nearly complete. There is a short presentation available here:
> 
> https://indico.esa.int/event/374/timetable/

Was the change in memory usage for 4.8 of 23812 bytes to 68896 explained?
> We finished the specification of the pre-qualified RTEMS feature set. The
> specification is available in an RTEMS Project repository:
> 
> https://git.rtems.org/rtems-central/tree/spec

I had a quick look. Is there a more user friendly view of this data?

I think the term "specification" is a little bit misleading because the data
files are not easily read by a person. I understand this is the specification
data set however it is not what I am traditionally use to seeing.

> The validation tests are generated from the specification using the
> "./spec2modules.py" script and end up in the RTEMS sources of a Git 
> submodule. I
> think the specification and the generation tool is now sufficiently stable so
> that the validation test code can be integrated in the RTEMS master branch. 
> The
> patch set is too big for the mailing list, so you can review it here:
> 
> https://git.rtems.org/sebh/rtems.git/log/?h=validation

The link failed.

> https://github.com/sebhub/rtems/tree/validation

The header in a test says the regeneration instructions are in the engineering
manual but I could not quickly find them?

> The patch set is organized so that general support code for the validation 
> tests
> is added first and then there are commits for each pre-qualified Classic API
> Manager or subsystem.
> 
> I did build all BSPs with the patch set. The validation tests use only
> statically allocated resources. 

Are the validation tests compatible with rtems-test?

How many test executables does this add to the testsuite?

What hardware have the validation tests been run on? Any tier 1 archs?

Is there anything that interprets the new test output format? It looks like lots
of great info but a little difficult to read.

> Some low memory targets are not able to link all test suites.

Are these excluded in the normal way?

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

Re: [PATCH rtems-tools 0/6] Fix formatting patches

[Chris Johns]

OK and thanks for the split.

Thanks
Chris

On 14/12/21 3:09 am, Ryan Long wrote:
> Hi,
> 
> For this patchset I made the formatting more consistent.
> 
> This included:
> 
> - adding whitespace
> - adding curly braces to if statements or loops
> - fixing the layout of long lists of function parameters
> 
> Thanks,
> Ryan
> 
> Ryan Long (6):
>   ObjdumpProcessor.cc: Fix formatting
>   TargetFactory.cc: Fix formatting
>   ConfigFile: Fix formatting
>   ObjdumpProcessor.cc: Fix formatting
>   ObjdumpProcessor.h: Fix formatting
>   SymbolTable.cc: Fix formatting
> 
>  tester/covoar/ConfigFile.cc   |  66 +-
>  tester/covoar/ConfigFile.h|   8 +-
>  tester/covoar/ObjdumpProcessor.cc | 261 
> +-
>  tester/covoar/ObjdumpProcessor.h  |  22 ++--
>  tester/covoar/SymbolTable.cc  |  70 +-
>  tester/covoar/TargetFactory.cc|  20 ++-
>  6 files changed, 241 insertions(+), 206 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] untar: Make behavior similar to GNU or BSD tar

[Chris Johns]

On 10/12/21 6:20 pm, Christian MAUDERER wrote:
> Am 09.12.21 um 22:09 schrieb Chris Johns:
>> On 9/12/21 6:47 pm, Christian MAUDERER wrote:
>>
>> Given it is in maybe we let it sit and it there is feedback we come back and
>> take another look?
> 
> No problem with that. I will try to be extra sensitive for problems with Untar
> that appear on the list in the next months.
> 

Thanks. There is no easy or clear guideline with this as a number of factors
effect this.

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

Re: [PATCH rtems-tools v2 0/4] Convert to C++ patches

[Chris Johns]

On 10/12/21 10:00 am, Ryan Long wrote:
> For this round of changes, I made some revisions that were recommended
> in ConfigFile.cc
> 
> - deleted a library include
> - changed a function call from sscanf to std::sscanf
> - consolidated some error messages into a function

OK to push.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] untar: Make behavior similar to GNU or BSD tar

[Chris Johns]

On 9/12/21 6:47 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> sorry that I haven't been clear enough.
> 
> 1. The ticket #4552 that I created before sending the patch to the list and 
> that
> was closed by the patch was for 5.
> 
> 2. I asked as an answer to Joels review and I understood him that he is OK 
> with
> that change:
> 
>   https://lists.rtems.org/pipermail/devel/2021-December/070092.html
> 
> and
> 
>   https://lists.rtems.org/pipermail/devel/2021-December/070093.html

Again sorry I missed this when I brushed over the emails.

> 
> Do you want me to revert that patch on 5?
> 

It does change the expected functionality and we should be careful about doing
that. It is not clear if someone has relied on it working this way as a cheap
way to detect an overwrite. I am fine on RTEMS 6 because of the upgrade and a
ticket in the release notes covering the change however if it breaks in a dot
release then that is a different issue.

Given it is in maybe we let it sit and it there is feedback we come back and
take another look?

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

Re: [rtems commit] untar: Make behavior similar to GNU or BSD tar

[Chris Johns]

Hi Christian,

I did not know this was for the 5 branch. Where was this discussed?

Functional changes to a release branch need to be treated carefully and in this
case I would not approve it. I am sorry if I did not pick up it was for 5 as 
well.

Thanks
Chris

On 9/12/21 6:21 pm, Christian Mauderer wrote:
> Module:rtems
> Branch:5
> Commit:ff3f3490df7120c9ec039b5acd1935265c3f9262
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=ff3f3490df7120c9ec039b5acd1935265c3f9262
> 
> Author:Christian Mauderer 
> Date:  Wed Dec  1 16:39:46 2021 +0100
> 
> untar: Make behavior similar to GNU or BSD tar
> 
> RTEMS untar implementation had problems with overwriting or integrating
> archives into existing directory structures. This patch adapts the
> behavior to mimic that of a GNU tar or BSD tar and extends the tar01
> test to check for the behavior. That is:
> 
> * If a directory structure exists, the files from the archive will be
>   integrated. Existing files are overwritten.
> 
> * If a file exists and the archive contains a directory with the same
>   name, the file is removed and a directory is created. In the above
>   example: if l1/l2 is a file it will be overwritten with a new
>   directory.
> 
> * If a directory exists and the archive contains a file with the same
>   name, the directory will be replaced if it is empty. If it contains
>   files, the result is an error.
> 
> * An archive also can contain only a file without the parent
>   directories. If in that case one of the parent directories exists as a
>   file extracting the archive results in an error. In the example: if
>   l1/l2 is a file and the archive doesn't contain the directories but
>   only the file l1/l2/x.txt that would be an error.
> 
> * In case of an error, it is possible that the archive has been
>   partially extracted.
> 
> Closes #4552
> 
> ---
> 
>  cpukit/libmisc/untar/untar.c|  57 +++
>  testsuites/libtests/tar01/init.c| 199 
> +++-
>  testsuites/libtests/tar01/tar01.doc |   1 +
>  testsuites/libtests/tar01/tar01.scn |  54 --
>  testsuites/libtests/tar01/tar01.tar | Bin 10240 -> 10240 bytes
>  5 files changed, 282 insertions(+), 29 deletions(-)
> 
> diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
> index a2f09fb..ab2 100644
> --- a/cpukit/libmisc/untar/untar.c
> +++ b/cpukit/libmisc/untar/untar.c
> @@ -126,30 +126,25 @@ Make_Path(const rtems_printer *printer, char *path)
>  
>  *p = '\0';
>  if (p[1] == '\0') {
> -  /* Speculatively unlink the last component so that it can be 
> re-created */
> -  unlink(path);
>return 0;
>  }
>  
>  if (mkdir(path, S_IRWXU | S_IRWXG | S_IRWXO) != 0) {
> -  if (errno == EEXIST || errno == EISDIR) {
> +  if (errno == EEXIST) {
> +/* If it exists already: Check whether it is a directory */
>  struct stat sb;
> -
> -if (stat(path, ) != 0) {
> +if (lstat(path, ) != 0) {
> +  Print_Error(printer, "lstat", path);
> +  return -1;
> +} else if (!S_ISDIR(sb.st_mode)) {
> +  rtems_printf(printer,
> +   "untar: mkdir: %s: exists but is not a directory\n",
> +   path);
>return -1;
>  }
> -
> -if (!S_ISDIR(sb.st_mode)) {
> -  if (unlink(path) != 0) {
> -Print_Error(printer, "unlink", path);
> -return -1;
> -  }
> -
> -  if (mkdir(path, S_IRWXU | S_IRWXG | S_IRWXO) != 0) {
> -Print_Error(printer, "mkdir (unlink)", path);
> -return -1;
> -  }
> -}
> +  } else {
> +Print_Error(printer, "mkdir", path);
> +return -1;
>}
>  }
>  
> @@ -206,6 +201,12 @@ Untar_ProcessHeader(
>  
>if (Make_Path(ctx->printer, ctx->file_path) != 0) {
>  retval = UNTAR_FAIL;
> +  } else {
> +/*
> + * Speculatively unlink. This should unlink everything but non-empty
> + * directories or write protected stuff.
> + */
> +unlink(ctx->file_path);
>}
>  
>if (ctx->linkflag == SYMTYPE) {
> @@ -225,8 +226,22 @@ Untar_ProcessHeader(
>  rtems_printf(ctx->printer, "untar: dir: %s\n", ctx->file_path);
>  r = mkdir(ctx->file_path, ctx->mode);
>  if (r != 0) {
> -  Print_Error(ctx->printer, "mkdir", ctx->file_path);
> -  retval = UNTAR_FAIL;
> +  if (errno == EEXIST) {
> +/* If it exists already: Check whether it is a directory */
> +struct stat sb;
> +if (lstat(ctx->file_path, ) != 0) {
> +  Print_Error(ctx->printer, "lstat", ctx->file_path);
> +  retval = UNTAR_FAIL;
> +} else if (!S_ISDIR(sb.st_mode)) {
> +  rtems_printf(ctx->printer,
> +   "untar: mkdir: %s: exists but is not a directory\n",
> +   ctx->file_path);
> +  retval = UNTAR_FAIL;
> +}
> +  } else {
> +

Re: [PATCH v1 3/4] ConfigFile: Convert to C++

[Chris Johns]

On 9/12/21 2:15 am, Ryan Long wrote:
> ---
>  tester/covoar/ConfigFile.cc | 79 
> +
>  tester/covoar/ConfigFile.h  |  2 +-
>  2 files changed, 31 insertions(+), 50 deletions(-)
> 
> diff --git a/tester/covoar/ConfigFile.cc b/tester/covoar/ConfigFile.cc
> index c16b64a..5c8949e 100644
> --- a/tester/covoar/ConfigFile.cc
> +++ b/tester/covoar/ConfigFile.cc
> @@ -10,6 +10,10 @@
>  #include 

Is this needed? I think reducing the C interfaces included would help the long
maintenance.

>  #include 
>  
> +#include 
> +#include 
> +#include 
> +
>  namespace Configuration {
>  
>FileReader::FileReader(
> @@ -24,43 +28,40 @@ namespace Configuration {
>}
>  
>bool FileReader::processFile(
> -const char* const file
> +const std::string& file
>)
>{
>  #define METHOD "FileReader::processFile - "
> -FILE *  in;
> -charline[256];
> -charoption[256];
> -charvalue[256];
> +#define MAX_LENGTH 256
> +std::ifstream in;
> +std::string line;
> +char option[MAX_LENGTH];
> +char value[MAX_LENGTH];
>  int line_no;
>  int i;
>  int j;
>  
> -if ( file == NULL ) {
> -  fprintf( stderr, METHOD "NULL filename\n" );
> +if ( file.empty() ) {
> +  std::cerr << METHOD << "Empty filename" << std::endl;
>return false;
>  }
>  
> -in = fopen( file, "r" );
> -if ( !in ) {
> -  fprintf( stderr, METHOD "unable to open %s\n", file );
> +in.open( file );
> +if ( !in.is_open() ) {
> +  std::cerr << METHOD << "unable to open " << file << std::endl;
>return false;
>  }
>  
>  line_no = 0;
> -while (fgets(line, sizeof(line), in) != NULL) {
> +while ( std::getline( line, MAX_LENGTH ) ) {
>int length;
>  
>line_no++;
>  
> -  length = (int) strlen( line );
> -  if ( line[length - 1] != '\n' ) {
> -fprintf(
> -  stderr,
> -  "%s: line %d is too long",
> -  file,
> -  line_no
> -);
> +  length = (int) line.length();
> +  if ( length > MAX_LENGTH ) {
> +std::cerr << file << ": line " << line_no << " is too long"
> +  << std::endl;
>  continue;
>}
>  
> @@ -96,14 +97,9 @@ namespace Configuration {
>if (line[0] == '\0')
>  continue;
>  
> -  if (sscanf(line, "%s", option) != 1) {
> -fprintf(
> -  stderr,
> -  "%s: line %d is invalid: %s\n",
> -  file,
> -  line_no,
> -  line
> -);
> +  if (sscanf(line.c_str(), "%s", option) != 1) {

I suggest you use the C++ interface ..

https://en.cppreference.com/w/cpp/io/c/fscanf

> +std::cerr << file << ": line" << line_no << " is invalid: " << line
> +  << std::endl;

Please make the repeated code a helper function with line number and line as 
args.

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

Re: [PATCH] spec: Update location of cadence I2C

[Chris Johns]

OK and thanks

Chris

On 9/12/21 12:08 pm, Kinsey Moore wrote:
> When the cadence I2C code was moved to a shared directory, the
> references were updated but the install locations weren't. This updates
> the install locations to match what out-of-tree applications expect.
> ---
>  spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml | 4 +++-
>  spec/build/bsps/arm/xilinx-zynq/obj.yml | 6 --
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml 
> b/spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml
> index fd9d51dfa9..fa269d61ad 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml
> @@ -9,10 +9,12 @@ enabled-by: true
>  includes: []
>  install:
>  - destination: ${BSP_INCLUDEDIR}/bsp
> +  source:
> +  - bsps/aarch64/xilinx-zynqmp/include/bsp/i2c.h
> +- destination: ${BSP_INCLUDEDIR}/dev/i2c
>source:
>- bsps/include/dev/i2c/cadence-i2c-regs.h
>- bsps/include/dev/i2c/cadence-i2c.h
> -  - bsps/aarch64/xilinx-zynqmp/include/bsp/i2c.h
>  links: []
>  source:
>  - bsps/shared/dev/i2c/cadence-i2c.c
> diff --git a/spec/build/bsps/arm/xilinx-zynq/obj.yml 
> b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> index bc675cd38c..dcac09126b 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/obj.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> @@ -14,10 +14,12 @@ install:
>- bsps/arm/xilinx-zynq/include/tm27.h
>  - destination: ${BSP_INCLUDEDIR}/bsp
>source:
> -  - bsps/include/dev/i2c/cadence-i2c-regs.h
> -  - bsps/include/dev/i2c/cadence-i2c.h
>- bsps/arm/xilinx-zynq/include/bsp/i2c.h
>- bsps/arm/xilinx-zynq/include/bsp/irq.h
> +- destination: ${BSP_INCLUDEDIR}/dev/i2c
> +  source:
> +  - bsps/include/dev/i2c/cadence-i2c-regs.h
> +  - bsps/include/dev/i2c/cadence-i2c.h
>  links: []
>  source:
>  - bsps/arm/shared/cache/cache-l2c-310.c
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools 0/8] Convert and reformat pt. 4

[Chris Johns]

On 8/12/21 1:09 am, Ryan Long wrote:
> On 12/6/2021 10:09 PM, Chris Johns wrote:
>> On 4/12/21 1:47 am, Ryan Long wrote:
>>> Hi,
>>>
>>> For this series of patches, I followed this series of steps:
>>>
>>> 1. Convert a file from the C way of doing things to C++.
>>> 2. Go through all the files that had to do with the converted file and
>>> make the formatting consistent.
>> OK to push.
>>
>> It would be helpful in future to separate the white space changes from any 
>> code
>> changes.
> 
> I guess removing "void" from an empty parameter list and adding curly brackets
> around if statements counts as code changes? 

Yes.

> I didn't see any whitespace changes in the code changes.

The following is an example:

-debug.begin(executable.elf());
+debug.begin( executable.elf() );

It takes time for me to check and see if this is the same code with whitespace
changes or whitespace and code changes.

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

Re: [PATCH] untar: Make behavior similar to GNU or BSD tar

[Chris Johns]

On 3/12/21 11:50 pm, Christian Mauderer wrote:
> RTEMS untar implementation had problems with overwriting or integrating
> archives into existing directory structures. This patch adapts the
> behavior to mimic that of a GNU tar or BSD tar and extends the tar01
> test to check for the behavior. That is:
> 
> * If a directory structure exists, the files from the archive will be
>   integrated. Existing files are overwritten.

What currently happens?

> * If a file exists and the archive contains a directory with the same
>   name, the file is removed and a directory is created. In the above
>   example: if l1/l2 is a file it will be overwritten with a new
>   directory.

OK

> * If a directory exists and the archive contains a file with the same
>   name, the directory will be replaced if it is empty. If it contains
>   files, the result is an error.
> 
> * An archive also can contain only a file without the parent
>   directories. If in that case one of the parent directories exists as a
>   file extracting the archive results in an error. In the example: if
>   l1/l2 is a file and the archive doesn't contain the directories but
>   only the file l1/l2/x.txt that would be an error.
> 
> * In case of an error, it is possible that the archive has been
>   partially extracted.

And what was there is not recoverable.

Functionally this is not a big change and so I am left wondering why the
original developer(s) did not do this?

I think the changes make sense and I do not think it will break any applications
I know of that use this code.

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

Re: [PATCH rtems-tools 0/8] Convert and reformat pt. 4

[Chris Johns]

On 4/12/21 1:47 am, Ryan Long wrote:
> Hi,
> 
> For this series of patches, I followed this series of steps:
> 
> 1. Convert a file from the C way of doing things to C++.
> 2. Go through all the files that had to do with the converted file and
> make the formatting consistent.

OK to push.

It would be helpful in future to separate the white space changes from any code
changes.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/1] Update rtems-notes-5.md

[Chris Johns]

On 3/12/21 8:26 pm, jan.som...@dlr.de wrote:
>> -Original Message-
>> From: Chris Johns 
>> Sent: Thursday, December 2, 2021 10:11 PM
>> To: Sommer, Jan ; Moyano Heredia, Victor Gabriel
>> ; devel@rtems.org
>> Subject: Re: [PATCH 1/1] Update rtems-notes-5.md
>>
>> On 2/12/21 7:27 pm, jan.som...@dlr.de wrote:
>>>> -Original Message-
>>>> From: devel  On Behalf Of Chris Johns
>>>> Sent: Thursday, December 2, 2021 2:06 AM
>>>> To: Moyano Heredia, Victor Gabriel ;
>>>> devel@rtems.org
>>>> Subject: Re: [PATCH 1/1] Update rtems-notes-5.md
>>>>
>>>> OK to push.
>>>
>>> Should I push the addition to master, 5, or both branches?
>>
>> Good question, I think both.
>>
> 
> One more question: 
> Adding the 5.2 Release notes below the ones from 5.1 is correct?
> Or do you prefer to have the newest release notes on top?

I think top.

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

Re: [PATCH 1/1] Update rtems-notes-5.md

[Chris Johns]

On 2/12/21 7:27 pm, jan.som...@dlr.de wrote:
>> -Original Message-
>> From: devel  On Behalf Of Chris Johns
>> Sent: Thursday, December 2, 2021 2:06 AM
>> To: Moyano Heredia, Victor Gabriel ;
>> devel@rtems.org
>> Subject: Re: [PATCH 1/1] Update rtems-notes-5.md
>>
>> OK to push.
> 
> Should I push the addition to master, 5, or both branches?

Good question, I think both.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/1] Update rtems-notes-5.md

[Chris Johns]

OK to push.

Thanks
Chris

On 1/12/21 2:03 am, Moyano, Gabriel wrote:
> ---
>  rtems-notes-5.md | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/rtems-notes-5.md b/rtems-notes-5.md
> index 3737199..7697980 100644
> --- a/rtems-notes-5.md
> +++ b/rtems-notes-5.md
> @@ -374,3 +374,12 @@ Obsoleted architectures:
>  * RTEMS Trace addition of a new trace record support for target tracing.
>  
>  * RTEMS Bootimage, a tool to portably create SD card images.
> +
> +## RTEMS 5.2 Release Notes
> +
> +### API Changes
> +
> + API Additions
> +
> +* NTP support
> + * Addition of NTP update second handler via 
> _Timecounter_Set_NTP_update_second() from 
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/5] score: Optimize Workspace Handler initialization

[Chris Johns]

On 29/11/21 9:29 pm, Sebastian Huber wrote:
> The BSPs provide memory for the workspace initialization via
> _Memory_Get().  Most BSPs provide exactly one memory area.  Only two
> BSPs provide more than one memory area (arm/altera-cyclone-v and
> bsps/powerpc/mpc55xxevb).  Only if more than one memory area is
> provided, there is a need to use _Heap_Extend().  Provide two
> implementations to initialize the workspace handler and let the BSP
> select one of the implementations based on the number of provided memory
> areas.  This gets rid of a dependency on _Heap_Extend().  It also avoids
> dead code sections for most BSPs.
> ---
>  bsps/shared/start/wkspaceinitmany.c   |  46 +++
>  bsps/shared/start/wkspaceinitone.c|  46 +++
>  cpukit/include/rtems/score/wkspace.h  |  12 +-
>  cpukit/include/rtems/score/wkspaceinitmany.h  | 129 ++
>  cpukit/include/rtems/score/wkspaceinitone.h   | 113 +++
>  cpukit/score/src/wkspace.c|  85 +---
>  .../altera-cyclone-v/bspalteracyclonev.yml|   1 +
>  spec/build/bsps/i386/pc386/obj.yml|   1 +
>  spec/build/bsps/objmem.yml|   1 +
>  spec/build/bsps/powerpc/mpc55xxevb/obj.yml|   1 +
>  spec/build/bsps/powerpc/objmem.yml|   1 +
>  spec/build/bsps/powerpc/tqm8xx/obj.yml|   1 +
>  spec/build/bsps/sparc/objmem.yml  |   1 +
>  13 files changed, 347 insertions(+), 91 deletions(-)
>  create mode 100644 bsps/shared/start/wkspaceinitmany.c
>  create mode 100644 bsps/shared/start/wkspaceinitone.c
>  create mode 100644 cpukit/include/rtems/score/wkspaceinitmany.h
>  create mode 100644 cpukit/include/rtems/score/wkspaceinitone.h
> 
> diff --git a/bsps/shared/start/wkspaceinitmany.c 
> b/bsps/shared/start/wkspaceinitmany.c
> new file mode 100644
> index 00..30335d63c9
> --- /dev/null
> +++ b/bsps/shared/start/wkspaceinitmany.c
> @@ -0,0 +1,46 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreWorkspace
> + *
> + * @brief This source file contains the _Workspace_Handler_initialization()
> + *   implementation which supports more than one memory area.
> + */
> +
> +/*
> + * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> + *
> + * 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.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +
> +void _Workspace_Handler_initialization( void )
> +{
> +  _Workspace_Initialize_for_many_areas();

_Workspace_Initialize_for_multiple_areas() ?

And then also for _Malloc_Initialize_for_many_areas() ?

> diff --git a/cpukit/include/rtems/score/wkspaceinitmany.h 
> b/cpukit/include/rtems/score/wkspaceinitmany.h
> new file mode 100644
> index 00..0277c6ee1e
> --- /dev/null
> +++ b/cpukit/include/rtems/score/wkspaceinitmany.h
> @@ -0,0 +1,129 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreWorkspace
> + *
> + * @brief This header file provides the implementation of
> + *   _Workspace_Initialize_for_many_areas().
> + */
> +
> +/*
> + * Copyright (C) 2012, 2020 embedded brains GmbH 
> (http://www.embedded-brains.de)
> + *
> + * 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 

Re: AW: AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

[Chris Johns]

On 29/11/21 11:24 pm, Sebastian Huber wrote:
> On 24/11/2021 10:57, gabriel.moy...@dlr.de wrote:
>>> I am fine with this change being pushed to the 5 branch but I think it
>>> needs to built with the tier 1 archs (i386, powerpc, arm).
>> I could compile them for the BSPs of those archs.
> Thanks.
>
>> Does it make sense to run some test in qemu?
> Test results are always welcome.
>
 I've run the following tests:
 - sptimecounter02, 03 and 04 are pass on pc686 and Xilinx_zynq_a9.
 - sptimecounter01 doesn't print something since everything happens inside 
 of
 boot_card(). How the result of this test is verified?
>>> Re-run the test using rtems-test.
>>> - sptimecounter01, 02, 03 and 04 are marked as pass on Xilinx_zynq_a9 and 
>>> psim
>>> - sptimecounter02, 03 and 04 are marked as pass on pc686
>>> - sptimecounter01 is marked as invalid on pc686. This result is with and
>>> without the patch set. I guess it is because nothing is printed
>>> out.
>>>
 Are there any other tests that can be interested to run?
>>> If there isn't any other test to run, I would say that the patch set is 
>>> ready.
>> After running the whole testsuite for pc686, xilinx_zynq_a9 and psim; there
>> are no new failures introduced.
> 
> For me this is fine, what do you think Chris?

Sorry about the delay and being distracted .. a few deadlines.

Yes this looks fine.

I think Jan has commit access so if he could push this to the 5 branch it would
be appreciated.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: grub2 on old Linux Distributions (at least CentOS 7)

[Chris Johns]

On 21/11/21 12:21 pm, Joel Sherrill wrote:
> On Sat, Nov 20, 2021, 6:50 PM Karel Gardas  wrote:
>> indeed, centos 7 is bundled with gcc 4.8.5. Now, the question is, is
>> centos 7 still supported by RTEMS? If so, then we will need to invent
>> some machinery to check not only for commands but also for versions in
>> cfg files? Also if we're doing this we need to check firmly we're really
>> on old centos IMHO.
> 
> You can't build the documentation without using a Python 3 software
> collection, Texlive, and some pip magic. For rtems6, I might be ok with
> recommending a newer GCC.

Is this to be checked and enforced or does it just fail to build?

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

Re: AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

[Chris Johns]

On 19/11/21 9:32 pm, gabriel.moy...@dlr.de wrote:
>> I am fine with this change being pushed to the 5 branch but I think it needs 
>> to built with the tier 1 archs (i386, powerpc, arm).
> 
> I could compile them for the BSPs of those archs. 

Thanks.

> Does it make sense to run some test in qemu?

Test results are always welcome.

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

Re: Testing rtems 7 using rtems-test

[Chris Johns]

On 20/11/21 5:14 am, Joel Sherrill wrote:
> Looks like another place that needs version help. rtems-test has a 6
> in it somewhere that needs to be overridden.

It is located here:

https://git.rtems.org/rtems-tools/tree/tester/rtems/version.cfg

> Notice that it is
> invoking sparc-rtems6-sis when I really want sparc-rtems7-sis.
> Hopefully there is an existing way to override this easily enough.
> Otherwise, we are missing a small but essential piece of really
> testing rtems7.

Yes it needs to have the `--rtems-version` option added. I will need to play a
bit to figure out how to add this.

Could you please raise a ticket and assign it to me?

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

[Chris Johns]

On 17/11/21 11:03 pm, Sebastian Huber wrote:
> On 17/11/2021 11:42, gabriel.moy...@dlr.de wrote:
>>> The patch set should have no API/ABI impact on applications.
>> Sorry I didn't verified if the ABI is broken. We are checking this with my 
>> team.
> 
> I think, the patch set should have no API/ABI impact on applications. The
> changes are all in kern_tc.c.

I am fine with this change being pushed to the 5 branch but I think it needs to
built with the tier 1 archs (i386, powerpc, arm).

Once pushed I would appreciate an update to:

https://git.rtems.org/rtems-release/tree/rtems-notes-5.md

under "## RTEMS 5.2 Release Notes".

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] rtems: Add new clock manager directives

[Chris Johns]

On 18/11/21 3:39 am, Sebastian Huber wrote:
> On 17/11/2021 09:11, Sebastian Huber wrote:
>> Module:    rtems
>> Branch:    master
>> Commit:    ccbcfb679da0a6c07878d3ae4ff0f91cb1c3caee
>> Changeset:http://git.rtems.org/rtems/commit/?id=ccbcfb679da0a6c07878d3ae4ff0f91cb1c3caee
>>
>>
>> Author:    Sebastian Huber
>> Date:  Mon Oct 11 17:07:50 2021 +0200
>>
>> rtems: Add new clock manager directives
>>
>> Update #4527.
> 
> Sorry, I accidentally committed this patch along with the build system patch
> set. I will revert it if needed.

Thank you for raising this. I saw them go by. Lets leave them, all good.

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

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 16/11/21 4:27 am, Sebastian Huber wrote:
> On 11/11/2021 08:02, Sebastian Huber wrote:> On 09/11/2021 13:06, Sebastian
> Huber wrote:
>>> On 09/11/2021 08:50, Sebastian Huber wrote:
>>>> On 09/11/2021 08:41, Chris Johns wrote:
>>>>>> We could also use something like this:
>>>>>>
>>>>>> static inline struct timespec rtems_clock_get_realtime(void)
>>>>>> {
>>>>>>    struct timespec time_snapshot;
>>>>>>
>>>>>>    _Timecounter_Nanotime( _snapshot );
>>>>>>
>>>>>>    return time_snapshot;
>>>>>> }
>>>>>>
>>>>>> Unfortunately GCC is not able to optimize this.
>>>>>>
>>>>> Ah OK. This can be fixed and the performance improved but once the API is
>>>>> set it
>>>>> cannot change or do you think we can add a check later and not break the 
>>>>> API?
>>>>
>>>> I filed a GCC bug for this:
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103150
>>>>
>>>> It seems I was not the only one noticing issues related to structure 
>>>> returns:
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
>>>>
>>>> However, if we want a foolproof API, then I would prefer the structure
>>>> return over the return status and pointer argument. Compilers may get 
>>>> better
>>>> in the future. clang has similar issues, so this is not only a GCC problem.
>>>
>>> We have at least three options for the API:
>>>
>>> 1. Use the existing FreeBSD implementation as is:
>>>
>>> void rtems_clock_get_realtime(struct timespec *);
>>>
>>> This is the easiest and most efficient approach.
>>>
>>> 2. Check for NULL and return a status:
>>>
>>> rtems_status_code rtems_clock_get_realtime(struct timespec *);
>>>
>>> This requires a wrapper function which is a bit less efficient and needs 
>>> more
>>> code/testing:
>>>
>>> rtems_status_code
>>> rtems_clock_get_realtime(struct timespec *time_snapshot)
>>> {
>>>    if ( time_snapshot == NULL ) {
>>>  return RTEMS_INVALID_ADDRESS;
>>>    }
>>>
>>>    _Timecounter_Nanotime( time_snapshot );
>>>    return RTEMS_SUCCESSFUL;
>>> }
>>>
>>> 3. Return the structure and use the existing implementation:
>>>
>>> static inline struct timespec rtems_clock_get_realtime(void)
>>> {
>>>    struct timespec time_snapshot;
>>>
>>>    _Timecounter_Nanotime( _snapshot );
>>>
>>>    return time_snapshot;
>>> }
>>>
>>> This is currently not well supported by existing compilers:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103150
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
>>>
>>
>> 4. Do nothing for a NULL pointer:
>>
>> void rtems_clock_get_realtime(struct timespec *);
>>
>> This requires a wrapper function which can use a tail call optimization:
>>
>> void
>> rtems_clock_get_realtime(struct timespec *time_snapshot)
>> {
>>    if ( time_snapshot == NULL ) {
>>  return;
>>    }
>>
>>    _Timecounter_Nanotime( time_snapshot );
>> }
> 
> How do we want to proceed with this? We ship the high performance and very
> useful clock routines from FreeBSD since 2015. I just would like to add an 
> RTEMS
> signature for them and document them in the Clock Manager. Currently, these
> routines are the most efficient way to get clock values in RTEMS. Developers
> afraid of unchecked NULL pointers may use existing RTEMS directives or
> clock_get(). It would be nice if we can decide on a way forward.

I will leave this for Joel to decide.

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

Re: [PATCH] config: CONFIGURE_DISABLE_BSP_SETTINGS

[Chris Johns]

OK

Chris

On 16/11/21 5:18 am, Sebastian Huber wrote:
> Evaluate CONFIGURE_DISABLE_BSP_SETTINGS for each affected application
> configuration option.  This makes the code easier to review since the 
> influence
> of CONFIGURE_DISABLE_BSP_SETTINGS is locally visible in the code.
> ---
>  cpukit/include/rtems/confdefs/bsp.h| 15 ++-
>  cpukit/include/rtems/confdefs/extensions.h |  3 ++-
>  cpukit/include/rtems/confdefs/iodrivers.h  |  3 ++-
>  cpukit/include/rtems/confdefs/malloc.h | 10 +++---
>  cpukit/include/rtems/confdefs/percpu.h |  9 ++---
>  5 files changed, 19 insertions(+), 21 deletions(-)
> 
> diff --git a/cpukit/include/rtems/confdefs/bsp.h 
> b/cpukit/include/rtems/confdefs/bsp.h
> index 03ad9bf55f..bc96713765 100644
> --- a/cpukit/include/rtems/confdefs/bsp.h
> +++ b/cpukit/include/rtems/confdefs/bsp.h
> @@ -41,19 +41,8 @@
>  #error "Do not include this file directly, use  instead"
>  #endif
>  
> -#ifdef CONFIGURE_INIT
> -
> -#ifdef CONFIGURE_DISABLE_BSP_SETTINGS
> -  #undef BSP_IDLE_TASK_BODY
> -  #undef BSP_IDLE_TASK_STACK_SIZE
> -  #undef BSP_INITIAL_EXTENSION
> -  #undef BSP_INTERRUPT_STACK_SIZE
> -  #undef CONFIGURE_BSP_PREREQUISITE_DRIVERS
> -  #undef CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
> -#else
> -  #include 
> +#if defined(CONFIGURE_INIT) && !defined(CONFIGURE_DISABLE_BSP_SETTINGS)
> +#include 
>  #endif
>  
> -#endif /* CONFIGURE_INIT */
> -
>  #endif /* _RTEMS_CONFDEFS_BSP_H */
> diff --git a/cpukit/include/rtems/confdefs/extensions.h 
> b/cpukit/include/rtems/confdefs/extensions.h
> index 6492407934..118ad29484 100644
> --- a/cpukit/include/rtems/confdefs/extensions.h
> +++ b/cpukit/include/rtems/confdefs/extensions.h
> @@ -146,7 +146,8 @@ extern "C" {
>  #ifdef CONFIGURE_INITIAL_EXTENSIONS
>CONFIGURE_INITIAL_EXTENSIONS,
>  #endif
> -#ifdef BSP_INITIAL_EXTENSION
> +#if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +  defined(BSP_INITIAL_EXTENSION)
>BSP_INITIAL_EXTENSION
>  #endif
>};
> diff --git a/cpukit/include/rtems/confdefs/iodrivers.h 
> b/cpukit/include/rtems/confdefs/iodrivers.h
> index a7de77a8c3..8c102197eb 100644
> --- a/cpukit/include/rtems/confdefs/iodrivers.h
> +++ b/cpukit/include/rtems/confdefs/iodrivers.h
> @@ -110,7 +110,8 @@ extern "C" {
>  
>  rtems_driver_address_table
>  _IO_Driver_address_table[ CONFIGURE_MAXIMUM_DRIVERS ] = {
> -  #ifdef CONFIGURE_BSP_PREREQUISITE_DRIVERS
> +  #if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +defined(CONFIGURE_BSP_PREREQUISITE_DRIVERS)
>  CONFIGURE_BSP_PREREQUISITE_DRIVERS,
>#endif
>#ifdef CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS
> diff --git a/cpukit/include/rtems/confdefs/malloc.h 
> b/cpukit/include/rtems/confdefs/malloc.h
> index d864a98270..a8dae6e739 100644
> --- a/cpukit/include/rtems/confdefs/malloc.h
> +++ b/cpukit/include/rtems/confdefs/malloc.h
> @@ -45,8 +45,12 @@
>  
>  #include 
>  
> -#if defined(CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK) \
> -  || defined(CONFIGURE_MALLOC_DIRTY)
> +#if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +  defined(CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK)
> +#define _CONFIGURE_HEAP_EXTEND_VIA_SBRK
> +#endif
> +
> +#if defined(_CONFIGURE_HEAP_EXTEND_VIA_SBRK) || 
> defined(CONFIGURE_MALLOC_DIRTY)
>  #include 
>  #endif
>  
> @@ -54,7 +58,7 @@
>  extern "C" {
>  #endif
>  
> -#ifdef CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
> +#ifdef _CONFIGURE_HEAP_EXTEND_VIA_SBRK
>  const rtems_heap_extend_handler rtems_malloc_extend_handler =
>rtems_heap_extend_via_sbrk;
>  #endif
> diff --git a/cpukit/include/rtems/confdefs/percpu.h 
> b/cpukit/include/rtems/confdefs/percpu.h
> index 3bea8340cb..b91590bfd9 100644
> --- a/cpukit/include/rtems/confdefs/percpu.h
> +++ b/cpukit/include/rtems/confdefs/percpu.h
> @@ -78,7 +78,8 @@ extern "C" {
>  /* Interrupt stack configuration */
>  
>  #ifndef CONFIGURE_INTERRUPT_STACK_SIZE
> -  #ifdef BSP_INTERRUPT_STACK_SIZE
> +  #if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +defined(BSP_INTERRUPT_STACK_SIZE)
>  #define CONFIGURE_INTERRUPT_STACK_SIZE BSP_INTERRUPT_STACK_SIZE
>#else
>  #define CONFIGURE_INTERRUPT_STACK_SIZE CPU_STACK_MINIMUM_SIZE
> @@ -121,7 +122,8 @@ RTEMS_DEFINE_GLOBAL_SYMBOL(
>  /* Idle thread configuration */
>  
>  #ifndef CONFIGURE_IDLE_TASK_STACK_SIZE
> -  #ifdef BSP_IDLE_TASK_STACK_SIZE
> +  #if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +defined(BSP_IDLE_TASK_STACK_SIZE)
>  #define CONFIGURE_IDLE_TASK_STACK_SIZE BSP_IDLE_TASK_STACK_SIZE
>#else
>  #define CONFIGURE_IDLE_TASK_STACK_SIZE CONFIGURE_MINIMUM_TASK_STACK_SIZE
> @@ -153,7 +155,8 @@ const size_t _Thread_Idle_stack_size = 
> CONFIGURE_IDLE_TASK_STACK_SIZE;
>#error "If you define CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION, then 
> you must define CONFIGURE_IDLE_TASK_BODY as well"
>  #endif
>  
> -#if !defined(CONFIGURE_IDLE_TASK_BODY) && defined(BSP_IDLE_TASK_BODY)
> +#if !defined(CONFIGURE_IDLE_TASK_BODY) && \
> +  

Re: [PATCH] c-user: Use rubric for configuration options

[Chris Johns]

OK to push. This is a sensible change to make.

Thanks
Chris

On 16/11/21 6:27 pm, Sebastian Huber wrote:
> Use a rubric instead of a definition list for the application
> configuration options similar to the directive documentation pages.  For
> direcives and application configuration options use the same rubric
> order.
> 
> Generalize value constraints to constraints.
> 
> This patch does not change hand written content.
> ---
> 
> The generated PDF can be reviewed here:
> 
> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
> 
>  c-user/config/bdbuf.rst |  457 +--
>  c-user/config/bsp-related.rst   |  304 
>  c-user/config/classic-api.rst   |  676 
>  c-user/config/classic-init-task.rst |  355 +
>  c-user/config/device-driver.rst |  792 ++-
>  c-user/config/event-record.rst  |  160 ++--
>  c-user/config/filesystem.rst|  844 ++--
>  c-user/config/general.rst   | 1103 +++
>  c-user/config/idle-task.rst |  147 ++--
>  c-user/config/mpci.rst  |  315 
>  c-user/config/posix-api.rst |  539 +++--
>  c-user/config/posix-init-thread.rst |  115 +--
>  c-user/config/scheduler-general.rst |  669 
>  c-user/config/task-stack-alloc.rst  |  244 +++---
>  14 files changed, 3691 insertions(+), 3029 deletions(-)
> 
> diff --git a/c-user/config/bdbuf.rst b/c-user/config/bdbuf.rst
> index c5381e1..d36c2bd 100644
> --- a/c-user/config/bdbuf.rst
> +++ b/c-user/config/bdbuf.rst
> @@ -35,24 +35,29 @@ This section describes configuration options related to 
> the Block Device Cache
>  CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
>  
>  
> -CONSTANT:
> -``CONFIGURE_APPLICATION_NEEDS_LIBBLOCK``
> +.. rubric:: CONSTANT:
>  
> -OPTION TYPE:
> -This configuration option is a boolean feature define.
> +``CONFIGURE_APPLICATION_NEEDS_LIBBLOCK``
>  
> -DEFAULT CONFIGURATION:
> -If this configuration option is undefined, then the described feature is 
> not
> -enabled.
> +.. rubric:: OPTION TYPE:
>  
> -DESCRIPTION:
> -In case this configuration option is defined, then the Block Device 
> Cache is
> -initialized during system initialization.
> +This configuration option is a boolean feature define.
>  
> -NOTES:
> -Each option of the Block Device Cache (bdbuf) configuration can be 
> explicitly
> -set by the user with the configuration options below.  The Block Device 
> Cache
> -is used for example by the RFS and DOSFS filesystems.
> +.. rubric:: DEFAULT CONFIGURATION:
> +
> +If this configuration option is undefined, then the described feature is not
> +enabled.
> +
> +.. rubric:: DESCRIPTION:
> +
> +In case this configuration option is defined, then the Block Device Cache is
> +initialized during system initialization.
> +
> +.. rubric:: NOTES:
> +
> +Each option of the Block Device Cache (bdbuf) configuration can be explicitly
> +set by the user with the configuration options below.  The Block Device Cache
> +is used for example by the RFS and DOSFS filesystems.
>  
>  .. Generated from spec:/acfg/if/bdbuf-buffer-max-size
>  
> @@ -63,30 +68,31 @@ NOTES:
>  CONFIGURE_BDBUF_BUFFER_MAX_SIZE
>  ---
>  
> -CONSTANT:
> -``CONFIGURE_BDBUF_BUFFER_MAX_SIZE``
> +.. rubric:: CONSTANT:
> +
> +``CONFIGURE_BDBUF_BUFFER_MAX_SIZE``
> +
> +.. rubric:: OPTION TYPE:
>  
> -OPTION TYPE:
> -This configuration option is an integer define.
> +This configuration option is an integer define.
>  
> -DEFAULT VALUE:
> -The default value is 4096.
> +.. rubric:: DEFAULT VALUE:
>  
> -VALUE CONSTRAINTS:
> -The value of this configuration option shall satisfy all of the following
> -constraints:
> +The default value is 4096.
>  
> -* It shall be greater than or equal to zero.
> +.. rubric:: DESCRIPTION:
>  
> -* It shall be an integral multiple of
> -  :ref:`CONFIGURE_BDBUF_BUFFER_MIN_SIZE`.
> +The value of this configuration option defines the maximum size of a buffer
> +in bytes.
>  
> -DESCRIPTION:
> -The value of this configuration option defines the maximum size of a 
> buffer
> -in bytes.
> +.. rubric:: CONSTRAINTS:
>  
> -NOTES:
> -None.
> +The following constraints apply to this configuration option:
> +
> +* The value of the configuration option shall be greater than or equal to 
> zero.
> +
> +* The value of the configuration option shall be an integral multiple of
> +  :ref:`CONFIGURE_BDBUF_BUFFER_MIN_SIZE`.
>  
>  .. Generated from spec:/acfg/if/bdbuf-buffer-min-size
>  
> @@ -97,30 +103,31 @@ NOTES:
>  CONFIGURE_BDBUF_BUFFER_MIN_SIZE
>  ---
>  
> -CONSTANT:
> -``CONFIGURE_BDBUF_BUFFER_MIN_SIZE``
> +.. rubric:: CONSTANT:
> +
> +``CONFIGURE_BDBUF_BUFFER_MIN_SIZE``
> +
> +.. rubric:: OPTION TYPE:
>  
> -OPTION TYPE:
> -This configuration option is an integer define.
> +This 

Re: [PATCH v2 1/4] Revert "optvermaj.yml: Allow __RTEMS_MAJOR__ to be overridden so RTEMS 7 tools can be tested"

[Chris Johns]

OK and thank you

Chris

On 16/11/21 5:47 pm, Sebastian Huber wrote:
> This reverts commit d1bbfbea5f60f552b2b3138bb1df35c3372f2461.
> ---
>  spec/build/cpukit/optvermaj.yml | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/spec/build/cpukit/optvermaj.yml b/spec/build/cpukit/optvermaj.yml
> index e1a5eae5b3..2596e6ef6a 100644
> --- a/spec/build/cpukit/optvermaj.yml
> +++ b/spec/build/cpukit/optvermaj.yml
> @@ -1,16 +1,14 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
> -- get-string: null
> +- set-value: '6'
>  - env-assign: null
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -default: 6
> +default: null
>  default-by-variant: []
> -description: |
> -  Major Component of the RTEMS Version Number
> +description: ''
>  enabled-by: true
> -format: '{}' 
>  links: []
>  name: __RTEMS_MAJOR__
>  type: build
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] waf: Add --rtems-version as a configure option

[Chris Johns]

On 15/11/21 7:09 pm, Sebastian Huber wrote:
> On 14/11/2021 23:42, Chris Johns wrote:
>>> With this approach you don't give the user the ability to change everything.
>>> However, what can be change is defined by the build specification and not 
>>> the
>>> wscript.
>> I understand the reason however you would need to implement it to show how 
>> it is
>> done? Can we internally do:
>>
>>   set_value("__RTEMS_MAJOR__", ctx.options.rtems_version)
>>
>> ? I do not understand the how to make the change and then manage the sequence
>> via the actions.
> 
> Please have a look at for a proof of concept:
> 
> https://lists.rtems.org/pipermail/devel/2021-November/069889.html

Really nice and I like the idea of `get-string-command-line`. Having this in the
spec files is important if you want to know what can be changed. The prepare
step is a nice way to sequence the steps and the bit I was not sure about.

> We can also add --rtems-version=X and map it to __RTEMS_MAJOR=X in the wscipt.

Is adding this something specific? I would like to see the option directly
supported.

Thank you for the patch and the prompt response.

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

Re: [PATCH] waf: Add --rtems-version as a configure option

[Chris Johns]

> On 14 Nov 2021, at 11:15 pm, Sebastian Huber
>  wrote:
>
> On 14/11/2021 04:07, chr...@rtems.org wrote:
>> From: Chris Johns 
>> - Provide the option `--rtems-version` to set the major version
>>   number
>> - Add a method to handle setting action values
>> - Return the spec YAML file back to it's original values
>>   as it does not allow a user to change the version.
>> Closes #4548
>
> I would simply revert the optvermaj.yml patch with "git revert".

Ok. 

> I don't like the special case approach which violates one design principle of
> the build system that the wcript should know the absolute minimum of the
> layout of the build specification.

This alternative moves that knowledge out into all sorts of support tools. Is
that what you want?

I think the same command line interface (--rtems-version) used else where for
this option would be good.

> My preferred solution would be that the build item defines that it can be
> modified by a command line option, for example:
>
> ./waf configure --rtems-set-value=__RTEMS_MAJOR__=7

Does this option as stated here contradict the idea of the build system being
specified? I see strength in the spec files and I am not sure about a generic
approach. I think the less that can change the better. And if you need change
the spec files to use the value what does it offer?

We need to change the version and a specific option exposes as narrow an
interface as possible.

> In spec/build/cpukit/optvermaj.yml:
>
> actions:
> - get-string-option: '6'
> - env-assign
>
> With this approach you don't give the user the ability to change everything.
> However, what can be change is defined by the build specification and not the
> wscript.

I understand the reason however you would need to implement it to show how it is
done? Can we internally do:

 set_value("__RTEMS_MAJOR__", ctx.options.rtems_version)

? I do not understand the how to make the change and then manage the sequence
via the actions. 

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

[RBW] Re: Large pedals, thumbs up

[JohnS]

Thank you Ray for the tip, great looking pedals, may give them a try myself 
and they are in stock (at least they are today).

JohnS

On Saturday, November 13, 2021 at 12:52:35 PM UTC-5 Ray Varella wrote:

> Over the years I’ve seen numerous comments on how comfortable larger 
> pedals are. 
> I’ve ridden standard sized pedals my whole life and never gave it much 
> though. 
> Since I’ve spent more and more time riding in thin soled sandals I noticed 
> a bit of discomfort (not pain) after riding for a couple hours. 
> I bought a pair of Sylvan Gorditos from Crust and swapped out my standard 
> Sylvans. 
> After I got home from my first ride with them I realized i hadn’t noticed 
> any pressure where I used to. 
> Aside from that I didn’t give them a single thought while riding. 
>
> I see more big pedals in my future. 
>
> Ray
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/75aeb6e8-cae0-49e8-afc4-79a2a39be24en%40googlegroups.com.

Re: [RTEMS v2] optvermaj.yml: Allow __RTEMS_MAJOR__ to be overridden so RTEMS 7 tools can be tested

[Chris Johns]

On 13/11/21 10:00 am, Joel Sherrill wrote:
> On Fri, Nov 12, 2021 at 4:52 PM Chris Johns  wrote:
>>
>> Let me take a look at a configure option. I prefer it over spec files as this
>> creates another thing to change after a release.
> 
> Happy to see an alternative way to do this. At this point, there was no way
> to build RTEMS or any subsequent software with the rtems7 tools. That
> seemed like a glaring hole in the testing.

I see it is applied. It is a bit rough to post then push 45 minutes later a
patch when someone is asleep.

I now need to see what was there and figure it all out.

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

Re: [PATCH RSB] rtems-tools-6.cfg: Bump hash to get fix for rtems-test

[Chris Johns]

OK

On 13/11/21 1:54 am, Joel Sherrill wrote:
> ---
>  rtems/config/tools/rtems-tools-6.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-tools-6.cfg 
> b/rtems/config/tools/rtems-tools-6.cfg
> index 6d05d12..cf895d6 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version d1df4f6e02fe22d2cb542adbd6ba4248ee077892
> + %define rtems_tools_version 6b31bb03aaf98232a21813c471d0298c170dde60
>   %define rtems_tools_ext bz2
>  %endif
>  
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools 
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
>  %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> - 
> zhSEMRbpLdeDTg6RI5U1e/TU9FsN09cS/NPQrXCMU6QJsCdDWIzA0HwTq54/apM7RW38uQkmaW9cPk5RVU3e1A==
> + 
> +TKPQxx2HdnSBW7QcgfzFZCjRw7mssXHaJSxDd0v1KJ/VLeWcdus/MELH7oq0WyEMpqAyd1+1HpMVuFrMFyvcw==
>  
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RTEMS v2] optvermaj.yml: Allow __RTEMS_MAJOR__ to be overridden so RTEMS 7 tools can be tested

[Chris Johns]

Let me take a look at a configure option. I prefer it over spec files as this
creates another thing to change after a release.

Thanks
Chris

On 13/11/21 3:03 am, Joel Sherrill wrote:
> ---
>  spec/build/cpukit/optvermaj.yml | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/spec/build/cpukit/optvermaj.yml b/spec/build/cpukit/optvermaj.yml
> index 2596e6ef6a..e1a5eae5b3 100644
> --- a/spec/build/cpukit/optvermaj.yml
> +++ b/spec/build/cpukit/optvermaj.yml
> @@ -1,14 +1,16 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
> -- set-value: '6'
> +- get-string: null
>  - env-assign: null
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -default: null
> +default: 6
>  default-by-variant: []
> -description: ''
> +description: |
> +  Major Component of the RTEMS Version Number
>  enabled-by: true
> +format: '{}' 
>  links: []
>  name: __RTEMS_MAJOR__
>  type: build
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Building a BSP for rtems7

[Chris Johns]

On 13/11/21 9:08 am, Joel Sherrill wrote:
> On Fri, Nov 12, 2021 at 3:50 PM Chris Johns  wrote:
>>
>> On 13/11/21 12:46 am, Sebastian Huber wrote:
>>> On 11/11/2021 22:31, Joel Sherrill wrote:
>>>> On Thu, Nov 11, 2021 at 12:56 PM Sebastian Huber
>>>>   wrote:
>>>>>
>>>>>
>>>>> On 11/11/2021 17:47, Joel Sherrill wrote:
>>>>>> Hi
>>>>>>
>>>>>> I was looking at the logs for building the rtems7 tools and it seems
>>>>>> that I am missing something on the waf configure for rtems to build
>>>>>> for rtems7. Assuming it is possible. My command was:
>>>>>>
>>>>>> ./waf configure --rtems-tools=/home/joel/rtems-cron-7/tools/7
>>>>>> --rtems-bsps=sparc/leon3 --out=b-leon3
>>>>>> --prefix=/home/joel/rtems-cron-7/tools/7/bsp-install
>>>>>> --rtems-config=config-sparc-leon3.ini
>>>>>>
>>>>>> And it still tried to find sparc-rtems6-gcc.  Is there an argument i am 
>>>>>> mising?
>>>>> Try to add
>>>>>
>>>>> __RTEMS_MAJOR__ = 7
>>>>>
>>>>> to the config.ini.
>>>> That isn't in the set dumped by bsp_defaults and using it didn't
>>>> appear to change anything.
>>>
>>> Ok, I seem to remember a discussion about this some time ago. Options with
>>>
>>> default: null
>>>
>>> cannot be changed by the user. I think for the RTEMS version the reason was 
>>> that
>>> users should be forced to use the right tool chain.
>>>
>>> We could change the RTEMS version options to
>>>
>>> default: 6
>>>
>>> for example.
>>>
>>> At the moment you have to patch spec/build/cpukit/optvermaj.yml to build 
>>> with a
>>> tool chain of the wrong version.
>>
>> I think the major version is important enough and needed for development 
>> that a
>> top level waf option should be considered. I am not in favour of settings or 
>> INI
>> files because these can be archived in user projects. A user should be able 
>> to
>> move a config from 6 to 7 to 8 etc without changing it. An option can be 
>> used to
>> force the change.
> 
> OK. Patch? :)
> 

Please?

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

Re: Building a BSP for rtems7

[Chris Johns]

On 13/11/21 12:46 am, Sebastian Huber wrote:
> On 11/11/2021 22:31, Joel Sherrill wrote:
>> On Thu, Nov 11, 2021 at 12:56 PM Sebastian Huber
>>   wrote:
>>>
>>>
>>> On 11/11/2021 17:47, Joel Sherrill wrote:
 Hi

 I was looking at the logs for building the rtems7 tools and it seems
 that I am missing something on the waf configure for rtems to build
 for rtems7. Assuming it is possible. My command was:

 ./waf configure --rtems-tools=/home/joel/rtems-cron-7/tools/7
 --rtems-bsps=sparc/leon3 --out=b-leon3
 --prefix=/home/joel/rtems-cron-7/tools/7/bsp-install
 --rtems-config=config-sparc-leon3.ini

 And it still tried to find sparc-rtems6-gcc.  Is there an argument i am 
 mising?
>>> Try to add
>>>
>>> __RTEMS_MAJOR__ = 7
>>>
>>> to the config.ini.
>> That isn't in the set dumped by bsp_defaults and using it didn't
>> appear to change anything.
> 
> Ok, I seem to remember a discussion about this some time ago. Options with
> 
> default: null
> 
> cannot be changed by the user. I think for the RTEMS version the reason was 
> that
> users should be forced to use the right tool chain.
> 
> We could change the RTEMS version options to
> 
> default: 6
> 
> for example.
> 
> At the moment you have to patch spec/build/cpukit/optvermaj.yml to build with 
> a
> tool chain of the wrong version.

I think the major version is important enough and needed for development that a
top level waf option should be considered. I am not in favour of settings or INI
files because these can be archived in user projects. A user should be able to
move a config from 6 to 7 to 8 etc without changing it. An option can be used to
force the change.

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

Re: RSB: add GRUB2 to the tools.

[Chris Johns]

On 11/11/21 9:15 am, Karel Gardas wrote:
> On 11/10/21 11:04 PM, Chris Johns wrote:
>> On 11/11/21 5:32 am, Karel Gardas wrote:
>>> the attach patch adds GRUB2 into the RSB RTEMS tools. Idea is to use
>>> that on amd64 BSP for building bootable images. That's also the reason
>>> why it is used only on 6/rtems-x86_64 bset only.
>>
>> Thank you for adding this and posting it here.
>>
>> Does grub build on all supported hosts, ie Windows, MacOS, FreeBSD and Linux?
> 
> Wow! I've tested only build on Ubuntu 20.04. I'll see what I can do
> about others. FreeBSD (13) is most easy to do here actually.

It may not be possible to build on Windows and MacOS and that may be fine. Maybe
an error is raised if the host type is not supported?

This is a really useful package and it is good we add it.

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

Re: RSB: add GRUB2 to the tools.

[Chris Johns]

On 11/11/21 5:32 am, Karel Gardas wrote:
> the attach patch adds GRUB2 into the RSB RTEMS tools. Idea is to use
> that on amd64 BSP for building bootable images. That's also the reason
> why it is used only on 6/rtems-x86_64 bset only.

Thank you for adding this and posting it here.

Does grub build on all supported hosts, ie Windows, MacOS, FreeBSD and Linux?

Chris

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

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 9/11/21 5:57 pm, Sebastian Huber wrote:
> On 09/11/2021 03:46, Chris Johns wrote:
>>
>> On 20/10/21 2:25 am, Sebastian Huber wrote:
>>> Add new clock manager directives to get all times provided by the
>>> timehands.
>>>
>>> Update #4527.
>>> ---
>>> For an updated document to review see:
>>>
>>> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
>>>
>>> v2: Clarify boot time.
>>>
>>>   c-user/clock/directives.rst   | 835 ++
>>>   c-user/clock/introduction.rst |  81 
>>>   2 files changed, 916 insertions(+)
>>>
>>> diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
>>> index bdb7680..8f2d7ea 100644
>>> --- a/c-user/clock/directives.rst
>>> +++ b/c-user/clock/directives.rst
>>> @@ -224,6 +224,841 @@ The following constraints apply to this directive:
>>>     Applications which are restricted to only use interfaces of the
>>> pre-qualified
>>>     feature set of RTEMS shall not use the directive.
>>>   +.. Generated from spec:/rtems/clock/if/get-realtime
>>> +
>>> +.. raw:: latex
>>> +
>>> +    \clearpage
>>> +
>>> +.. index:: rtems_clock_get_realtime()
>>> +
>>> +.. _InterfaceRtemsClockGetRealtime:
>>> +
>>> +rtems_clock_get_realtime()
>>> +--
>>> +
>>> +Gets the time elapsed since the :term:`Unix epoch` measured using
>>> +:term:`CLOCK_REALTIME` in seconds and nanoseconds format.
>>> +
>>> +.. rubric:: CALLING SEQUENCE:
>>> +
>>> +.. code-block:: c
>>> +
>>> +    void rtems_clock_get_realtime( struct timespec *time_snapshot );
>>> +
>>> +.. rubric:: PARAMETERS:
>>> +
>>> +``time_snapshot``
>>> +    This parameter is the pointer to a `struct timespec
>>> +<https://en.cppreference.com/w/c/chrono/timespec>`_ object. The time> +   
>>> elapsed since the :term:`Unix epoch` measured using the
>>> +    :term:`CLOCK_REALTIME` at some time point during the directive call 
>>> will be
>>> +    stored in this object.  Calling the directive with a pointer equal to 
>>> `NULL
>>> +<https://en.cppreference.com/w/c/types/NULL>`_ is undefined behaviour.
>> Why not return an invalid error status? Same question for the same thing 
>> below.
> 
> I just documented the existing implementation. If you want an error status and
> NULL pointer checks, then we have to add a wrapper function around the FreeBSD
> interface. We still have to export the FreeBSD interface since it is used by
> libbsd.

Sure. I was only comparing this against the other APIs we have and a NULL is
checked.

> 
> The functions just have a single parameter and no return value currently. Why
> would someone pass a NULL pointer to such functions?
> 
> We could also change
> 
> RTEMS_ALIAS(_Timecounter_Nanotime)
> void rtems_clock_get_realtime(struct timespec *);
> 
> to
> 
> rtems_status_code
> rtems_clock_get_realtime(struct timespec *time_snapshot)
> {
>   if ( time_snapshot == NULL ) {
>     return RTEMS_INVALID_ADDRESS;
>   }
> 
>   _Timecounter_Nanotime( time_snapshot );
>   return RTEMS_SUCCESSFUL;
> }
> 
> However, this is less efficient. You need an extra comparison, a branch, a 
> stack
> frame, push/pop of the return address, and an extra function call.
> 
> We could also use something like this:
> 
> static inline struct timespec rtems_clock_get_realtime(void)
> {
>   struct timespec time_snapshot;
> 
>   _Timecounter_Nanotime( _snapshot );
> 
>   return time_snapshot;
> }
> 
> Unfortunately GCC is not able to optimize this.
> 

Ah OK. This can be fixed and the performance improved but once the API is set it
cannot change or do you think we can add a check later and not break the API?

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

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 20/10/21 2:25 am, Sebastian Huber wrote:
> Add new clock manager directives to get all times provided by the
> timehands.
> 
> Update #4527.
> ---
> For an updated document to review see:
> 
> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
> 
> v2: Clarify boot time.
> 
>  c-user/clock/directives.rst   | 835 ++
>  c-user/clock/introduction.rst |  81 
>  2 files changed, 916 insertions(+)
> 
> diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
> index bdb7680..8f2d7ea 100644
> --- a/c-user/clock/directives.rst
> +++ b/c-user/clock/directives.rst
> @@ -224,6 +224,841 @@ The following constraints apply to this directive:
>Applications which are restricted to only use interfaces of the 
> pre-qualified
>feature set of RTEMS shall not use the directive.
>  
> +.. Generated from spec:/rtems/clock/if/get-realtime
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: rtems_clock_get_realtime()
> +
> +.. _InterfaceRtemsClockGetRealtime:
> +
> +rtems_clock_get_realtime()
> +--
> +
> +Gets the time elapsed since the :term:`Unix epoch` measured using
> +:term:`CLOCK_REALTIME` in seconds and nanoseconds format.
> +
> +.. rubric:: CALLING SEQUENCE:
> +
> +.. code-block:: c
> +
> +void rtems_clock_get_realtime( struct timespec *time_snapshot );
> +
> +.. rubric:: PARAMETERS:
> +
> +``time_snapshot``
> +This parameter is the pointer to a `struct timespec
> +`_ object. The time> +  
>   elapsed since the :term:`Unix epoch` measured using the
> +:term:`CLOCK_REALTIME` at some time point during the directive call will 
> be
> +stored in this object.  Calling the directive with a pointer equal to 
> `NULL
> +`_ is undefined behaviour.

Why not return an invalid error status? Same question for the same thing below.

Chris

> +
> +.. rubric:: NOTES:
> +
> +The directive accesses a device provided by the :term:`Clock Driver` to get 
> the
> +time in the highest precision available to the system.  Alternatively, the
> +:ref:`InterfaceRtemsClockGetRealtimeCoarse` directive may be used to get the
> +time with less precision and less runtime overhead.
> +
> +See :ref:`InterfaceRtemsClockGetRealtimeBintime` and
> +:ref:`InterfaceRtemsClockGetRealtimeTimeval` to get the time in alternative
> +formats.
> +
> +.. rubric:: CONSTRAINTS:
> +
> +The following constraints apply to this directive:
> +
> +* The directive may be called from within any runtime context.
> +
> +* The directive will not cause the calling task to be preempted.
> +
> +* The directive requires a :term:`Clock Driver`.
> +
> +.. Generated from spec:/rtems/clock/if/get-realtime-bintime
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: rtems_clock_get_realtime_bintime()
> +
> +.. _InterfaceRtemsClockGetRealtimeBintime:
> +
> +rtems_clock_get_realtime_bintime()
> +--
> +
> +Gets the time elapsed since the :term:`Unix epoch` measured using
> +:term:`CLOCK_REALTIME` in binary time format.
> +
> +.. rubric:: CALLING SEQUENCE:
> +
> +.. code-block:: c
> +
> +void rtems_clock_get_realtime_bintime( struct bintime *time_snapshot );
> +
> +.. rubric:: PARAMETERS:
> +
> +``time_snapshot``
> +This parameter is the pointer to a :c:type:`bintime` object.  The time
> +elapsed since the :term:`Unix epoch` measured using the
> +:term:`CLOCK_REALTIME` at some time point during the directive call will 
> be
> +stored in this object.  Calling the directive with a pointer equal to 
> `NULL
> +`_ is undefined behaviour.
> +
> +.. rubric:: NOTES:
> +
> +The directive accesses a device provided by the :term:`Clock Driver` to get 
> the
> +time in the highest precision available to the system.  Alternatively, the
> +:ref:`InterfaceRtemsClockGetRealtimeCoarseBintime` directive may be used to 
> get
> +the time with less precision and less runtime overhead.
> +
> +See :ref:`InterfaceRtemsClockGetRealtime` and
> +:ref:`InterfaceRtemsClockGetRealtimeTimeval` to get the time in alternative
> +formats.
> +
> +.. rubric:: CONSTRAINTS:
> +
> +The following constraints apply to this directive:
> +
> +* The directive may be called from within any runtime context.
> +
> +* The directive will not cause the calling task to be preempted.
> +
> +* The directive requires a :term:`Clock Driver`.
> +
> +.. Generated from spec:/rtems/clock/if/get-realtime-timeval
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: rtems_clock_get_realtime_timeval()
> +
> +.. _InterfaceRtemsClockGetRealtimeTimeval:
> +
> +rtems_clock_get_realtime_timeval()
> +--
> +
> +Gets the time elapsed since the :term:`Unix epoch` measured using
> +:term:`CLOCK_REALTIME` in seconds and microseconds format.
> +
> +.. rubric:: CALLING SEQUENCE:
> +
> +.. code-block:: c
> 

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 9/11/21 9:08 am, Joel Sherrill wrote:
> 
> 
> On Mon, Nov 8, 2021, 5:04 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 8/11/21 5:29 pm, Sebastian Huber wrote:
> > On 25/10/2021 19:50, Sebastian Huber wrote:
> >> On 19/10/2021 17:25, Sebastian Huber wrote:
> >>> Add new clock manager directives to get all times provided by the
> >>> timehands.
> >>>
> >>> Update #4527.
> >>> ---
> >>> For an updated document to review see:
> >>>
> >>> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
> <https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf>
> >>>
> >>> v2: Clarify boot time.
> >>
> >> Any comments with respect to the new clock manager directives?
> >
> > If I get no objections, I will commit this on Wednesday.
> 
> We need to discuss and resolve the use of external links to specific 
> pages in
> our documentation.
> 
> I have just seen the links to opengroup.org <http://opengroup.org> and
> cppreference.com <http://cppreference.com> in the patch
> and was going to comment however a check of the existing documentation 
> shows:
> 
> $ grep -r cppreference `find . -name \*.rst` | wc -l
>      164
> 
> $ grep -r opengroup.org <http://opengroup.org> `find . -name \*.rst` | wc 
> -l
>       11
> 
> It looks like I have missed this happening in the past. I think we need to
> handle what happens with these external links because it now blocks a 6 
> release.
> 
> Deep linking into pages on an external site is at best fragile. I prefer 
> we do
> not do this because they are:
> 
> 1. Nice but not critical
> 
> 2. Create additional maintenance because someone needs to maintain the 
> links to
> make sure they are valid for each release. I have no idea how that can be 
> done
> and as the person handling releases I have no interest in doing this 
> however I
> have an interest in providing clean and stable releases
> 
> 3. Archived in a release and the referenced web site can and will change 
> their
> internal structure breaking a long life release. The referenced websites 
> have
> done this a number of times in the past
> 
> I am sorry to have to raise this. I did consider us holding an offline 
> copy of
> cppreference.com <http://cppreference.com> on ftp.rtems.org
> <http://ftp.rtems.org> however the open group site makes that hard
> because it is an exception. I am happy to hear about alternative solution?
> 
> 
> The Open Group has perma-links to specific POSIX versions and pages. If we 
> just
> want the latest version of a standard page, that's different.

That would work but in looking at the documentation and the links I still
question the value given the issues it raises. Is the overhead and work worth
what it gives us? Check `clock_settime()` in ...

https://docs.rtems.org/branches/master/c-user/clock/directives.html#rtems-clock-set

I normally just use `man` but I suspect that is just me.

> Give me an example and the goal and I will get some guidance for those.

https://docs.rtems.org/branches/master/c-user/message/directives.html#rtems-message-queue-broadcast

Then a `NULL`. Looking at this the `NULL` is a link but `buffer` is not and that
is confusing but that is the style. If the `NULL` link is broken that would be
frustrating.

Also why not also link `size_t`, `uint32_t` etc?

The fact the link jumps you out to an external site may not be liked by some.
What about those users who are required to be offline?

> Cppreference.com may have a similar permanence but I don't know. We could ask.

Asking would be great.

A halfway point maybe a glossary entry that shows the link and users can see the
jump is external?

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

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 8/11/21 5:29 pm, Sebastian Huber wrote:
> On 25/10/2021 19:50, Sebastian Huber wrote:
>> On 19/10/2021 17:25, Sebastian Huber wrote:
>>> Add new clock manager directives to get all times provided by the
>>> timehands.
>>>
>>> Update #4527.
>>> ---
>>> For an updated document to review see:
>>>
>>> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
>>>
>>> v2: Clarify boot time.
>>
>> Any comments with respect to the new clock manager directives?
> 
> If I get no objections, I will commit this on Wednesday.

We need to discuss and resolve the use of external links to specific pages in
our documentation.

I have just seen the links to opengroup.org and cppreference.com in the patch
and was going to comment however a check of the existing documentation shows:

$ grep -r cppreference `find . -name \*.rst` | wc -l
 164

$ grep -r opengroup.org `find . -name \*.rst` | wc -l
  11

It looks like I have missed this happening in the past. I think we need to
handle what happens with these external links because it now blocks a 6 release.

Deep linking into pages on an external site is at best fragile. I prefer we do
not do this because they are:

1. Nice but not critical

2. Create additional maintenance because someone needs to maintain the links to
make sure they are valid for each release. I have no idea how that can be done
and as the person handling releases I have no interest in doing this however I
have an interest in providing clean and stable releases

3. Archived in a release and the referenced web site can and will change their
internal structure breaking a long life release. The referenced websites have
done this a number of times in the past

I am sorry to have to raise this. I did consider us holding an offline copy of
cppreference.com on ftp.rtems.org however the open group site makes that hard
because it is an exception. I am happy to hear about alternative solution?

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

Re: [PATCH RSB v3] rtems-kernel: Implement kernel recipe using waf

[Chris Johns]

OK and thanks

Chris

On 5/11/21 1:31 am, Ryan Long wrote:
> Closes #4145
> ---
>  rtems/config/tools/rtems-kernel-6.cfg   |   6 +-
>  rtems/config/tools/rtems-kernel-common.cfg  | 125 +++
>  source-builder/sb/rtems-kernel-config-check | 147 
> 
>  3 files changed, 215 insertions(+), 63 deletions(-)
>  create mode 100755 source-builder/sb/rtems-kernel-config-check
> 
> diff --git a/rtems/config/tools/rtems-kernel-6.cfg 
> b/rtems/config/tools/rtems-kernel-6.cfg
> index f1d0990..9120862 100644
> --- a/rtems/config/tools/rtems-kernel-6.cfg
> +++ b/rtems/config/tools/rtems-kernel-6.cfg
> @@ -2,10 +2,10 @@
>  # RTEMS 5
>  #
>  
> -%define rtems_kernel_version 3ec5f20484cc4201e1d7b87844505644533b6148
> -%hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
> -  
> BjMKrf5n1YR6IpiZrY5TUEzKATPRJxA2/6m6f833DdRu+RyLxccXqA4gHRdVUqFelFNQ3o0XdG4o1naBKYfhkQ==
> +%define rtems_kernel_version 3bb97a30b17b6c138dead3e3a6b329c3b301cdb3
>  
> +%hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.gz \
> +  
> m/ogwrJj4X60ewDIbV6WRj1MJa/22gQHQd56XiNMfvCr0nsvcXdkXKAObLIGYIGYfUyEwlVk3SRjjRFkFalDGQ==
>  #
>  # The RTEMS build instructions.
>  #
> diff --git a/rtems/config/tools/rtems-kernel-common.cfg 
> b/rtems/config/tools/rtems-kernel-common.cfg
> index 157c7a4..431fc1d 100644
> --- a/rtems/config/tools/rtems-kernel-common.cfg
> +++ b/rtems/config/tools/rtems-kernel-common.cfg
> @@ -9,7 +9,7 @@
>  # and BSPs. Only after the source to download.
>  #
>  %if %{_dry_run} && %{defined with_download}
> - %log Kenrel configuration errors ignored
> + %log Kernel configuration errors ignored
>   %define rtems_kernel_error 0
>  %else
>   %define rtems_kernel_error 1
> @@ -19,10 +19,15 @@
>   %define rtems_kernel_version %{rsb_version}
>  %endif
>  
> +%if %{defined with_rtems_bsp_config}
> + %define _target %(%{_sbdir}/sb/rtems-kernel-config-check -v 
> %{rtems_version} -t %{with_rtems_bsp_config})
> + %define rtems_bsp %(%{_sbdir}/sb/rtems-kernel-config-check -b 
> %{with_rtems_bsp_config})
> +%endif
> +
>  #
>  # The target. It could be set in rtems_target.
>  #
> -%if %{defined rtems_target}
> +%if %{defined rtems_target} && !%{defined with_rtems_bsp_config}
>   %define _target %{rtems_target}
>  %endif
>  %if %{_target} == %{nil} && %{rtems_kernel_error}
> @@ -32,10 +37,21 @@
>  #
>  # The BSP.
>  #
> -%if !%{defined with_rtems_bsp} && %{rtems_kernel_error}
> +%if !%{defined with_rtems_bsp} && %{rtems_kernel_error} && !%{defined 
> with_rtems_bsp_config}
>   %error No RTEMS BSP specified: --with-rtems-bsp=bsp
>  %endif
> -%define rtems_bsp %{with_rtems_bsp}
> +%if !%{defined with_rtems_bsp_config}
> + %define rtems_bsp %{with_rtems_bsp}
> +%endif
> +
> +#
> +# Configuration file used with waf
> +#
> +%ifn %{defined with_rtems_bsp_config}
> + %define config_file config-%{_target}-%{rtems_bsp}.ini
> +%else
> + %define config_file %{with_rtems_bsp_config}
> +%endif
>  
>  #
>  # If no tools are provided use the prefix.
> @@ -98,14 +114,6 @@ URL:   https://www.rtems.org/
>   %define rtems_posix 0
>  %endif
>  
> -%if %{defined with_rtems_legacy_network}
> - %define rtems_networking 1
> -%endif
> -
> -%if %{defined with_rtems_cxx}
> - %define rtems_cxx 1
> -%endif
> -
>  %if %{defined with_rtems_bspopts}
>   %define bspopts %{with_rtems_bspopts}
>  %endif
> @@ -143,43 +151,43 @@ URL: https://www.rtems.org/
>  # --without-rtems-tests  : Supported, forced to no
>  # --with-rtems-smp   : Supported
>  # --without-rtems-smp: Don't care
> -# --with-rtems-legacy-network: Supported
> +# --with-rtems-legacy-network: Unsupported
>  # --without-rtems-legacy-network : Don't care
> -# --with-rtems-bspopts   : Supported, quote for a list
> -# --without-rtems-bspopts: Don't care
> -#
>  %if %{defined without_rtemsbsp}
>   %error Option --without-rtemsbsp is not supported.
>  %endif
> +%if %{defined with_rtems_legacy_network}
> + echo "RTEMS legacy network has been removed."
> + echo "Please review and update your configuration."
> + exit 1
> +%endif
> +%if %{defined enable_cxx}
> + echo CXX has been removed."
> + echo "Please review and update your configuration."
> + exit 1
> +%endif
> +
>  %if %{defined without_rtems_tests}
> - %define with_rtems_tests no
> + %define rtems_tests False
> + %define rtems_sample_tests False
>  %endif
>  %if %{defined with_rtems_tests}
>   %if %{with_rtems_tests} == 1
> -  %define with_rtems_tests yes
> +   %define rtems_tests True
> +   %define rtems_sample_tests True
>   %endif
> - %if %{with_rtems_tests} == yes || \
> - %{with_rtems_tests} == no || \
> - %{with_rtems_tests} == samples
> -  %define rtems_tests %{with_rtems_tests}
> +  %if %{with_rtems_tests} == samples
> +  %define rtems_tests False
> +  %define rtems_sample_tests True
>   %endif
>  %endif
>  %if %{defined with_rtems_smp}
>   %define rtems_smp 1
>  %endif
> -%if %{defined 

[RBW] Re: Philly Bike Expo 2021

[JohnS]

Thanks Pam, should be good time.

On Thursday, November 4, 2021 at 10:18:54 PM UTC-4 Pam Bikes wrote:

> I'll look for you.  Can't wait to meet you and see your bike.
>
> On Thursday, November 4, 2021 at 1:49:28 PM UTC-4 JohnS wrote:
>
>> Saturday's weather forecast is sunny and mid-50's, should be great riding 
>> weather to/from the Expo!
>>
>> BTW, I'm planning to wear my light blue peace wheel shirt and will have 
>> my shop sack slung over my shoulder.
>>
>> Hope to meet up with the ROB members when I'm there,
>> JohnS
>>
>> On Wednesday, November 3, 2021 at 5:55:46 PM UTC-4 cycli...@gmail.com 
>> wrote:
>>
>>> Filled with envy.  Enjoy!
>>>
>>> On Wednesday, November 3, 2021 at 2:44:33 PM UTC-7 Pam Bikes wrote:
>>>
>>>> 2 more things to note:
>>>> Ride your bike to the Expo and stop by the Cycling Savvy Booth and show 
>>>> (or buy) a Bike Benefits sticker and get a raffle ticket to win some fun 
>>>> prizes.  I'm bringing small things I carry on my bike like a John's Irish 
>>>> strap as a prize for example.
>>>>
>>>> Sat night I've invited the Riv folks to dinner.  Everyone is welcome to 
>>>> join.  We'll need to plan a time and place.  Let me know if you're coming 
>>>> and if you have food restrictions, preferences.  If folks are on foot, let 
>>>> us know so we can stay close by.  I don't have a phone but if I'm in wifi 
>>>> I 
>>>> can get messages (980 288 4801 <(980)%20288-4801>) and email.  If 
>>>> someone would like to take charge on this, please do.
>>>>
>>>> Sun - I'll be presenting at 1:30.  Please come see me and my Betty.
>>>>
>>>> I hope to see y'all there.
>>>>
>>>> On Wednesday, October 27, 2021 at 1:37:41 PM UTC-4 Pam Bikes wrote:
>>>>
>>>>> I'm presenting and leading a ride in Philly.  Please all come and 
>>>>> bring your Rivs.  I'm bringing my Betty on the train.  The ride is Sat at 
>>>>> 7:30 near Girard/Kelly.
>>>>> https://phillybikeexpo.com/unracer-roll-to-pbe21/
>>>>> The presentation is Sun at 1:30.  
>>>>> I hope to see lots of Rivs in Philly.
>>>>> Here's the link to the whole weekend.  https://phillybikeexpo.com/
>>>>>
>>>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/270c9831-3359-4728-a0a7-b740954262f8n%40googlegroups.com.

[RBW] Re: Philly Bike Expo 2021

[JohnS]

Saturday's weather forecast is sunny and mid-50's, should be great riding 
weather to/from the Expo!

BTW, I'm planning to wear my light blue peace wheel shirt and will have my 
shop sack slung over my shoulder.

Hope to meet up with the ROB members when I'm there,
JohnS

On Wednesday, November 3, 2021 at 5:55:46 PM UTC-4 cycli...@gmail.com wrote:

> Filled with envy.  Enjoy!
>
> On Wednesday, November 3, 2021 at 2:44:33 PM UTC-7 Pam Bikes wrote:
>
>> 2 more things to note:
>> Ride your bike to the Expo and stop by the Cycling Savvy Booth and show 
>> (or buy) a Bike Benefits sticker and get a raffle ticket to win some fun 
>> prizes.  I'm bringing small things I carry on my bike like a John's Irish 
>> strap as a prize for example.
>>
>> Sat night I've invited the Riv folks to dinner.  Everyone is welcome to 
>> join.  We'll need to plan a time and place.  Let me know if you're coming 
>> and if you have food restrictions, preferences.  If folks are on foot, let 
>> us know so we can stay close by.  I don't have a phone but if I'm in wifi I 
>> can get messages (980 288 4801 <(980)%20288-4801>) and email.  If 
>> someone would like to take charge on this, please do.
>>
>> Sun - I'll be presenting at 1:30.  Please come see me and my Betty.
>>
>> I hope to see y'all there.
>>
>> On Wednesday, October 27, 2021 at 1:37:41 PM UTC-4 Pam Bikes wrote:
>>
>>> I'm presenting and leading a ride in Philly.  Please all come and bring 
>>> your Rivs.  I'm bringing my Betty on the train.  The ride is Sat at 7:30 
>>> near Girard/Kelly.
>>> https://phillybikeexpo.com/unracer-roll-to-pbe21/
>>> The presentation is Sun at 1:30.  
>>> I hope to see lots of Rivs in Philly.
>>> Here's the link to the whole weekend.  https://phillybikeexpo.com/
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/3936f0e5-dda9-45d9-b617-c99f4b60abd9n%40googlegroups.com.

Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf

[Chris Johns]

On 4/11/21 12:37 am, Ryan Long wrote:
> -Original Message-
> From: Chris Johns  
> Sent: Tuesday, November 2, 2021 5:14 PM
> To: Ryan Long ; devel@rtems.org
> Subject: Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf
> 
> On 3/11/21 4:13 am, Ryan Long wrote:
>>
>> -Original Message-
>> From: Chris Johns 
>> Sent: Monday, November 1, 2021 8:48 PM
>> To: Ryan Long ; devel@rtems.org
>> Subject: Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe 
>> using waf On 28/10/21 2:09 am, Ryan Long wrote:
>>> + %define rtems_bsp
>>> + %(%{_topdir}/../source-builder/rtems-kernel-config-check -b
>>> + %{with_rtems_bsp_config})
>>
>> How are config file errors handled? I normally return `ERROR` or something 
>> that can be checked.
>> [Ryan Long] Right now the script is handling all the errors. I'll add some 
>> error checking to rtems-kernel-common.cfg.
> 
> And if the helper script finds and error what happens to the RSB build?
> [Ryan Long] The build fails when an error is found on in the INI file by the 
> helper script. The error is printed out, so does error checking still need to 
> be added to rtems-kernel-common.cfg?

This founds fine to me. I was just checking this is being handled.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf

[Chris Johns]

On 3/11/21 4:13 am, Ryan Long wrote:
> 
> -Original Message-
> From: Chris Johns  
> Sent: Monday, November 1, 2021 8:48 PM
> To: Ryan Long ; devel@rtems.org
> Subject: Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf
> On 28/10/21 2:09 am, Ryan Long wrote:
>> + %define rtems_bsp 
>> + %(%{_topdir}/../source-builder/rtems-kernel-config-check -b 
>> + %{with_rtems_bsp_config})
> 
> How are config file errors handled? I normally return `ERROR` or something 
> that can be checked.
> [Ryan Long] Right now the script is handling all the errors. I'll add some 
> error checking to rtems-kernel-common.cfg.

And if the helper script finds and error what happens to the RSB build?

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

Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf

[Chris Johns]

True,  None,  False),
> +'--topdir': ('_topdir',   self._lo_path, 
> True,  None,  False),
> +'--configdir' : ('_configdir',self._lo_path, 
> True,  None,  False),
> +'--builddir'  : ('_builddir', self._lo_path, 
> True,  None,  False),
> +'--sourcedir' : ('_sourcedir',self._lo_path, 
> True,  None,  False),
> +'--patchdir'  : ('_patchdir', self._lo_path, 
> True,  None,  False),
> +'--tmppath'   : ('_tmppath',  self._lo_path, 
> True,  None,  False),
> +'--jobs'  : ('_jobs', self._lo_jobs, 
> True,  'max', True),
> +'--log'   : ('_logfile',  
> self._lo_string,   True,  None,  False),
> +'--url'   : ('_url_base', 
> self._lo_string,   True,  None,  False),
> +'--no-download'   : ('_disable_download', self._lo_bool, 
> False, '0',   True),
> +'--macros': ('_macros',   
> self._lo_string,   True,  None,  False),
> +'--source-only-download'  : ('_source_download',  self._lo_bool, 
> False, '0',   True),
> +'--targetcflags'  : ('_targetcflags', 
> self._lo_string,   True,  None,  False),
> +'--targetcxxflags': ('_targetcxxflags',   
> self._lo_string,   True,  None,  False),
> +'--libstdcxxflags': ('_libstdcxxflags',   
> self._lo_string,   True,  None,  False),
> +'--force' : ('_force',self._lo_bool, 
> False, '0',   True),
> +'--quiet' : ('_quiet',self._lo_bool, 
> False, '0',   True),
> +'--trace' : ('_trace',self._lo_bool, 
> False, '0',   True),
> +    '--dry-run'   : ('_dry_run',  self._lo_bool, 
> False, '0',   True),
> +'--warn-all'  : ('_warn_all', self._lo_bool, 
> False, '0',   True),
> +'--no-clean'  : ('_no_clean', self._lo_bool, 
> False, '0',   True),
> +'--keep-going': ('_keep_going',   self._lo_bool, 
> False, '0',   True),
> +'--always-clean'  : ('_always_clean', self._lo_bool, 
> False, '0',   True),
> +'--no-install': ('_no_install',   self._lo_bool, 
> False, '0',   True),
> +'--regression': ('_regression',   self._lo_bool, 
> False, '0',   True),
> +'--host'  : ('_host', 
> self._lo_triplets, True,  None,  False),
> +'--build' : ('_build',
> self._lo_triplets, True,  None,  False),
> +'--target': ('_target',   
> self._lo_triplets, True,  None,  False),
> +'--rtems-tools'   : ('_rtems_tools',  
> self._lo_string,   True,  None,  False),
> +'--rtems-bsp' : ('_rtems_bsp',
> self._lo_string,   True,  None,  False),

The documented method uses `--with-rtems-bsp=erc32 --with-rtems-tests=yes` ...

https://docs.rtems.org/branches/master/user/start/bsp-build.html#rsb-bsp-build

I prefer we do not changes this. See `--with-`:

https://docs.rtems.org/branches/master/user/rsb/commands.html#set-builder-sb-set-builder

The --with-* method avoids creating a dependency between package configs and the
commandline options, ie this source file.

Chris

> +'--rtems-version' : ('_rtems_version',
> self._lo_string,   True,  None,  False),
> +'--help'  : (None,self._lo_help, 
> False, None,  False)
>  }
>  
>  self.command_path = command_path
> @@ -203,40 +203,41 @@ class command_line:
>  print('%s: [options] [args]' % (self.command_name))
>  print('RTEMS Source Builder, an RTEMS Tools Project (c) 2012-2019 
> Chris Johns')
>  print('Options and arguments:')
> -print('--force: Force the build to proceed')
> -print('--quiet: Quiet output (not used)')
> -print('--trace: Trace the execution')
> -print('--dry-run  : Do everything but actually run the 
> build')
> -print('--warn-all : Generate warnings')
> -print('--no-clean : Do not clean up the build tree')
> -print('--always-clean : Always clean the build tree, even 
> with 

Re: [RBW] Re: Philly Bike Expo 2021

[JohnS]

So this is the route I'll be taking Saturday morning after breakfast at 
Bruno's, so leaving about 9:00. About 5 miles are on gravel. Not sure if 
I'll take the Quickbeam or my recently refreshed '82 Stumpjumper.

https://ridewithgps.com/routes/37909474

JohnS

On Thursday, October 28, 2021 at 2:40:24 PM UTC-4 Benjamin Kelley wrote:

> You all got me excited for PBE so I went and checked but SWA tickets from 
> KC are just too expensive for the last minute trip.
> I'll definitely plan better for next year.
>
> --ben
>
> On Thu, Oct 28, 2021 at 12:31 PM Roberta  wrote:
>
>> I'm looking forward to meeting new people and catching up with the ones I 
>> know.  Andy, I will miss you (we met two years ago).  There's something 
>> about knowing who you're writing to that makes these prose interactions 
>> come alive.
>>
>> Also, I'll be on my  Platy, too, for Pam's ride, so won't make it to 
>> John's breakfast.  Kate, looking forward to hearing about your biking 
>> adventures in Europe and Michigan.
>>
>> Roberta
>>
>> On Thursday, October 28, 2021 at 5:12:51 AM UTC-4 ascpgh wrote:
>>
>>> Please take lots of pictures. 
>>>
>>> Seeing the riders and their bikes would be great, pictures of 
>>> exhibitors' things too! Rivendell is going to be there and I know they were 
>>> impressed by the receptive crowds and embrace of fellow exhibitors so far 
>>> from home last time. 
>>>
>>> I know this year has been hard on many folks at all levels in the bike 
>>> business and this was such a good event two years ago, I hope its 
>>> restorative vibes are rewarding to all. There was a much more palpable 
>>> sense of kinship among cyclists there than I ever noticed or felt at 
>>> InterBike.
>>>
>>> Sad to miss out this year and will be checking out everyones'' postings, 
>>> participating vicariously.
>>>
>>> Andy Cheatham
>>> Pittsburgh
>>>
>>> On Wednesday, October 27, 2021 at 10:52:27 PM UTC-4 Roberta wrote:
>>>
>>>> I will be there for both your ride (unless it's raining too hard ) and 
>>>> at the show both days, including your session. I’m looking forward to 
>>>> meeting you and others from the board. Perhaps we could all meet at noon 
>>>> at 
>>>> Riv’s booth?  
>>>>
>>>> Girard street at Kelly drive is overhead, a bridge. 
>>>>
>>>> I live downtown Philly, so if anyone needs local info, I’m happy to 
>>>> help. 
>>>>
>>>> Roberta
>>>> On Wednesday, October 27, 2021 at 1:37:41 PM UTC-4 Pam Bikes wrote:
>>>>
>>>>> I'm presenting and leading a ride in Philly.  Please all come and 
>>>>> bring your Rivs.  I'm bringing my Betty on the train.  The ride is Sat at 
>>>>> 7:30 near Girard/Kelly.
>>>>> https://phillybikeexpo.com/unracer-roll-to-pbe21/
>>>>> The presentation is Sun at 1:30.  
>>>>> I hope to see lots of Rivs in Philly.
>>>>> Here's the link to the whole weekend.  https://phillybikeexpo.com/
>>>>>
>>>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "RBW Owners Bunch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rbw-owners-bun...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/rbw-owners-bunch/1e9ed4bf-cfa6-4b86-bc81-c2d05637c257n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/rbw-owners-bunch/1e9ed4bf-cfa6-4b86-bc81-c2d05637c257n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/688052ba-5a0a-4197-a4cd-e0d576040b5en%40googlegroups.com.

Re: [PATCH v1 0/8] Add AArch64 libdebugger support

[Chris Johns]

On 30/10/21 8:17 am, Kinsey Moore wrote:
> This patch set adds libdebugger support to AArch64 and resolves several
> bugs found along the way.

Looks good and OK to push.

Kinsey. really nice work :)

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB] Update to dtc 1.6.1

[Chris Johns]

On 29/10/21 6:26 am, Joel Sherrill wrote:
> On Thu, Oct 28, 2021 at 12:20 PM Hesham Almatary
>  wrote:
>>
>> Does RISC-V need that too?
> 
> Not based on the current bsets.
> 
> $ grep -r dtc *
> 6/rtems-moxie.bset:devel/dtc-1.6.0-1
> 6/rtems-microblaze.bset:devel/dtc-1.6.0-1
> 7/rtems-moxie.bset:devel/dtc-1.6.0-1
> 
> Alex.. the grep shows that 7/microblaze is out of sync. Please address that.
> 
> Hesham.. if riscv needs dtc, it should be added to its bset for 6 and 7.

Should we add DTC to the default package set and avoid the need to manage what
needs it?

The rational is the growing use of FDT in RTEMS and this lets us control what we
need on a per release basis. For example 5 years from now DTC has changed and
RTEMS today does not work with it.

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

Re: [PATCH rtems-tools] rtems-bsp-builder: Fix mail support

[Chris Johns]

OK

Thanks
Chris

On 29/10/21 7:01 am, Alex White wrote:
> This fixes a problem with mailer options support that occurred because
> check.py uses argparse.ArgumentParser instead of tester.rt.options.
> ---
>  rtemstoolkit/mailer.py |  2 +-
>  tester/rt/check.py | 17 -
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
> index 085a2ce..32cbc23 100644
> --- a/rtemstoolkit/mailer.py
> +++ b/rtemstoolkit/mailer.py
> @@ -70,7 +70,7 @@ class mail:
>  def __init__(self, opts):
>  self.opts = opts
>  self.gitconfig_lines = None
> -if opts.find_arg('--use-gitconfig') is not None:
> +if self._get_arg('--use-gitconfig'):
>  # Read the output of `git config --list` instead of reading the
>  # .gitconfig file directly because Python 2 ConfigParser does not
>  # accept tabs at the beginning of lines.
> diff --git a/tester/rt/check.py b/tester/rt/check.py
> index c01c25d..ec92e7e 100755
> --- a/tester/rt/check.py
> +++ b/tester/rt/check.py
> @@ -105,7 +105,22 @@ def title():
>  return 'RTEMS Tools Project - RTEMS Kernel BSP Builder, %s' % 
> (version.string())
>  
>  def command_line():
> -return wrap(('command: ', ' '.join(sys.argv)), lineend = '\\')
> +# Filter potentially sensitive mail options out.
> +filtered_args = [
> +arg for arg in sys.argv
> +if all(
> +smtp_opt not in arg
> +for smtp_opt in [
> +'--smtp-host',
> +'--mail-to',
> +'--mail-from',
> +'--smtp-user',
> +'--smtp-password',
> +'--smtp-port'
> +]
> +)
> +]
> +return wrap(('command: ', ' '.join(filtered_args)), lineend = '\\')
>  
>  def jobs_option_parse(jobs_option):
>  try:
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel