Libexpat missing when using Python from python.org

[Ryan Long]

Hello,

Following Chris's advice, I installed Python 3.10.6 from Python's 
website. It gets me past the header check for gdb, but then it reports



checking whether to use expat... yes

checking for libexpat... no

configure: error: expat is missing or unusable

make[1]: *** [configure-gdb] Error 1

make: *** [all] Error 2


What's the best way to get Libexpat on macOS?

I was able to successfully build it with the python installed from 
Homebrew after disabling the building of gsed.


Thanks,

Ryan

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

[PATCH] gsed.cfg: Add check for gsed

[Ryan Long]

---
 bare/config/textproc/gsed.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bare/config/textproc/gsed.cfg b/bare/config/textproc/gsed.cfg
index 8287c74..b4aaf4f 100644
--- a/bare/config/textproc/gsed.cfg
+++ b/bare/config/textproc/gsed.cfg
@@ -2,7 +2,7 @@
 # GNU sed has a version option, check for it.
 # If not found build it.
 #
-%define has_gnu_sed %(sed --version > /dev/null 2>&1; echo $?)
+%define has_gnu_sed %(sed --version > /dev/null 2>&1 || gsed --version > 
/dev/null 2>&1; echo $?)
 %if %{has_gnu_sed} != 0
  %include %{_configdir}/textproc/gsed-4.8.cfg
 %endif
-- 
2.30.2

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

Re: [PATCH rtems-docs v2] TFTPFS: New documentation

[Joel Sherrill]

Thanks for the ping. Sorry I was out of town and didn't get to it until
today.

Verify this was merged correctly and this was it.

Thanks.

--joel

On Thu, Jun 9, 2022 at 8:21 AM Frank Kuehndel <
frank.kuehn...@embedded-brains.de> wrote:

