Re: [PATCH 2/2] bsp/stm32f4.h: Remove double define

[Matthew Joyce]

It's on line 131. Both defines are referring to the same address 
(0x40023C00) --one define just starts from STM32F4_BASE and the other 
from STM32F4_AHB1_BASE.


On 19.10.22 14:46, Joel Sherrill wrote:

Looks ok but where was the other one?

On Wed, Oct 19, 2022, 5:57 AM Matthew Joyce 
 wrote:


From: Matt Joyce 

Remove double define of STM32F4_FLASH.
---
 bsps/arm/stm32f4/include/bsp/stm32f4.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/bsps/arm/stm32f4/include/bsp/stm32f4.h
b/bsps/arm/stm32f4/include/bsp/stm32f4.h
index 7f84480ece..3b1f9ff9ba 100644
--- a/bsps/arm/stm32f4/include/bsp/stm32f4.h
+++ b/bsps/arm/stm32f4/include/bsp/stm32f4.h
@@ -54,16 +54,6 @@

 /** @} */

-/**
- * @name STM32F4 FLASH
- * @{
- */
-
-#include 
-#define STM32F4_FLASH ((volatile stm32f4_flash *) (STM32F4_BASE +
0x40023C00))
-
-/** @} */
-
 #include 

 /**
-- 
2.31.1


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


--
embedded brains GmbH
Herr Matthew JOYCE
Dornierstr. 4
82178 Puchheim
Germany
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] bsp/stm32f4xxxx_rcc.h: Fix RCC register defines

[Matthew Joyce]

RCC_CFGR_PPRE2 is defined twice, on lines 240 and 241. Based on the 
other defines, I think 241 should have been RCC_CFGR_PPRE2_MSK. Is that 
what you're referring to? Thanks!


On 19.10.22 14:48, Joel Sherrill wrote:

I don't see the name defined twice. Are they functionally equivalent?

On Wed, Oct 19, 2022, 5:57 AM Matthew Joyce 
 wrote:


From: Matt Joyce 

Fix a double define of RCC_CFGR_PPRE2 and add RCC_CFGR_PPRE1_MSK.
---
 bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
b/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
index 7dadfbe756..dc4a7f0edd 100644
--- a/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
+++ b/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
@@ -231,6 +231,7 @@ typedef struct {
 #define RCC_CFGR_HPRE_BY_512 BSP_FLD32( 15, 4, 7 )

 #define RCC_CFGR_PPRE1 10
+#define RCC_CFGR_PPRE1_MSK BSP_MSK32( 10, 12 )
 #define RCC_CFGR_PPRE1_BY_1 0
 #define RCC_CFGR_PPRE1_BY_2 BSP_FLD32( 4, 10, 12 )
 #define RCC_CFGR_PPRE1_BY_4 BSP_FLD32( 5, 10, 12 )
@@ -238,7 +239,7 @@ typedef struct {
 #define RCC_CFGR_PPRE1_BY_16 BSP_FLD32( 7, 10, 12 )

 #define RCC_CFGR_PPRE2 13
-#define RCC_CFGR_PPRE2 BSP_MSK32( 13, 15 )
+#define RCC_CFGR_PPRE2_MSK BSP_MSK32( 13, 15 )
 #define RCC_CFGR_PPRE2_BY_1 0
 #define RCC_CFGR_PPRE2_BY_2 BSP_FLD32( 4, 13, 15 )
 #define RCC_CFGR_PPRE2_BY_4 BSP_FLD32( 5, 13, 15 )
-- 
2.31.1


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


--
embedded brains GmbH
Herr Matthew JOYCE
Dornierstr. 4
82178 Puchheim
Germany
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [libbsd 00/22] Remove FreeBSD file descriptors and avoid VFS

[Sebastian Huber]

On 29/08/2022 10:27, Sebastian Huber wrote:

Hello Chris,

On 25/07/2022 08:12, Sebastian Huber wrote:

On 11/07/2022 15:04, Sebastian Huber wrote:

On 24/06/2022 08:33, Sebastian Huber wrote:
This patch set removes the FreeBSD file descriptors.  The VFS is no 
longer used

if only the USB, SD/MMC, network, PCI, and NVMe support is used by the
application.  This change significantly reduce the memory usage of 
LibBSD for
these applications.  Using the media01 test case for the arm/lpc32xx 
BSP as a

benchmark, the heap usage dropped from 14.3MiB to 10.2MiB.  The "_BSD
bufdaemon", "_BSD vnlru", "_BSD syncer", and "_BSD bufspacedaemon-" 
tasks are
no longer present in media01.  The code size is reduced by about 
8KiB.  The
data size is reduced by about 30KiB.  The throughput with a simple 
FTP test

increased by about 1%.

The "Remove FreeBSD file descriptors" change removes more lines than 
there are

added.

This change makes it easier to port the NFS support to the master 
branch since

now the changes are more localized.


I have a target with only 8MiB of RAM (for code and data). So, this 
patch set is not just a micro optimization.


This pending patch set is currently a blocker for me. I would like to 
work on the NTP daemon integration and an update of the libbsd master 
branch to a more recent FreeBSD version. This patch set just restores 
what worked well for several years.


did you have time to review this patch set in the meantime? The NTP 
client no longer crashes with this patch set.


This patch set is now pending for about four months. From my point of 
view it is a straight forward fix of some severe issues which prevent 
the use of libbsd on lower end targets. It is not really good if our 
internal libbsd branches diverge too much from the RTEMS mainline.


--
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

Re: [libbsd 00/22] Remove FreeBSD file descriptors and avoid VFS

[Chris Johns]

On 20/10/2022 7:01 pm, Sebastian Huber wrote:
> On 29/08/2022 10:27, Sebastian Huber wrote:
>> Hello Chris,
>>
>> On 25/07/2022 08:12, Sebastian Huber wrote:
>>> On 11/07/2022 15:04, Sebastian Huber wrote:
 On 24/06/2022 08:33, Sebastian Huber wrote:
> This patch set removes the FreeBSD file descriptors.  The VFS is no longer
> used
> if only the USB, SD/MMC, network, PCI, and NVMe support is used by the
> application.  This change significantly reduce the memory usage of LibBSD 
> for
> these applications.  Using the media01 test case for the arm/lpc32xx BSP 
> as a
> benchmark, the heap usage dropped from 14.3MiB to 10.2MiB.  The "_BSD
> bufdaemon", "_BSD vnlru", "_BSD syncer", and "_BSD bufspacedaemon-" tasks 
> are
> no longer present in media01.  The code size is reduced by about 8KiB.  
> The
> data size is reduced by about 30KiB.  The throughput with a simple FTP 
> test
> increased by about 1%.
>
> The "Remove FreeBSD file descriptors" change removes more lines than 
> there are
> added.
>
> This change makes it easier to port the NFS support to the master branch 
> since
> now the changes are more localized.

 I have a target with only 8MiB of RAM (for code and data). So, this patch
 set is not just a micro optimization.
>>>
>>> This pending patch set is currently a blocker for me. I would like to work 
>>> on
>>> the NTP daemon integration and an update of the libbsd master branch to a
>>> more recent FreeBSD version. This patch set just restores what worked well
>>> for several years.
>>
>> did you have time to review this patch set in the meantime? The NTP client no
>> longer crashes with this patch set.
> 
> This patch set is now pending for about four months. From my point of view it 
> is
> a straight forward fix of some severe issues which prevent the use of libbsd 
> on
> lower end targets.

Is there a repo somewhere with the patches applied? I am being lazy asking as I
would like to avoid downloading the 22 patches and applying them by hand.

It seems the media test cannot grow by more than 9K of code and the heap by 5M!
Is my understanding correct? Anything else we need to understand about the low
end limits?

I have not seen any requirements on the lower end for libbsd before now. How do
we manage the competing requirement of low end support and adding functionality
to libbsd in the future if they clash?

Adding VFS support as FreeBSD implements it has pushed you over the edge but
that edge is not defined so it makes it difficult for anyone other than you to
work on this code base in a major way. I was not aware this was an issue and for
me the extra 9K of code is not a problem and a 5M change in heap is acceptable.

> It is not really good if our internal libbsd branches diverge
> too much from the RTEMS mainline.

Yes I agree. It is not in anyone's interest and that only benefits you.

I would like to reiterate we have an obligation to maintain the code base as
close to FreeBSD as possible. Some of these changes push that boundary. We need
to find a suitable path forward.

Reviewing the changes:

1. The break up of the syscalls file. The related comments are:

 "Collecting all system calls in a single translation unit is not good
  due to the library initialization through linker sets."

Could you please explain what the linker set issue is?

Why the need to change FreeBSD calls to static? Is it solely a performance
optimisation?

We are required to use function and data sections so I assume the syscall file
will be broken up by the linker where possible?

I cannot tell from the patches if the conditional syscall trace support is still
present?

I do not agree with your statement in the patches separation helps porting. My
experience was not that. When adding VFS and the NFS client I found the syscall
code all over the place and not easy to find, hard to review and it added
complexity. It adds unnecessary changes to the FreeBSD code against a base
requirement of the porting effort.

2. FreeBSD file descriptor removal

Does this mean we can never have them in libbsd? Does that limit what can be
brought across from FreeBSD in the future?

3. select, poll, and kqueue

Do these calls work with an NFS client fd?

4. Types of RTEMS fd's in libbsd

The change I made brought the types into a single location so it is easier to
review and understand. There is:

 - rtems_bsd_sysgen_dirops
 - rtems_bsd_sysgen_fileops
 - rtems_bsd_sysgen_nodeops
 - rtems_bsd_sysgen_imfsnodeops

VFS is now left to handle the specific vnode ops as FreeBSD is designed to do.

[
https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-syscall-api.c?h=6-freebsd-12
]

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

Re: Ping on ticket 4728 + patch

[Alan Cudmore]

On Thu, Oct 20, 2022 at 2:13 AM Sebastian Huber
 wrote:
>
>
>
> On 20/10/2022 03:48, Alan Cudmore wrote:
> > On Wed, Oct 19, 2022 at 12:24 AM Sebastian Huber
> >  wrote:
> >>
> >> On 18/10/2022 21:02, Alan Cudmore wrote:
> >>> *From: *Sebastian Huber 
> >>> *Sent: *Tuesday, October 18, 2022 11:15 AM
> >>> *To: *Alan Cudmore ; j...@rtems.org
> >>> 
> >>> *Cc: *rtems-de...@rtems.org 
> >>> *Subject: *Re: Ping on ticket 4728 + patch
> >>>
> >>> On 18/10/2022 16:36, Alan Cudmore wrote:
> >>>
> >>>   > On Tue, Oct 18, 2022 at 9:55 AM Joel Sherrill  wrote:
> >>>
> >>>   >>
> >>>
> >>>   >>
> >>>
> >>>   >> On Tue, Oct 18, 2022 at 8:44 AM Alan
> >>> Cudmore  wrote:
> >>>
> >>>   >>> The log does have the error, and I get it when building by hand too:
> >>>
> >>>   >>> start.o: in function `.L0 ':
> >>>
> >>>   >>>
> >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5c):
> >>>
> >>>   >>> relocation truncated to fit: R_RISCV_GPREL_I against symbol
> >>>
> >>>   >>> `bsp_section_bss_size' defined in*ABS*  section in
> >>>
> >>>   >>>
> >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
> >>>
> >>>   >>> collect2: error: ld returned 1 exit status
> >>>
> >>>   >>
> >>>
> >>>   >>
> >>>
> >>>   >> Hmmm.. that's weird. You should never get a truncation error linking
> >>> minimum.exe.
> >>>
> >>>   >> It should always fit within the BSP's memory and not have any issues
> >>> with branches
> >>>
> >>>   >> or calls needing fixup.
> >>>
> >>>   >>
> >>>
> >>>   >> Unless the wrong type of branch/jump/call instruction is used at
> >>> start.S:86, I have
> >>>
> >>>   >> no idea.If it's a form that assumes a short distance to the
> >>> destination but is going
> >>>
> >>>   >> to a symbol outside start.S and thus could be further.
> >>>
> >>>   > Also, 6 of the samples such as hello.exe link without error.
> >>>
> >>>   > The rv32imafdc BSP variant does not have CPU_CFLAGS.
> >>>
> >>>   > rv32imafd links fine and has specific CPU_CFLAGS, rv32imafdc does not
> >>>
> >>>   > have the flags.
> >>>
> >>>   > (I'll research the gcc defaults and architecture differences next..)
> >>>
> >>>   >
> >>>
> >>>   > I get a similar error on the frdme310arty BSP but only on a specific
> >>>
> >>>   > POSIX testsuite executable:
> >>>
> >>>   >
> >>>
> >>>   > start.o: in function `.L0 ':
> >>>
> >>>   >
> >>>
> >>>   >
> >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x28):
> >>>
> >>>   > relocation truncated to fit: R_RISCV_GPREL_I against symbol
> >>>
> >>>   > `bsp_section_bss_size' defined in*ABS*  section in
> >>>
> >>>   >
> >>> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
> >>>
> >>>   >
> >>>
> >>>   > collect2: error: ld returned 1 exit status
> >>>
> >>> My off hand guess is that this is a tool chain issue on certain host
> >>>
> >>> systems. For example, I never got this error on our OpenSUSE machines.
> >>>
> >>> I can set up a OpenSUSE virtual machine and try it. I noticed the RSB
> >>> documentation does not have a set of packages for OpenSUSE – I could
> >>> send a docs patch after a successful build. What release do you use? Do
> >>> you have a list of packages to install?
> >>
> >> We use openSUSE Leap 15.3 and 15.4. To get the packages maybe try this:
> >>
> >> zypper in -t pattern devel_C_C++ devel_python3
> >
> > I was able to set up an openSUSE Leap 15.4 (64 bit) VM and the above
> > packages worked for the RSB build.
> > Unfortunately, I still get the same link error for minimum.exe. Do you
> > think this is a linker error? Is it worth trying a Clang build?
>
> I am not really sure what it its, since I never got this error on one of
> our machines.
>
> What happens if you compile the attached files with:
>
> riscv-rtems6-gcc start.S abs.S -Wl,-gc-sections
This produces a.out without error. I can post the symbols or objdump
header info if that would help.
For the minimum.exe failure, I can add:
volatile int x = 0;
to the Init function and the error goes away.
I can also get the error to go away if I add RTEMS_POSIX_API=True to config.ini
I suspect that what I am doing is adding just enough code or data to
move the bss symbol close enough to the global pointer. I can try to
compare the map for minimum.exe for both the original and modified
version that does link. The original version will produce an
executable if I use -Wl,--noinhibit-exec
>
> --
> 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
> Vertretungsberechtig

RE: [PATCH rtems-docs v2] user/bsps: Update riscv for PolarFire SoC

[Padmarao.Begari]

Hi,

The Patch v1 was reviewed by Alan, update few comments, and submitted Patch v2.
 https://lists.rtems.org/pipermail/devel/2022-October/073469.html - Patch v1

https://lists.rtems.org/pipermail/devel/2022-October/073528.html - Patch v2

Can you please review or merge it to rtems-docs git?

Regards
Padmarao
-Original Message-
From: Padmarao Begari  
Sent: Monday, October 10, 2022 12:25 PM
To: devel@rtems.org
Cc: Cyril Jean - M31571 ; Padmarao Begari - I30397 

Subject: [PATCH rtems-docs v2] user/bsps: Update riscv for PolarFire SoC

Update the riscv documentation for the Microchip PolarFire SoC BSP variant 
including information about SMP test procedure for the Microchip PolarFire 
Icicle Kit.
---
 user/bsps/bsps-riscv.rst | 126 ++-
 1 file changed, 125 insertions(+), 1 deletion(-)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst index 
5faa87b..48e7ee7 100644
--- a/user/bsps/bsps-riscv.rst
+++ b/user/bsps/bsps-riscv.rst
@@ -8,7 +8,7 @@ riscv (RISC-V)
 riscv
 =
 
-This BSP offers 13 variants:
+This BSP offers 15 variants:
 
 * rv32i
 
@@ -38,6 +38,8 @@ This BSP offers 13 variants:
 
 * frdme310arty
 
+* mpfs64imafdc
+
 Each variant corresponds to a GCC multilib.  A particular variant reflects an  
ISA with ABI and code model choice.
 
@@ -47,6 +49,9 @@ be started im machine mode.
 
 The reference platform for this BSP is the Qemu `virt` machine.
 
+The reference platform for the mpfs64imafdc BSP variant is the 
+Microchip PolarFire SoC Icicle Kit.
+
 Build Configuration Options
 ---
 
@@ -68,6 +73,13 @@ configuration INI file. The ``waf`` defaults can be used to 
inspect the values.
 ``BSP_FDT_BLOB_SIZE_MAX``
 The maximum size of the device tree blob in bytes (default is 65536).
 
+``BSP_DTB_IS_SUPPORTED``
+If defined to a non-zero value, then the device tree blob is embedded in
+the BSP.
+
+``BSP_DTB_HEADER_PATH``
+The path to the header file containing the device tree blob.
+
 ``BSP_CONSOLE_BAUD``
 The default baud for console driver devices (default 115200).
 
@@ -94,6 +106,13 @@ configuration INI file. The ``waf`` defaults can be used to 
inspect the values.
  Enables support sifive Freedom E310 Arty board if defined to a non-zero
  value,otherwise it is disabled (disabled by default)
 
+``RISCV_ENABLE_MPFS_SUPPORT``
+ Enables support Microchip PolarFire SoC if defined to a non-zero
+ value, otherwise it is disabled (disabled by default).
+
+``RISCV_BOOT_HARTID``
+ The boot hartid (processor number) of risc-v cpu by default 0.
+
 Interrupt Controller
 
 
@@ -124,6 +143,111 @@ They are initialized according to the device tree.  The 
console driver does not  configure the pins or peripheral clocks.  The console 
device is selected  according to the device tree "/chosen/stdout-path" property 
value.
 
+Microchip PolarFire SoC
+---
+
+The PolarFire SoC is the 4x 64-bit RISC-V U54 cores and a 64-bit RISC-V
+E51 monitor core SoC from the Microchip.
+
+The ``mpfs64imafdc`` BSP variant supports the U54 cores but not the E51 
+because the E51 monitor core is reserved for the first stage bootloader 
+(Hart Software Services). In order to boot from the first U54 core, 
+``RISCV_BOOT_HARTID`` is set to 1 by default.
+
+The device tree blob is embedded in the ``mpfs64imafdc`` BSP variant by 
+default with the ``BSP_DTB_IS_SUPPORTED`` enabled and the DTB header 
+path ``BSP_DTB_HEADER_PATH`` is set to bsp/mpfs-dtb.h.
+
+**SMP test procedure for the Microchip PolarFire Icicle Kit:**
+
+The "config.ini" file.
+
+.. code-block:: none
+
+[riscv/mpfs64imafdc]
+BUILD_TESTS = True
+RTEMS_POSIX_API=True
+RTEMS_SMP = True
+BSP_START_COPY_FDT_FROM_U_BOOT=False
+BSP_VERBOSE_FATAL_EXTENSION = False
+
+Build RTEMS.
+
+.. code-block:: shell
+
+$ ./waf configure --prefix=$HOME/rtems-start/rtems/6
+$ ./waf
+
+Convert .exe to .elf file.
+
+.. code-block:: shell
+
+$ riscv-rtems6-objcopy 
+ build/riscv/mpfs64imafdc/testsuites/smptests/smp01.exe 
+ build/riscv/mpfs64imafdc/testsuites/smptests/smp01.elf
+
+Generate a payload for the `smp01.elf` using the `hss-payload-generator 
`_.
+
+* Copy `smp01.elf` file to the HSS/tools/hss-payload-generator/test directory.
+
+* Go to hss-payload-generator source directory.
+
+.. code-block:: shell
+
+$ cd hart-software-services/tools/hss-payload-generator
+
+* Edit test/uboot.yaml file for the hart entry points and correct name 
+of the
+  binary file.
+
+.. code-block:: none
+
+set-name: 'PolarFire-SoC-HSS::RTEMS'
+hart-entry-points: {u54_1: '0x10', u54_2: '0x10', u54_3: 
'0x10', u54_4: '0x10'}
+payloads:
+ test/smp01.elf: {exec-addr: '0x10', owner-hart: u54_1, 
+ secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, 
+ pri

Re: [PATCH rtems-docs v2] user/bsps: Update riscv for PolarFire SoC

[Chris Johns]

On 21/10/2022 4:04 pm, padmarao.beg...@microchip.com wrote:
> The Patch v1 was reviewed by Alan, update few comments, and submitted Patch 
> v2.
>  https://lists.rtems.org/pipermail/devel/2022-October/073469.html - Patch v1
> 
> https://lists.rtems.org/pipermail/devel/2022-October/073528.html - Patch v2
> 
> Can you please review or merge it to rtems-docs git?

Sorry about the delay. I have merged the patch based on Alan's review.

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

Re: [libbsd 00/22] Remove FreeBSD file descriptors and avoid VFS

[Sebastian Huber]

On 21/10/2022 02:30, Chris Johns wrote:

On 20/10/2022 7:01 pm, Sebastian Huber wrote:

On 29/08/2022 10:27, Sebastian Huber wrote:

Hello Chris,

On 25/07/2022 08:12, Sebastian Huber wrote:

On 11/07/2022 15:04, Sebastian Huber wrote:

On 24/06/2022 08:33, Sebastian Huber wrote:

This patch set removes the FreeBSD file descriptors.  The VFS is no longer
used
if only the USB, SD/MMC, network, PCI, and NVMe support is used by the
application.  This change significantly reduce the memory usage of LibBSD for
these applications.  Using the media01 test case for the arm/lpc32xx BSP as a
benchmark, the heap usage dropped from 14.3MiB to 10.2MiB.  The "_BSD
bufdaemon", "_BSD vnlru", "_BSD syncer", and "_BSD bufspacedaemon-" tasks are
no longer present in media01.  The code size is reduced by about 8KiB.  The
data size is reduced by about 30KiB.  The throughput with a simple FTP test
increased by about 1%.

The "Remove FreeBSD file descriptors" change removes more lines than there are
added.

This change makes it easier to port the NFS support to the master branch since
now the changes are more localized.


I have a target with only 8MiB of RAM (for code and data). So, this patch
set is not just a micro optimization.


This pending patch set is currently a blocker for me. I would like to work on
the NTP daemon integration and an update of the libbsd master branch to a
more recent FreeBSD version. This patch set just restores what worked well
for several years.


did you have time to review this patch set in the meantime? The NTP client no
longer crashes with this patch set.


This patch set is now pending for about four months. From my point of view it is
a straight forward fix of some severe issues which prevent the use of libbsd on
lower end targets.


Is there a repo somewhere with the patches applied? I am being lazy asking as I
would like to avoid downloading the 22 patches and applying them by hand.


Thanks for having a look at this work. You find a branch for testing here:

https://github.com/sebhub/rtems-libbsd/tree/filedesc

You need this RTEMS patch:

https://lists.rtems.org/pipermail/devel/2022-June/072055.html



It seems the media test cannot grow by more than 9K of code and the heap by 5M!
Is my understanding correct? Anything else we need to understand about the low
end limits?


If you have only 16M or 32M of RAM for code and data than adding 5M for 
nothing is a big deal. The libbsd started as a libusb. Not every 
application uses the network stuff.




I have not seen any requirements on the lower end for libbsd before now. How do
we manage the competing requirement of low end support and adding functionality
to libbsd in the future if they clash?

Adding VFS support as FreeBSD implements it has pushed you over the edge but
that edge is not defined so it makes it difficult for anyone other than you to
work on this code base in a major way. I was not aware this was an issue and for
me the extra 9K of code is not a problem and a 5M change in heap is acceptable.


The problem is not the VFS support. The problem is that you added the 
FreeBSD file descriptors and concentrated all the system calls in one 
translation unit.





It is not really good if our internal libbsd branches diverge
too much from the RTEMS mainline.


Yes I agree. It is not in anyone's interest and that only benefits you.

I would like to reiterate we have an obligation to maintain the code base as
close to FreeBSD as possible. Some of these changes push that boundary. We need
to find a suitable path forward.


Being as close as possible to FreeBSD should not result in being 
FreeBSD. RTEMS has its own infrastructure and one part is the file 
descriptor handling. There are always trade-offs to consider when 
porting new components from FreeBSD to RTEMS.




Reviewing the changes:

1. The break up of the syscalls file. The related comments are:

  "Collecting all system calls in a single translation unit is not good
   due to the library initialization through linker sets."

Could you please explain what the linker set issue is?


The libbsd uses a constructor based initialization. The constructors are 
pulled in through the configuration and indirectly by using API level 
functions. If you concentrate the API level function in one file, then 
everything related to all of the API level functions is pulled in and 
initialized. Therefore, the API level functions need to be placed in 
separate translation units so that you get only what you need in your 
executable. For example, if you just want to use USB and sysctl(), then 
you should not end up with stuff related to socket().




Why the need to change FreeBSD calls to static? Is it solely a performance
optimisation?


It is also easier to maintain if you have the RTEMS glue code attached 
to the FreeBSD system call implementation (sys_* and kern_*). For 
example, in uipc_syscalls.c the glue code was placed in white space 
between functions. Such code areas are absolutely no is