Re: [PATCH] aarch64: Add tests that are failing intermittently
On 21/8/21 2:38 am, Kinsey Moore wrote: > On 8/19/2021 18:03, Chris Johns wrote: >> On 20/8/21 4:55 am, Kinsey Moore wrote: >>> On 8/19/2021 13:32, Gedare Bloom wrote: On Thu, Aug 19, 2021 at 11:43 AM Kinsey Moore wrote: > I've seen these failures on my local system, in our CI, and on a build > server that I sometimes > use for development/testing so if it's a configuration issue we're being > pretty consistent about > misconfiguration across some pretty different environments (docker, > bare-metal, VM, different > OSs, different QEMU versions). I've seen enough of the spintrcritical > tests fail sporadically on > QEMU to lump them all into this category. These are also tests that I > have seen behave badly > on ARMv7 QEMU on my local system (which doesn't rule out > misconfiguration, but it's another > data point). > Yes, for example, it may be a matter of qemu process counts spawned by rtems-test, and the order in which tests get invoked could be a cause for which ones don't work. I could easily see this happening, since each test runtime will be fairly consistent, so you'll often see the same tests running concurrently with each other. But, if you change the order (e.g., by adding new tests), then we may see a new set of sporadically failing testcases, will we just add those, or do we need to re-examine this indetermine set periodically? Who will maintain this list? That's kind of the root of my concern here. >>> I understand your concern about maintenance of the failure list and I don't >>> have a good answer for you. I imagine going forward it would be a >>> combination >>> of the current stake-holders for a given BSP and anyone who watches the >>> automated build output from Joel's runs for these kinds of issues. >>> >>> On the other hand if we don't mark those tests, people will get fatigued >>> looking at the spurious failures and assume any new ones just fall into the >>> same category as others. At that point is it even worth running the >>> automated tests for that platform? >>> > As far as your worry about marking these indeterminate, they're only > being marked as such for > QEMU BSPs. The ZynqMP hardware BSP doesn't have these testing carve-outs > and runs all these tests flawlessly. >> Great, this is important. >> > These failures become much more common when there is otherwise load on > the system and a > lot of them disappear when you limit the tester to a single QEMU > instance at a time. > I'm wondering if we should sacrifice testing speed for coverage/quality. If throttling rtems-test leads to more reliable test results, then it may be a better option than basically ignoring a swath of our testsuite. >>> That would certainly mitigate some of the failures, but you'd also have to >>> guarantee nothing else is running on the system which could cause the same >>> problem. I know at least some of the current automated runs operate on a >>> shared system which can and does often have other intensive processes >>> running on it. There are also the tests that are sporadic on QEMU even >>> without additional load. >> What is it in these tests when combined with qemu that causes the tests to >> fail? >> Is there some relation to a real clock, some shared host resource or a bug in >> qemu? I am concerned a simulator can vary like this based on the host's load >> and >> it makes me wonder how people use it on machines to host a number VMs. > I experienced very similar results on an ARMv7 BSP (not Zynq) and assumed > that this > was a known/accepted problem with QEMU when the same issues popped up on > AArch64. I think we have just ignored issue. I know I have ignored it because of the rabbit hole it is. > My local system under no other load produces these failures for the > Zynq A9 QEMU > BSP: > > "failed": [ > "spcpucounter01.exe", > "psxtimes01.exe", > "sp69.exe", > "psx12.exe", > "minimum.exe", > "dl06.exe", > "sptimecounter02.exe" > ], > > minimum.exe We have discussed this test in the past and I think the end result from Joel was an exit code of 0 meant it had passed but I am not sure the exit code is printed because it is minimal. Maybe it should be changed to be a `no-run` type test? > and dl06.exe are probably unrelated, Yeap and that is one I should fix when I can find the time. > but the remainder are in my problem set for AArch64 on QEMU. OK. > A run of the AArch64 ZynqMP ILP32 BSP produced these failures under the same > conditions with all the test carve-outs removed: > > "failed": [ > "psx12.exe", > "spcpucounter01.exe", > "sptimecounter01.exe", > "sptimecounter02.exe", > "sp04.exe" > ], > > Because of my experience with the
Re: [PATCH] gdb: prefere python3 if it is installed
On 21/8/21 4:08 am, o...@c-mauderer.de wrote: > Started to test both (MSYS2 and Cygwin) and I start to suspect that our manual > needs some minor updates. I'm taking notes ... Oh awesome, I am sooo grateful. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] gdb: prefere python3 if it is installed
On 20/08/2021 18:24, Gedare Bloom wrote: On Fri, Aug 20, 2021 at 2:02 AM Chris Johns wrote: On 20/8/21 5:42 pm, Christian MAUDERER wrote: Am 20.08.21 um 09:02 schrieb Chris Johns: On 20/8/21 4:48 pm, Christian MAUDERER wrote: Hello, Am 20.08.21 um 03:49 schrieb Chris Johns: On 20/8/21 3:16 am, Joel Sherrill wrote: On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom wrote: I have no problem with this. I think it is sensible to look for python3 before python2. At some point we'll have to stop looking for python2 :) That is further in the future than I would have thought based on the CentOS project changes. I still see user organizations with no plans to move off CentOS 7. It will receive maintenance updates through 2024-06-30. But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't that bad. I had to test something on a true 32-bit distribution this week and even CentOS 7 (i386) wasn't as painful as I expected to setup. There will come a time when a change made cannot be easily tested by us on python2 and that will in effect end our support. We are not there yet. STOP. Please do not do this again. That discussion took a wrong direction. We discussed deprecating python2 a few times and I know that we will not do it before the big long living distributions drop it. I can live with that and I don't want to re-start this discussion with this patch. If Joel feels the need to make this statement he can and he has more than earned the right to do so. His work and those he supports is important. Sorry, I didn't want to offend you, Joel or Gedare. I had that with discussions before that the original idea (here: giving priority to python3 over python2 when building gdb) started to be buried by a similar but slightly different one which has been already discussed multiple times (here: deprecating python2). I wanted to avoid that. I should have worded that different. I'm sorry if I have offended you, Joel or Gedare or anyone else. Thanks and none taken. I am clear on the focus of your posts so it is ok. :) It would be fine without the STOP. Totally acceptable to express your opinion and request that we not bikeshed your patch, we just want to keep the tone of the list in the right direction which we all know can be challenging in virtual, international communications. We understand the intent here, but we just want to make sure to keep the list friendly to all (who may lack some of our context). Thanks! Yes, again: sorry. "Let's deprecate python2" is a dangerous topic that has the tendency to start really long discussions. I pannicked a bit there that it would hide the topic that I had in mind. I used the wrong tone to express that. I'll try to be more careful in the future. On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER wrote: PS: I had the problem on the 5 branch of RTEMS source builder. I think we should apply a patch to both: master and the 5 branch. Am 19.08.21 um 10:34 schrieb Christian Mauderer: More and more systems stop shipping python2. So we should start to prefer python3 over python2. For building gdb it is not only necessary to have a python binary installed, but also the matching python-devel packet. On a lot of hosts that will now be more often python3-devel and not python2-devel. --- Note: Please see that patch more as an suggestion / base for discussion. I'm open to better solutions. My problem that triggered this patch was a build of a toolchain on a github CI/CD system that has been originally set up by one of our users (see [1] for the log). It seems that on the "macos-latest" machines a python2 is installed but no python2 headers are found. I have just built the latest RSB master GDB on a fully updated MacOS (Big Sur): config: tools/rtems-gdb-10.cfg package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB (installed: 19.586MB) cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml I support the latest MacOS with Xcode and have a dedicated Mac machine that tracks the current RSB. It had wedged itself and I have cleared that so it is now building the latest. So do I understand that correct: This is a "clean" Mac with no additional python installs or similar and it worked? What python versions are available on this this machine? It is working for me and I have not looked into it any more. If I did understand you correctly, it seems that github has made some odd choices about their default config for the macos-latest machines. They seem to have python2 but no devel headers. You will need to raise that with them. Yes, of course. I didn't want to raise it as a problem here. It was more a statement than
Re: [PATCH] aarch64: Add tests that are failing intermittently
On 8/19/2021 18:03, Chris Johns wrote: On 20/8/21 4:55 am, Kinsey Moore wrote: On 8/19/2021 13:32, Gedare Bloom wrote: On Thu, Aug 19, 2021 at 11:43 AM Kinsey Moore wrote: I've seen these failures on my local system, in our CI, and on a build server that I sometimes use for development/testing so if it's a configuration issue we're being pretty consistent about misconfiguration across some pretty different environments (docker, bare-metal, VM, different OSs, different QEMU versions). I've seen enough of the spintrcritical tests fail sporadically on QEMU to lump them all into this category. These are also tests that I have seen behave badly on ARMv7 QEMU on my local system (which doesn't rule out misconfiguration, but it's another data point). Yes, for example, it may be a matter of qemu process counts spawned by rtems-test, and the order in which tests get invoked could be a cause for which ones don't work. I could easily see this happening, since each test runtime will be fairly consistent, so you'll often see the same tests running concurrently with each other. But, if you change the order (e.g., by adding new tests), then we may see a new set of sporadically failing testcases, will we just add those, or do we need to re-examine this indetermine set periodically? Who will maintain this list? That's kind of the root of my concern here. I understand your concern about maintenance of the failure list and I don't have a good answer for you. I imagine going forward it would be a combination of the current stake-holders for a given BSP and anyone who watches the automated build output from Joel's runs for these kinds of issues. On the other hand if we don't mark those tests, people will get fatigued looking at the spurious failures and assume any new ones just fall into the same category as others. At that point is it even worth running the automated tests for that platform? As far as your worry about marking these indeterminate, they're only being marked as such for QEMU BSPs. The ZynqMP hardware BSP doesn't have these testing carve-outs and runs all these tests flawlessly. Great, this is important. These failures become much more common when there is otherwise load on the system and a lot of them disappear when you limit the tester to a single QEMU instance at a time. I'm wondering if we should sacrifice testing speed for coverage/quality. If throttling rtems-test leads to more reliable test results, then it may be a better option than basically ignoring a swath of our testsuite. That would certainly mitigate some of the failures, but you'd also have to guarantee nothing else is running on the system which could cause the same problem. I know at least some of the current automated runs operate on a shared system which can and does often have other intensive processes running on it. There are also the tests that are sporadic on QEMU even without additional load. What is it in these tests when combined with qemu that causes the tests to fail? Is there some relation to a real clock, some shared host resource or a bug in qemu? I am concerned a simulator can vary like this based on the host's load and it makes me wonder how people use it on machines to host a number VMs. I experienced very similar results on an ARMv7 BSP (not Zynq) and assumed that this was a known/accepted problem with QEMU when the same issues popped up on AArch64. My local system under no other load produces these failures for the Zynq A9 QEMU BSP: "failed": [ "spcpucounter01.exe", "psxtimes01.exe", "sp69.exe", "psx12.exe", "minimum.exe", "dl06.exe", "sptimecounter02.exe" ], minimum.exe and dl06.exe are probably unrelated, but the remainder are in my problem set for AArch64 on QEMU. A run of the AArch64 ZynqMP ILP32 BSP produced these failures under the same conditions with all the test carve-outs removed: "failed": [ "psx12.exe", "spcpucounter01.exe", "sptimecounter01.exe", "sptimecounter02.exe", "sp04.exe" ], Because of my experience with the aforementioned ARMv7 BSP and the lack of failures on hardware, I chose not to weed out the root cause of the failures under QEMU. This patch is documentation of our observations across multiple architectures and BSPs running on QEMU more than anything else. I feel with this volume of tests being tagged this way we should have a better understanding of the problem and so a means to track or not track how to resolve it. As Gedare has kindly stated once pushed this change disappears into a dark corner and we have no means to track it. The other solution is to set `jobs` to `1` in this BSP's tester config, again something Gedare has raised. It means we get better or even valid results. What is more important, valid results or running the testsuite as fast as possible? I fully support dropping the
Re: [PATCH 5/5] score: Delete unused rtems_ada_self
these 5 look fine to me
On Mon, Aug 16, 2021 at 5:15 AM Sebastian Huber
wrote:
>
> ---
> cpukit/include/rtems/score/threadimpl.h | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/threadimpl.h
> b/cpukit/include/rtems/score/threadimpl.h
> index 45c0795d9c..f25e347e33 100644
> --- a/cpukit/include/rtems/score/threadimpl.h
> +++ b/cpukit/include/rtems/score/threadimpl.h
> @@ -74,11 +74,6 @@ typedef struct {
> */
> extern Thread_Zombie_registry _Thread_Zombies;
>
> -/**
> - * Self for the GNU Ada Run-Time
> - */
> -extern void *rtems_ada_self;
> -
> /**
> * @brief Object identifier of the global constructor thread.
> *
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] eng: Document use of BSP family for defaults
ok On Wed, Aug 18, 2021 at 3:29 AM Sebastian Huber wrote: > > Update #4468. > --- > eng/build-system.rst | 4 ++-- > eng/req/items.rst| 8 ++-- > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/eng/build-system.rst b/eng/build-system.rst > index e76b606..030679d 100644 > --- a/eng/build-system.rst > +++ b/eng/build-system.rst > @@ -355,8 +355,8 @@ Add a Base BSP to a BSP Family > items ``spec:/build/bsps/arch/family/bsprst``, > ``spec:/build/bsps/arch/family/bspuvw``, and > ``spec:/build/bsps/arch/family/bspxyz`` just define the name of the base > -BSP and set a link to the group item. The base BSP names can be used for > -example in the ``default-by-variant`` attribute of > +BSP and set a link to the group item. The base BSP and BSP family names > +can be used for example in the ``default-by-variant`` attribute of > :ref:`SpecTypeBuildOptionItemType` items. The items linked by the BSP > items are shown using relative UIDs. > > diff --git a/eng/req/items.rst b/eng/req/items.rst > index e7727aa..51f3c3d 100644 > --- a/eng/req/items.rst > +++ b/eng/req/items.rst > @@ -719,8 +719,11 @@ default > > default-by-variant > The attribute value shall be a list. Each list element shall be a > -:ref:`SpecTypeBuildOptionDefaultByVariant`. The list is processed from > top > -to bottom. If a matching variant is found, then the processing stops. > +:ref:`SpecTypeBuildOptionDefaultByVariant`. The list is checked two times > +and processed from top to bottom. Firstly, the base BSP name is used to > +match with a variant. Secondly, the BSP family name prefixed by ``bsps/`` > +is used to match with a variant. If a matching variant is found, then > the > +processing stops. > > description > The attribute value shall be an optional string. It shall be the > @@ -750,6 +753,7 @@ Please have a look at the following example: > default-by-variant: > - value: 9600 >variants: > + - bsps/powerpc/motorola_powerpc >- m68k/m5484FireEngine >- powerpc/hsc_cm01 > - value: 19200 > -- > 2.26.2 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] gdb: prefere python3 if it is installed
On Fri, Aug 20, 2021 at 2:02 AM Chris Johns wrote: > > On 20/8/21 5:42 pm, Christian MAUDERER wrote: > > Am 20.08.21 um 09:02 schrieb Chris Johns: > >> On 20/8/21 4:48 pm, Christian MAUDERER wrote: > >>> Hello, > >>> > >>> Am 20.08.21 um 03:49 schrieb Chris Johns: > On 20/8/21 3:16 am, Joel Sherrill wrote: > > On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom wrote: > >> > >> I have no problem with this. I think it is sensible to look for > >> python3 before python2. At some point we'll have to stop looking for > >> python2 :) > > > > That is further in the future than I would have thought based on the > > CentOS project changes. I still see user organizations with no plans > > to move off CentOS 7. It will receive maintenance updates through > > 2024-06-30. > > > > But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't > > that bad. I had to test something on a true 32-bit distribution this > > week > > and even CentOS 7 (i386) wasn't as painful as I expected to setup. > > There will come a time when a change made cannot be easily tested by us > on > python2 and that will in effect end our support. We are not there yet. > >>> > >>> STOP. > >> > >> Please do not do this again. > >> > >> That discussion took a wrong direction. We discussed deprecating python2 a > >>> few times and I know that we will not do it before the big long living > >>> distributions drop it. I can live with that and I don't want to re-start > >>> this > >>> discussion with this patch. > >> > >> If Joel feels the need to make this statement he can and he has more than > >> earned > >> the right to do so. His work and those he supports is important. > > > > Sorry, I didn't want to offend you, Joel or Gedare. > > > > I had that with discussions before that the original idea (here: giving > > priority > > to python3 over python2 when building gdb) started to be buried by a > > similar but > > slightly different one which has been already discussed multiple times > > (here: > > deprecating python2). I wanted to avoid that. > > > > I should have worded that different. I'm sorry if I have offended you, Joel > > or > > Gedare or anyone else. > > Thanks and none taken. I am clear on the focus of your posts so it is ok. :) > It would be fine without the STOP. Totally acceptable to express your opinion and request that we not bikeshed your patch, we just want to keep the tone of the list in the right direction which we all know can be challenging in virtual, international communications. We understand the intent here, but we just want to make sure to keep the list friendly to all (who may lack some of our context). Thanks! > > > >> > >>> > > >> On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER > >> wrote: > >>> > >>> PS: I had the problem on the 5 branch of RTEMS source builder. I think > >>> we should apply a patch to both: master and the 5 branch. > >>> > >>> Am 19.08.21 um 10:34 schrieb Christian Mauderer: > More and more systems stop shipping python2. So we should start to > prefer python3 over python2. For building gdb it is not only > necessary > to have a python binary installed, but also the matching python-devel > packet. On a lot of hosts that will now be more often python3-devel > and not python2-devel. > --- > > Note: Please see that patch more as an suggestion / base for > discussion. I'm open to better solutions. > > My problem that triggered this patch was a build of a toolchain on a > github CI/CD system that has been originally set up by one of our > users (see [1] for the log). It seems that on the "macos-latest" > machines a python2 is installed but no python2 headers are found. > > I have just built the latest RSB master GDB on a fully updated MacOS > (Big Sur): > > config: tools/rtems-gdb-10.cfg > package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 > building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 > sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB > (installed: > 19.586MB) > cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 > reporting: tools/rtems-gdb-10.cfg -> > arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt > reporting: tools/rtems-gdb-10.cfg -> > arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml > > I support the latest MacOS with Xcode and have a dedicated Mac machine > that > tracks the current RSB. It had wedged itself and I have cleared that so > it is > now building the latest. > >>> > >>> So do I understand that correct: This is a "clean" Mac with no additional > >>> python > >>> installs or similar and it worked? What python versions are available on > >>> this > >>>
Re: [PATCH v4 0/2] Add MicroBlaze tools to RSB
On Thu, Aug 19, 2021 at 11:51 PM Chris Johns wrote: > > Hi Alex, > > These patches are OK to push. > > One minor point, the script sha512-base64 in the RSB creates a base64 > encoded > hash and that makes them smaller. I prefer we move to this more and more. I did that on my patches. Be happy you are teaching this old dog a new trick. :) --joel > > Chris > > On 19/8/21 1:34 pm, Alex White wrote: > > Hi, > > > > This patch set now depends on Joel's newlib hash bump and should be merged > > after > > it. > > > > v4: > > - Rename to rtems-xilinx-gcc-10-newlib-head.cfg > > - Simplify rtems-xilinx-gcc-10-newlib-head.cfg with include > > > > v3: > > - Follow naming convention for Xilinx .cfg files > > - Simplify rtems-xilinx-binutils-2.36.cfg with rtems-binutils-2.36.cfg > > include > > > > v2: > > - Add Xilinx QEMU version to .cfg filename > > - Exclude GDB configuration with unneeded Xilinx patches > > > > This patch set adds the MicroBlaze tools to rtems-source-builder. > > > > Thanks, > > > > Alex > > > > Alex White (2): > > rsb: Add MicroBlaze tools > > rsb: Add Xilinx QEMU > > > > bare/config/devel/qemu-xilinx-v2020.2-1.cfg | 23 ++ > > bare/config/devel/qemu-xilinx.bset| 24 ++ > > rtems/config/6/rtems-microblaze.bset | 23 +- > > .../tools/rtems-xilinx-binutils-2.36.cfg | 40 > > .../tools/rtems-xilinx-gcc-10-newlib-head.cfg | 46 +++ > > 5 files changed, 155 insertions(+), 1 deletion(-) > > create mode 100644 bare/config/devel/qemu-xilinx-v2020.2-1.cfg > > create mode 100644 bare/config/devel/qemu-xilinx.bset > > create mode 100644 rtems/config/tools/rtems-xilinx-binutils-2.36.cfg > > create mode 100644 rtems/config/tools/rtems-xilinx-gcc-10-newlib-head.cfg > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Using libbsd dhcpcd options
This stored as "/etc/dhcpcd.conf" might not be completely correct but it works. In the call-back hook you'll get a "new_root_path=" entry with what is set on the DHCP host. Thanks! static const char* dhcpcd_conf_text = \ "debug\n" "clientid\n" "nodhcp6\n" "ipv4only\n" "timeout 0\n" "interface ffec0\n" "option bootfile_name\n" "option root_path\n" "\n"; Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Using libbsd dhcpcd options
> On Aug 19, 2021, at 20:02 , Chris Johns wrote:
>
> On 20/8/21 1:45 am, junkes wrote:
>> Hallo Peter,
>> I do not know if this is best practice but I run the following code:
>>
>> static void
>> default_network_dhcpcd(void)
>> {
>> static const char default_cfg[] = "clientid test client\n";
>> rtems_status_code sc;
>> int fd;
>> int rv;
>> ssize_t n;
>> struct stat statbuf;
>>
>> if (ENOENT == stat("/etc/dhcpcd.conf", )) {
>> fd = open("/etc/dhcpcd.conf", O_CREAT | O_WRONLY,
>> S_IRWXU | S_IRWXG | S_IRWXO);
>> assert(fd >= 0);
>>
>> n = write(fd, default_cfg, sizeof(default_cfg) - 1);
>> assert(n == (ssize_t) sizeof(default_cfg) - 1);
>>
>> static const char fhi_cfg[] =
>> "nodhcp6\n"
>> "ipv4only\n"
>> "option ntp_servers\n"
>> "option rtems_cmdline\n"
>> "option tftp_server_name\n"
>> "option bootfile_name\n"
>> "define 129 string rtems_cmdline\n"
>> "timeout 0";
>>
>> n = write(fd, fhi_cfg, sizeof(fhi_cfg) - 1);
>> assert(n == (ssize_t) sizeof(fhi_cfg) - 1);
>>
>> rv = close(fd);
>> assert(rv == 0);
>> }
>>
>> sc = rtems_dhcpcd_start(NULL);
>> assert(sc == RTEMS_SUCCESSFUL);
>> }
> Hienz, this is a good solution and using a file best solution.
>
> Chris
I see online that DHCP option 129 has three definitions: "PXE - undefined
(vendor specific)", "Kernel options Variable length string", and "Call Server
IP address".
Above does "option rtems_cmdline" and "define 129 string rtems_cmdline" set
option 129 to correspond to "Kernel options"? There's no "DHO_" define for 129
in dhcp.h so I assume that's why you need the "define 129".
Option 17 is defined in dhcp.h ("#define DHO_ROOT_PATH 17") so I assume I just
add "option root_path". I'll try it later today.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] gdb: prefere python3 if it is installed
On 20/8/21 5:42 pm, Christian MAUDERER wrote: > Am 20.08.21 um 09:02 schrieb Chris Johns: >> On 20/8/21 4:48 pm, Christian MAUDERER wrote: >>> Hello, >>> >>> Am 20.08.21 um 03:49 schrieb Chris Johns: On 20/8/21 3:16 am, Joel Sherrill wrote: > On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom wrote: >> >> I have no problem with this. I think it is sensible to look for >> python3 before python2. At some point we'll have to stop looking for >> python2 :) > > That is further in the future than I would have thought based on the > CentOS project changes. I still see user organizations with no plans > to move off CentOS 7. It will receive maintenance updates through > 2024-06-30. > > But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't > that bad. I had to test something on a true 32-bit distribution this week > and even CentOS 7 (i386) wasn't as painful as I expected to setup. There will come a time when a change made cannot be easily tested by us on python2 and that will in effect end our support. We are not there yet. >>> >>> STOP. >> >> Please do not do this again. >> >> That discussion took a wrong direction. We discussed deprecating python2 a >>> few times and I know that we will not do it before the big long living >>> distributions drop it. I can live with that and I don't want to re-start >>> this >>> discussion with this patch. >> >> If Joel feels the need to make this statement he can and he has more than >> earned >> the right to do so. His work and those he supports is important. > > Sorry, I didn't want to offend you, Joel or Gedare. > > I had that with discussions before that the original idea (here: giving > priority > to python3 over python2 when building gdb) started to be buried by a similar > but > slightly different one which has been already discussed multiple times (here: > deprecating python2). I wanted to avoid that. > > I should have worded that different. I'm sorry if I have offended you, Joel or > Gedare or anyone else. Thanks and none taken. I am clear on the focus of your posts so it is ok. :) > >> >>> >> On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER >> wrote: >>> >>> PS: I had the problem on the 5 branch of RTEMS source builder. I think >>> we should apply a patch to both: master and the 5 branch. >>> >>> Am 19.08.21 um 10:34 schrieb Christian Mauderer: More and more systems stop shipping python2. So we should start to prefer python3 over python2. For building gdb it is not only necessary to have a python binary installed, but also the matching python-devel packet. On a lot of hosts that will now be more often python3-devel and not python2-devel. --- Note: Please see that patch more as an suggestion / base for discussion. I'm open to better solutions. My problem that triggered this patch was a build of a toolchain on a github CI/CD system that has been originally set up by one of our users (see [1] for the log). It seems that on the "macos-latest" machines a python2 is installed but no python2 headers are found. I have just built the latest RSB master GDB on a fully updated MacOS (Big Sur): config: tools/rtems-gdb-10.cfg package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB (installed: 19.586MB) cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml I support the latest MacOS with Xcode and have a dedicated Mac machine that tracks the current RSB. It had wedged itself and I have cleared that so it is now building the latest. >>> >>> So do I understand that correct: This is a "clean" Mac with no additional >>> python >>> installs or similar and it worked? What python versions are available on >>> this >>> this machine? >> >> It is working for me and I have not looked into it any more. >> >>> If I did understand you correctly, it seems that github has made some odd >>> choices about their default config for the macos-latest machines. They seem >>> to >>> have python2 but no devel headers. >> >> You will need to raise that with them. > > Yes, of course. I didn't want to raise it as a problem here. It was more a > statement than a question or a complain. Yeap, I understand. > >> Homebrew - which could be used earlier on MacOS to install the necessary headers - dropped the python@2 packet. Homebrew and MacPorts are a personal choice and I am fine with users heading
Re: [PATCH] gdb: prefere python3 if it is installed
Am 20.08.21 um 09:02 schrieb Chris Johns: On 20/8/21 4:48 pm, Christian MAUDERER wrote: Hello, Am 20.08.21 um 03:49 schrieb Chris Johns: On 20/8/21 3:16 am, Joel Sherrill wrote: On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom wrote: I have no problem with this. I think it is sensible to look for python3 before python2. At some point we'll have to stop looking for python2 :) That is further in the future than I would have thought based on the CentOS project changes. I still see user organizations with no plans to move off CentOS 7. It will receive maintenance updates through 2024-06-30. But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't that bad. I had to test something on a true 32-bit distribution this week and even CentOS 7 (i386) wasn't as painful as I expected to setup. There will come a time when a change made cannot be easily tested by us on python2 and that will in effect end our support. We are not there yet. STOP. Please do not do this again. That discussion took a wrong direction. We discussed deprecating python2 a few times and I know that we will not do it before the big long living distributions drop it. I can live with that and I don't want to re-start this discussion with this patch. If Joel feels the need to make this statement he can and he has more than earned the right to do so. His work and those he supports is important. Sorry, I didn't want to offend you, Joel or Gedare. I had that with discussions before that the original idea (here: giving priority to python3 over python2 when building gdb) started to be buried by a similar but slightly different one which has been already discussed multiple times (here: deprecating python2). I wanted to avoid that. I should have worded that different. I'm sorry if I have offended you, Joel or Gedare or anyone else. On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER wrote: PS: I had the problem on the 5 branch of RTEMS source builder. I think we should apply a patch to both: master and the 5 branch. Am 19.08.21 um 10:34 schrieb Christian Mauderer: More and more systems stop shipping python2. So we should start to prefer python3 over python2. For building gdb it is not only necessary to have a python binary installed, but also the matching python-devel packet. On a lot of hosts that will now be more often python3-devel and not python2-devel. --- Note: Please see that patch more as an suggestion / base for discussion. I'm open to better solutions. My problem that triggered this patch was a build of a toolchain on a github CI/CD system that has been originally set up by one of our users (see [1] for the log). It seems that on the "macos-latest" machines a python2 is installed but no python2 headers are found. I have just built the latest RSB master GDB on a fully updated MacOS (Big Sur): config: tools/rtems-gdb-10.cfg package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB (installed: 19.586MB) cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml I support the latest MacOS with Xcode and have a dedicated Mac machine that tracks the current RSB. It had wedged itself and I have cleared that so it is now building the latest. So do I understand that correct: This is a "clean" Mac with no additional python installs or similar and it worked? What python versions are available on this this machine? It is working for me and I have not looked into it any more. If I did understand you correctly, it seems that github has made some odd choices about their default config for the macos-latest machines. They seem to have python2 but no devel headers. You will need to raise that with them. Yes, of course. I didn't want to raise it as a problem here. It was more a statement than a question or a complain. Homebrew - which could be used earlier on MacOS to install the necessary headers - dropped the python@2 packet. Homebrew and MacPorts are a personal choice and I am fine with users heading down this path however it is beyond this project's scope to support those frameworks. I have posted the reasons in the past and the MacPorts maintainers are aware of those reasons. No problem. I'm not a Mac user so I don't really have an opinion or experience what is the right way to install the requirements on a MacOS system. I'm really happy that it just works most of the time (a lot of it most likely thanks to you). Actually, all I do is politely raise issues with those that do the real work. I think Homebrew and Macports are awesome projects but they bring in packages and with that issues and when our users have a mix of package versions the level of complexity
Re: [PATCH] gdb: prefere python3 if it is installed
On 20/8/21 4:48 pm, Christian MAUDERER wrote: > Hello, > > Am 20.08.21 um 03:49 schrieb Chris Johns: >> On 20/8/21 3:16 am, Joel Sherrill wrote: >>> On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom wrote: I have no problem with this. I think it is sensible to look for python3 before python2. At some point we'll have to stop looking for python2 :) >>> >>> That is further in the future than I would have thought based on the >>> CentOS project changes. I still see user organizations with no plans >>> to move off CentOS 7. It will receive maintenance updates through >>> 2024-06-30. >>> >>> But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't >>> that bad. I had to test something on a true 32-bit distribution this week >>> and even CentOS 7 (i386) wasn't as painful as I expected to setup. >> >> There will come a time when a change made cannot be easily tested by us on >> python2 and that will in effect end our support. We are not there yet. > > STOP. Please do not do this again. That discussion took a wrong direction. We discussed deprecating python2 a > few times and I know that we will not do it before the big long living > distributions drop it. I can live with that and I don't want to re-start this > discussion with this patch. If Joel feels the need to make this statement he can and he has more than earned the right to do so. His work and those he supports is important. > >> On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER wrote: > > PS: I had the problem on the 5 branch of RTEMS source builder. I think > we should apply a patch to both: master and the 5 branch. > > Am 19.08.21 um 10:34 schrieb Christian Mauderer: >> More and more systems stop shipping python2. So we should start to >> prefer python3 over python2. For building gdb it is not only necessary >> to have a python binary installed, but also the matching python-devel >> packet. On a lot of hosts that will now be more often python3-devel >> and not python2-devel. >> --- >> >> Note: Please see that patch more as an suggestion / base for >> discussion. I'm open to better solutions. >> >> My problem that triggered this patch was a build of a toolchain on a >> github CI/CD system that has been originally set up by one of our >> users (see [1] for the log). It seems that on the "macos-latest" >> machines a python2 is installed but no python2 headers are found. >> >> I have just built the latest RSB master GDB on a fully updated MacOS (Big >> Sur): >> >> config: tools/rtems-gdb-10.cfg >> package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 >> building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 >> sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB >> (installed: >> 19.586MB) >> cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 >> reporting: tools/rtems-gdb-10.cfg -> >> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt >> reporting: tools/rtems-gdb-10.cfg -> >> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml >> >> I support the latest MacOS with Xcode and have a dedicated Mac machine that >> tracks the current RSB. It had wedged itself and I have cleared that so it is >> now building the latest. > > So do I understand that correct: This is a "clean" Mac with no additional > python > installs or similar and it worked? What python versions are available on this > this machine? It is working for me and I have not looked into it any more. > If I did understand you correctly, it seems that github has made some odd > choices about their default config for the macos-latest machines. They seem to > have python2 but no devel headers. You will need to raise that with them. >> Homebrew - which could be used earlier on MacOS to install the >> necessary headers - dropped the python@2 packet. >> >> Homebrew and MacPorts are a personal choice and I am fine with users heading >> down this path however it is beyond this project's scope to support those >> frameworks. I have posted the reasons in the past and the MacPorts >> maintainers >> are aware of those reasons. > > No problem. I'm not a Mac user so I don't really have an opinion or experience > what is the right way to install the requirements on a MacOS system. I'm > really > happy that it just works most of the time (a lot of it most likely thanks to > you). Actually, all I do is politely raise issues with those that do the real work. I think Homebrew and Macports are awesome projects but they bring in packages and with that issues and when our users have a mix of package versions the level of complexity exploded. I have no capacity to cover this. > So it seems that on a >> modern MacOS there is no possibility to get python2 headers. >> >> As I have just built GDB this does not appear to be true. I would prefer we >> do >> not overreach until we all agree there is a problem. If there is an issue I
Re: [PATCH] gdb: prefere python3 if it is installed
Hello, Am 20.08.21 um 03:49 schrieb Chris Johns: On 20/8/21 3:16 am, Joel Sherrill wrote: On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom wrote: I have no problem with this. I think it is sensible to look for python3 before python2. At some point we'll have to stop looking for python2 :) That is further in the future than I would have thought based on the CentOS project changes. I still see user organizations with no plans to move off CentOS 7. It will receive maintenance updates through 2024-06-30. But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't that bad. I had to test something on a true 32-bit distribution this week and even CentOS 7 (i386) wasn't as painful as I expected to setup. There will come a time when a change made cannot be easily tested by us on python2 and that will in effect end our support. We are not there yet. STOP. That discussion took a wrong direction. We discussed deprecating python2 a few times and I know that we will not do it before the big long living distributions drop it. I can live with that and I don't want to re-start this discussion with this patch. On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER wrote: PS: I had the problem on the 5 branch of RTEMS source builder. I think we should apply a patch to both: master and the 5 branch. Am 19.08.21 um 10:34 schrieb Christian Mauderer: More and more systems stop shipping python2. So we should start to prefer python3 over python2. For building gdb it is not only necessary to have a python binary installed, but also the matching python-devel packet. On a lot of hosts that will now be more often python3-devel and not python2-devel. --- Note: Please see that patch more as an suggestion / base for discussion. I'm open to better solutions. My problem that triggered this patch was a build of a toolchain on a github CI/CD system that has been originally set up by one of our users (see [1] for the log). It seems that on the "macos-latest" machines a python2 is installed but no python2 headers are found. I have just built the latest RSB master GDB on a fully updated MacOS (Big Sur): config: tools/rtems-gdb-10.cfg package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB (installed: 19.586MB) cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml I support the latest MacOS with Xcode and have a dedicated Mac machine that tracks the current RSB. It had wedged itself and I have cleared that so it is now building the latest. So do I understand that correct: This is a "clean" Mac with no additional python installs or similar and it worked? What python versions are available on this this machine? If I did understand you correctly, it seems that github has made some odd choices about their default config for the macos-latest machines. They seem to have python2 but no devel headers. Homebrew - which could be used earlier on MacOS to install the necessary headers - dropped the python@2 packet. Homebrew and MacPorts are a personal choice and I am fine with users heading down this path however it is beyond this project's scope to support those frameworks. I have posted the reasons in the past and the MacPorts maintainers are aware of those reasons. No problem. I'm not a Mac user so I don't really have an opinion or experience what is the right way to install the requirements on a MacOS system. I'm really happy that it just works most of the time (a lot of it most likely thanks to you). So it seems that on a modern MacOS there is no possibility to get python2 headers. As I have just built GDB this does not appear to be true. I would prefer we do not overreach until we all agree there is a problem. If there is an issue I would raise the problem in Apple'd developer bug system. I have raised a number of issues over the years and to Apple's credit they have dealt with them all. Maybe I haven't made it enough clear: I had to do some guess work here. I have put it here as a basis for discussion. I'm completely OK if you can tell me that my conclusion has been wrong. It seems that it really is just an odd choice of defaults on github then. If python2 is still installed on the machine (for whatever reason), it is not possible to successfully use RTEMS source builder to build a gdb. If python3 is preferred instead, that should solve the problem. The change seems sensible. I think even if a clean MacOS doesn't have a problem (like I assumed), I still think it would be a good idea to prefer python3 if it is available. We are not talking about preferring it in our python-scripts but only to build gdb. Do I have a "go" to: - create tickets for 5