> From: Frank Kühndel 
>
> ---
>  filesystem/index.rst   |   1 +
>  filesystem/trivial_ftp.rst | 564 -
>  2 files changed, 562 insertions(+), 3 deletions(-)
>
> diff --git a/filesystem/index.rst b/filesystem/index.rst
> index f4e2ed6..64a2f1d 100644
> --- a/filesystem/index.rst
> +++ b/filesystem/index.rst
> @@ -9,6 +9,7 @@ RTEMS Filesystem Design Guide (|version|).
>  .. topic:: Copyrights and License
>
>  | |copy| 1988, 2015 On-Line Applications Research Corporation (OAR)
> +| |copy| 2022 embedded brains GmbH (http://www.embedded-brains.de)
>
>  .. include:: ../common/license.rst
>
> diff --git a/filesystem/trivial_ftp.rst b/filesystem/trivial_ftp.rst
> index e43c036..3ef8bba 100644
> --- a/filesystem/trivial_ftp.rst
> +++ b/filesystem/trivial_ftp.rst
> @@ -3,7 +3,565 @@
>  Trivial FTP Client Filesystem
>  *
>
> -This chapter describes the Trivial FTP (TFTP) Client Filesystem.
> +This chapter describes the Trivial File Transfer Protocol (TFTP) Client
> +Filesystem.  TFTP is designed to be an especially simple protocol which
> +uses the User Datagram Protocol (UDP) for data transfer over the Internet.
> +Its purpose is to send a single file between to network nodes (client and
> +server).  A file can be sent in both directions, i.e. a client can either
> +read a file from a server or write a file to the server.
>
> -This chapter should be written after the IMFS chapter is completed and
> describe
> -the implementation of the TFTP.
> +Besides reading or writing a file no other operations are supported.  That
> +is, one cannot seek the file, not append to the end of a file, not open
> +the file for reading and writing at the same time, not list directories,
> +not move files and so on.
> +
> +TFTP is inherent insecure as it does not provide any means for
> +authentication or encryption.  Therefore, it is highly recommended not
> +to employ it on public networks.  Nevertheless, it is still widely used
> +to load software and configuration data during early boot stages over
> +a Local Area Network (LAN).
> +
> +RTEMS TFTP Filesystem Implementation
> +
> +
> +The RTEMS TFTP filesystem implements a TFTP client which can be used
> +through the file system.  With other words, one needs to mount the
> +TFTP filesystem and can afterwards open a file for reading or writing
> +below that mount point.  The content of that file is then effectively
> +read from or written to the remote server.  The RTEMS implementation
> +implements the following features:
> +
> +* `RFC 1350 `_
> +  *The TFTP Protocol (Revision 2)*
> +* `RFC 2347 `_
> +  *TFTP Option Extension*
> +* `RFC 2348 `_
> +  *TFTP Blocksize Option*
> +* `RFC 7440 `_
> +  *TFTP Windowsize Option*
> +
> +Many simple TFTP server do not support options (RFC 2347). Therefore, in
> +case the server rejects the first request with options, the RTEMS client
> +makes automatically a second attempt using only the "classical" RFC 1350.
> +
> +The implementation has the following shortcomings:
> +
> +* IPv6 is not supported (yet).
> +
> +* No congestion control is implemented.
> +
> +  (Congestion is simply expressed a network traffic jam which involves
> +  package loss.)  This implementation would worsen a congestion situation
> +  and squeeze out TCP connections.  If that is a concern in your setup,
> +  it can be prevented by using value `1` as `windowsize` when mounting
> +  the TFTP file system.
> +
> +* One must call ``open()``, ``read()``, ``write()`` and ``close()``
> +  at a good pace.
> +
> +  TFTP is designed to read or write a whole already existing file in
> +  one sweep.  It uses timeouts (of unspecified length) and it does not
> +  know keep-alive messages.  If the client does not respond to the
> +  server in due time, the server sets the connection faulty and drops it.
> +  To avoid this, the user must read or write enough data fast enough.
> +
> +  The point here is, one cannot pause the reading or writing for longer
> +  periods of time.  TFTP cannot be used for example to write log files
> +  where all few seconds a line is written.  Also opening the
> +  file at the beginning of an application and closing it that the end
> +  will certainly lead to a timeout.  As another example, one cannot
> +  read a file by reading one byte per second, this will trigger a
> +  timeout and the server closes the connection.  The opening, reading
> +  or writing and closing must happen in swift consecutive steps.
> +
> +* The transfer mode is a

Re: Libexpat missing when using Python from python.org

[Chris Johns]

On 4/10/2022 2:32 am, Ryan Long wrote:
> Hello,
> 
> Following Chris's advice, I installed Python 3.10.6 from Python's website. It
> gets me past the header check for gdb,

Great.

> but then it reports
> 
> 
> checking whether to use expat... yes
> 
> checking for libexpat... no
> 
> configure: error: expat is missing or unusable
> 
> make[1]: *** [configure-gdb] Error 1
> 
> make: *** [all] Error 2
> 
> 
> What's the best way to get Libexpat on macOS?
> 
> I was able to successfully build it with the python installed from Homebrew
> after disabling the building of gsed.

It should build for the Xcode (MacOS) python so I something is wrong in the GDB
common build script.

gsed has to be built if sed is not the GNU version

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

Re: [PATCH] gsed.cfg: Add check for gsed

[Chris Johns]

On 4/10/2022 2:52 am, Ryan Long wrote:
> ---
>  bare/config/textproc/gsed.cfg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bare/config/textproc/gsed.cfg b/bare/config/textproc/gsed.cfg
> index 8287c74..b4aaf4f 100644
> --- a/bare/config/textproc/gsed.cfg
> +++ b/bare/config/textproc/gsed.cfg
> @@ -2,7 +2,7 @@
>  # GNU sed has a version option, check for it.
>  # If not found build it.
>  #
> -%define has_gnu_sed %(sed --version > /dev/null 2>&1; echo $?)
> +%define has_gnu_sed %(sed --version > /dev/null 2>&1 || gsed --version > 
> /dev/null 2>&1; echo $?)
>  %if %{has_gnu_sed} != 0
>   %include %{_configdir}/textproc/gsed-4.8.cfg
>  %endif

What does gcc require sed be as a command? Is it sed or gsed?

Which host has gsed installed?

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

Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

[Sebastian Huber]

On 30/09/2022 23:39, Chris Johns wrote:

On 30/9/2022 7:21 pm, Sebastian Huber wrote:

Update #4524.
---
  cpukit/doxygen/appl-config.h| 13 +
  cpukit/include/rtems/rtems/config.h | 29 +-
  cpukit/include/rtems/score/interr.h |  1 +
  cpukit/sapi/src/interrtext.c|  3 +-
  cpukit/sapi/src/malloctaskstackforidle.c| 59 +
  spec/build/cpukit/librtemscpu.yml   |  1 +
  spec/build/testsuites/sptests/grp.yml   |  2 +
  spec/build/testsuites/sptests/spfatal36.yml | 19 +++
  testsuites/sptests/spfatal36/init.c | 52 ++
  testsuites/sptests/spfatal36/spfatal36.doc  | 11 
  testsuites/sptests/spinternalerror02/init.c |  2 +-
  testsuites/sptests/sptls04/init.c   |  2 +
  12 files changed, 191 insertions(+), 3 deletions(-)
  create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
  create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
  create mode 100644 testsuites/sptests/spfatal36/init.c
  create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index aa6dbae648..ee647dc961 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -4842,6 +4842,19 @@
   * configuration options.  It is assumed that any memory allocated for the
   * stack of an IDLE task will not be from the RTEMS Workspace or the memory
   * statically allocated by default.
+ *
+ * For applications with a thread-local storage size which is completely
+ * unknown at the time the application configuration is defined, RTEMS provides
+ * an IDLE task stack allocator which uses rtems_malloc().


I thought the TLS size was static and set by the linker? Has this changed?


No, this didn't change.



I am confused about the relationship between an unknown TLS size and IDLE task?
And the relationship of the TLS size and stack size?


Currently, the IDLE task storage area is statically allocated. The size 
of this area is defined by CONFIGURE_IDLE_TASK_STACK_SIZE. So, this 
configuration option doesn't directly specify the IDLE task stack size. 
This size covers also the TLS area.





* * The size of the
+ * allocated thread storage area is the sum of stack size defined by the
+ * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the actual
+ * thread-local storage size of the application.


The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight into it being
effected by the TLS size.


* * Define this configuration
+ * option to ``rtems_malloc_task_stack_for_idle`` to use this allocator.  If
+ * the memory allocation fails, then the system terminates with the
+ * INTERNAL_ERROR_CORE fatal source and the
+ * INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK fatal code during system
+ * initialization.
+ * @endparblock


I am confused about the how and why I would use this change?


With the statically allocated storage area for the IDLE task you need at 
least an estimate of the size if you define the application 
configuration. If you can't estimate it, then one option is to simply 
allocate it dynamically.


Maybe a better approach is to allocate the IDLE task storage from the 
workspace by default and use the CONFIGURE_IDLE_TASK_STACK_SIZE really 
for the stack size and not the complete storage area. We could add a new 
configuration option (for example CONFIGURE_IDLE_TASK_STORAGE_SIZE) to 
enable the static allocation.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel